Follow Slashdot stories on Twitter


Forgot your password?
Encryption Security IT

New 25-GPU Monster Devours Strong Passwords In Minutes 330

chicksdaddy writes "A presentation at the Passwords^12 Conference in Oslo, Norway (slides), has moved the goalposts on password cracking yet again. Speaking on Monday, researcher Jeremi Gosney (a.k.a epixoip) demonstrated a rig that leveraged the Open Computing Language (OpenCL) framework and a technology known as Virtual Open Cluster (VCL) to run the HashCat password cracking program across a cluster of five, 4U servers equipped with 25 AMD Radeon GPUs communicating at 10 Gbps and 20 Gbps over Infiniband switched fabric. Gosney's system elevates password cracking to the next level, and effectively renders even the strongest passwords protected with weaker encryption algorithms, like Microsoft's LM and NTLM, obsolete. In a test, the researcher's system was able to generate 348 billion NTLM password hash checks per second. That renders even the most secure password vulnerable to compute-intensive brute force and wordlist (or dictionary) attacks. A 14 character Windows XP password hashed using LM for example, would fall in just six minutes, said Per Thorsheim, organizer of the Passwords^12 Conference. For some context: In June, Poul-Henning Kamp, creator of the md5crypt() function used by FreeBSD and other, Linux-based operating systems, was forced to acknowledge that the hashing function is no longer suitable for production use — a victim of GPU-powered systems that could perform 'close to 1 million checks per second on COTS (commercial off the shelf) GPU hardware,' he wrote. Gosney's cluster cranks out more than 77 million brute force attempts per second against MD5crypt."
This discussion has been archived. No new comments can be posted.

New 25-GPU Monster Devours Strong Passwords In Minutes

