12 ms·

I saw a very interesting talk last year from someone who, as part of a company's security team, had set up a system that continually attacked the hashes of ever

• mdpye 9y ago
  The sysadmin in the CS computer labs at my uni (Leeds) was doing this in 2002. Changing cracked passwords was compulsory, you got an email that just said (paraphrasing) "Your password is crap" and then were forced to change it at next login. It was quite amusing, and instructive for the first year students. I seem to remember it happening to maybe 15 to 20% of people when I started, even though everyone was warned repeatedly. And this was with hardware and hashes from 15 years ago. Many (most?!) websites were still storing passwords in plain-text and didn't use TLS for log-in forms in those days!
• mike-cardwell 9y ago
  I used to work at a University in the UK. One of my responsibilities was the email system. We constantly suffered targeted phishing attacks where the sender pretended to be from the IT department and required the recipient to respond with their password, for various made up reasons. Our spam filters captured most of these on the way in, but some still got through. And people replied. People replied all the time. Students and staff. Even after being constantly informed about the problem and told to not reply to such emails. When they replied, the attacker would log in and start sending out spam. Anyway, the format of our passwords was quite strict. I don't remember the exact rules, but it required "special" characters and lower/upper case letters and numbers and a minimum length etc. So what I did was write a system to scan all outgoing email. It would search that email for all strings which matched our password pattern. It would then attempt to authenticate against the Active Directory with each of those strings. If any succeeded, it would block the email, and the person sending the email would get a response telling them to not send their password via email. I would also be Cc'd in, so I could keep an eye on it. This stopped several people a week from emailing out their login details to a phisher. I wrote about it here: https://www.grepular.com/Mitigating_Spear_Phishing https://www.grepular.com/Mitigating_Spear_Phishing - With links to the source code. I also later came up with a simpler solution and wrote about it here: https://www.grepular.com/Defending_Against_Spear_Phishing_with_Exim https://www.grepular.com/Defending_Against_Spear_Phishing_wi...
  • koolba 9y ago
    That's seriously cool! I was reading about something similar for CI servers to compare the stdout/err to the values of all initialized secrets and if any strings match, filter them out. It's a simple way to block "echo $SECRET_STUFF" from publishing to a public log. It doesn't catch everything as it'd still be possible to curl out to transmit information, but it does work quite well for the more common case of "*Let me dump all environment cars to debug why this isn't working...".
  • kqr 9y ago
    Interesting! Did you consider regularly sending phishing emails yourself, and automatically call out anyone who reply anything at all to them? I mean, you won't catch quite as many people, but eventually most will learn, one would think.
    • mike-cardwell 9y ago
      I do remember that idea being discussed. I can't remember why we didn't go ahead with it at the time.
      • adamkruszewski 9y ago
        Wouldn't that add additional noise to each employee work and thus could potentially be more costly than phishing e-mails themselves?
    • glitcher 9y ago
      > but eventually most will learn, one would think With a large batch of new incoming students every year this problem would never go away.
  • toomuchtodo 9y ago
    This is brilliant.
  • andreareina 9y ago
    Nice to see that your second solution doesn't require passwords to conform to a format to work.
• peterwwillis 9y ago
  Where you use this is important, too. Accounts that can provide remote access or admin rights should be scrutinized heavily, whereas an office temp with an email address (and no access from the outside world) isn't much of a threat.
  • JoshTriplett 9y ago
    Not true. When that email address gets broken into, it'll get used to send spam, making your mail server a spam source, and making it harder for all the rest of your mail to reach people's inboxes. Not to mention producing more spam for the rest of us.
    • peterwwillis 9y ago
      If someone has broken into your internal network, harvested or brute forced credentials, and is now sending emails externally, you have WAY bigger problems than spam.
• hdhzy 9y ago
  > who, as part of a company's security team, had set up a system that continually attacked the hashes of every employee's Active Directory passwords. On the other hand of you are not part of the security team something like this can get you in some real trouble. Don't do it at home kids!
  • 0xdeadbeefbabe 9y ago
    It can also get you hired, as long as you are dealing with A students.
  • js2 9y ago
    The most famous case I'm aware of: https://en.wikipedia.org/wiki/Randal_L._Schwartz#Intel_case https://en.wikipedia.org/wiki/Randal_L._Schwartz#Intel_case
  • jandrese 9y ago
    I tried to send an email and now my AD account is locked!