Comments Filter:
  • Re:"Strong" (Score:5, Interesting)

    by dkf ( 304284 ) <> on Wednesday December 05, 2012 @06:55AM (#42189957) Homepage

    For comparison, the password to an account I use fairly often is 128 characters.

    That must be annoying to type in every time.

    More seriously, if that's a password but the system in question is only storing a relatively short hash of it, all the attacker has to do is find something that hashes to the same thing. That's pretty simple to do if you've got the grunt compute power, as there's usually no other checks on the sense of a password at the point of use (which isn't the same as the point of definition). In effect, you're not hindering attackers at all but you are making things worse for yourself. Congratulations on your addition to Security Theater! With thinking like that, you're almost qualified to work for the TSA...

    (Myself? I disable logins with passwords wherever I can. Turn up with a cryptographic key — the verification of which is not a hashing operation at all — or don't turn up at all.)

  • Re:Time delay? (Score:5, Interesting)

    by ledow ( 319597 ) on Wednesday December 05, 2012 @07:03AM (#42189991) Homepage

    This isn't about live attacks on a system. This is about "offline" attacks and even things like hash collisions (where someone can make a certificate or a download that has the same hash as the "official" one but is fake or contains malware, etc.).

    If you can take a login system and run millions of queries against it, it's a stupid system. But if you can steal a hashed file of password, or old hashed tokens from the network, then you can theoretically break them now in the time it takes to reboot the computer (if you could log into this other system remotely).

    Things like the Sony break-in would reveal everyone's password, not just the other stolen details. And on a local network, you could sniff tokens sent for NTLM services etc. and start impersonating other users before it could even be detected. Of course you have to have a certain level of compromise / access already to get to that stage, but it doesn't make it any less dangerous to be able to forge hashes or find out their plain-text.

    Please note, also, that things like these hashes have been used historically to verify software is genuine, as part of encryption algorithms, random number generators and all sorts of other things. At the time, they were reasonably unbreakable, but now they aren't. And that breaks lots of things if they are still relying on them.

    Impact to security-conscious users: Zip.
    Impact to security-unconscious users: Huge.

  • by Architect_sasyr ( 938685 ) on Wednesday December 05, 2012 @07:38AM (#42190107)

    If you already have access to that system it's fairly trivial to install password capturing code.

    The whole point is to engage in defence in depth - FreeBSD offers kern.securelevel to prevent you from being able to write to the file system, or change firewall rules. We have anti rootkit checking programs (do most people make regular use of rkhunter or anything similar?) Further, you need to encrypt and safely store backups. No password logging program is going to lift them from the hashes you got from the borrowed backup drives. Probably 60% of engagements I have been involved in managed to lift a backup drive from the environment, permitting only the tiniest changes to be made to live servers, thus minimising our risk of breaking things, and a (potential) black-hat's chance of being caught.

    Making the hashes harder to crack makes it harder to crack into the server, live or from backups. You'd be surprised how many people forget backups.

  • by Phoenix ( 2762 ) on Wednesday December 05, 2012 @08:20AM (#42190303)

    If passwords are getting cracked so quickly these days, what then is the answer? Authenticators are all well and good, but I don't have room on my keychain for one for Blizzard (I know about and have the one for my iPhone), one for Amazon, one for PayPal and eBay, one for Gmail, etc and so forth.

    What would be a viable solution then?

  • by Rich0 ( 548339 ) on Wednesday December 05, 2012 @08:45AM (#42190451) Homepage

    I'd echo the other suggestion to use lastpass. I was struggling with the same issues. In theory the passwords are encrypted/decrypted locally and they do not have access to them. Of course, I'm sure they could be bruteforced as with any of the other sites. That said, I am a bit more inclined to trust one site whose sole purpose is storing passwords than every web forum on the internet. These days most of my passwords are randomly generated thanks to lastpass.

    The real pain has been with smartphone apps, which don't integrate well with lastpass. I can access my passwords on the phone, but I have to do copy/paste to get the password into the app, and some apps are brain-dead and reset when context-switching which means I need to at least manually enter the username (which is a pita if it is a long email address).

    People also point out keepass, but it doesn't support every OS I use. Lastpass always has the browser as a fallback if nothing else.

  • by bmo ( 77928 ) on Wednesday December 05, 2012 @09:01AM (#42190567)

    >They that is account provider can easily use delays and lockout an account after too many tries.

    Not lock out an account.

    Temporary ban an IP address. Fail2ban does this. If you're just looking to protect SSH, use Denyhosts.

    You don't want to lock out legitimate users. All the big providers like Yahoo and Facebook will let you keep trying at a password 3 times, and then they'll throw a captcha at you for all tries after that with as many tries as you want, because you have to keep solving the captcha for each attempt. Current captcha technology is pretty much bot proof - almost human proof sometimes, it seems (as a user, I hate captcha and knowing someone who is sight impaired, I consider it offensive - we should find something else, something better).

    Locking out accounts over bad login attempts generates too many support calls and upset users, because you could DOS attack an account simply by spamming the login with bad passwords. It's been tried. It sucks as a solution. The solution is to make brute-forcing time consuming and requiring human intervention.


  • by Rich0 ( 548339 ) on Wednesday December 05, 2012 @09:36AM (#42190811) Homepage

    That episode is the main reason why I've stuck with them - I was a customer at that time.

    When that breach occurred nobody knew about it but them, but they immediately broke the news and generally treated the situation in the most conservative manner possible. Their treat assessments as communicated out seemed accurate to me.

    So, sure, you're more secure if you never put your passwords out in the cloud to begin with - nobody can question that (assuming you still use strong unique passwords for each site and just carry them around with you on a PDA or USB drive or something). However, if you are going to use a cloud service then would you rather use one that has an episode like this and does full disclosure, or one that puts the marketers in charge and covers the whole thing up? The only reason you can cite that example is because Lastpass did the right thing.

    If the alternative is to just pick a few memorable passwords and use them on many websites each, I'm not convinced you're better off.

  • Re:"Strong" (Score:5, Interesting)

    by fatphil ( 181876 ) on Wednesday December 05, 2012 @09:38AM (#42190817) Homepage
    > You're propagating security through bogosity.

    And flagging this:

    Snake Oil Warning Signs

    Warning Sign #5: Ridiculous key lengths.

"I'm not afraid of dying, I just don't want to be there when it happens." -- Woody Allen