• Ajedi32 9y ago
  That's a cool idea, but wouldn't it be more efficient to use something like zxcvbn to estimate the strength of new passwords and reject weak ones? That way you're not wasting electricity running a GPU array at full tilt 24/7.
  • SamBam 9y ago
    It might not catch the kinds of things that seem strong but end up on word lists. `correctbatteryhorsestaple`, and even more so `correctbatteryhorsestaple1` or `correctbatteryhorsestaple!` would probably pass a "strength" test with flying colors, but you bet it would get cracked in a moment by any script kiddie with a word list.
    • Ajedi32 9y ago
      zxcvbn accounts for the use of word lists. (And keyboard patterns, and common dates, and repeated characters, and a dozen or so other common patterns you probably haven't thought of yet.) Try it yourself: https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.html https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.ht... And in fact, four random words is actually quite strong. The XKCD comic that password is taken from accounts for the use of word lists in its entropy calculation. In fact, it even _assumes_ the attacker knows the exact 2048-word dictionary you're selecting the words from. Even under those assumptions, four random words is _still_ a pretty strong password.
      • SamBam 9y ago
        By `correctbatteryhorsestaple` I meant exactly that. Four words are great. THOSE four words would be terrible.
        • Ajedi32 9y ago
          But a brute force test like the parent comment described wouldn't catch that either, unless it had 'correctbatteryhorsestaple' as a word in one of its dictionaries. And if you're going to go that route, it's just as easy to put 'correctbatteryhorsestaple' in one of zxcvbn's dictionaries. Any common password pattern you could catch via brute force could also be detected via zxcvbn, except that zxcvbn would be much faster and more efficient at it.
• Diederich 9y ago
  Story time...please excuse the tangent, related to the above comment. In the mid 1990s, I was the computer security officer for the 81st Medical Group in the USAF, which is the proper name for a rather large DOD hospital in southern Mississippi. Though it was 22 years ago, the hospital was almost completely paperless. Every member of the staff, from doctors to orderlies, used one of the 10,000 or so VT320 terminals spread across a dozen or so building in the campus and beyond. Needless to say, on an average day, a person would enter their userid and password many times. Many of those accounts were very powerful, because we were networked with the rest of the DOD's medical records. One example report I ran with a doctor's account credentials was 'List everyone in the DOD, past or present, who is or was HIV positive.' ('Was' because the person could be dead.) Furthermore, this entire system was reachable via the Internet, via AFIN (Air Force Information Network). This probably strikes anyone reading this as...kind of nuts. And by today's standards it certainly in. But 22 years ago, most people weren't thinking in those terms. The implications did freak me out a bit, once I took the job, and though I didn't have the power to do much about it structurally, I could do some things to improve password security. So I had a dedicated (dating myself here) Pentium Pro Linux server that did nothing but run password attacks on our entire authentication database. On top of that was some automation I wrote that, once an account's password was guessed, would send automated e-mails, daily, to the account holder and their manager. If the password wasn't fixed in a week, then their account would be automatically expired, forcing them to pick a new password. The system didn't stop them from picking the same one as before, which people frequently did, but the automation was smart enough to expire their password again the next day without the grace period if that was done, which was annoying enough to get people to stop that practice. This was rather...unpopular...among the staff. But I had that little 'HIV Positive Report' presentation I mentioned before. I said the account I ran that report from was behind the password '1234', and that anyone in the world could have logged in, run the report, and published the results. The thought of that spooked even the most technically and security clueless medical types. Scare tactics? Yup. But sometimes scare tactics are justified.
  • JoshTriplett 9y ago
    This isn't a tangent, this is the kind of incredible on-topic story that's the highlights of an HN comments section. Have you considered writing this up as a full post somewhere?
• codinghorror 9y ago
  checking against the most common password lists (with some masking, maybe?) achieves _most_ of this, but you'd definitely need to do an offline attack to do better than that, on the order of an hour or so of GPU time per account. It wouldn't be trivial!