Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump • Hacker News Board

Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

#11

Post by afreak » Mon, Jun 20, 2016, 8:59 PM UTC

sgarman wrote: post #9

afreak wrote: post #2

Any developer today that is developing an application and isn't using something like Argon2, Bcrypt, or Scrypt should be considering a plan to move away from whatever they're currently using yesterday. There is no reason to be using anything less than those three and continued use is in my mind negligence. If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for a…

Most of the attacks described in this article are not solved by any of those though right? They protect against hacking one person but if you just do these advanced dictionary attacks you can still crack people with weak passwords. Maybe I'm missing something?

No. You cannot effectively use the techniques you can use against SHA/MD5 to attack the three I mentioned.

SHA and MD5 can be calculated entirely in a CPU's registers without having to rely on RAM. Bcrypt for example requires the use of a matrix as part of its calculation, slowing down the process. A GPU has so few channels from the processor to memory that it cannot be effectively done in parallel.

All one has to do with Bcrypt is just adjust the difficulty and any advances in GPU technology or whatever can be nullified.

Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

#12

Post by sgarman » Mon, Jun 20, 2016, 9:08 PM UTC

afreak wrote: post #11

sgarman wrote: post #9

Earlier quoted context omitted.

Most of the attacks described in this article are not solved by any of those though right? They protect against hacking one person but if you just do these advanced dictionary attacks you can still crack people with weak passwords. Maybe I'm missing something?

No. You cannot effectively use the techniques you can use against SHA/MD5 to attack the three I mentioned. SHA and MD5 can be calculated entirely in a CPU's registers without having to rely on RAM. Bcrypt for example requires the use of a matrix as part of its calculation, slowing down the process. A GPU has so few channels from the processor to memory that it cannot be effectively done in parallel. All one has to do…

Thanks. I thought I saw an article about a recent leak with salted bcrypted passwords where they cracked weak passwords. The conclusion was there is no way to prevent a weak password from being compromised so to prevent it require longer more complicated passwords.

Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

#13

Post by mikeokner » Mon, Jun 20, 2016, 9:09 PM UTC

sgarman wrote: post #9

afreak wrote: post #2

Any developer today that is developing an application and isn't using something like Argon2, Bcrypt, or Scrypt should be considering a plan to move away from whatever they're currently using yesterday. There is no reason to be using anything less than those three and continued use is in my mind negligence. If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for a…

Most of the attacks described in this article are not solved by any of those though right? They protect against hacking one person but if you just do these advanced dictionary attacks you can still crack people with weak passwords. Maybe I'm missing something?

bcrypt uses unique salts per-password. The hash outputted by the bcrypt function is actually several delimited fields that have been joined into a single string.

This means that if multiple users use a common password like 'pass123', the hashes stored in the database will still each be unique. Any attacker trying to reverse all of the password hashes will have to reverse every single one individually in a targeted manner rather than using pre-computed rainbow tables or generating hashes from a wordlist and scanning the database for matching hashes.

Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

#14

Post by jlgaddis » Mon, Jun 20, 2016, 9:09 PM UTC

pellej_s wrote: post #8

Yes, sure. You should not be using anything but Bcrypt et al for passwords (salt, salt, salt!) – but... Out of curiosity. What if these passwords were SHA-512 hashed (unsalted) rather than SHA1? Anyone know of comparable articles?

(cuda)hashcat can do SHA512 just fine, too.

Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

#15

Post by miles » Mon, Jun 20, 2016, 9:27 PM UTC

From a comment by giveen[1] on reddit earlier:

"At hashes.org, 87% completed https://hashes.org/public.php "

There are loads of cracked hashes from other public leaks as well at hashes.org - worth adding these to your pen testing dictionaries.

[1] https://www.reddit.com/r/netsec/comments/4ozdz8/introduction...

Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

#16

Post by afreak » Mon, Jun 20, 2016, 9:28 PM UTC

sgarman wrote: post #12

afreak wrote: post #11

Earlier quoted context omitted.

No. You cannot effectively use the techniques you can use against SHA/MD5 to attack the three I mentioned. SHA and MD5 can be calculated entirely in a CPU's registers without having to rely on RAM. Bcrypt for example requires the use of a matrix as part of its calculation, slowing down the process. A GPU has so few channels from the processor to memory that it cannot be effectively done in parallel. All one has to do…

Thanks. I thought I saw an article about a recent leak with salted bcrypted passwords where they cracked weak passwords. The conclusion was there is no way to prevent a weak password from being compromised so to prevent it require longer more complicated passwords.

A weak password is a weak password no matter how good the hashing is. I think that you're referring to this bit from last year:

http://www.pxdojo.net/2015/08/what-i-learned-from-cracking-4...

The author of this piece was doing about 156 hashes per second and after just over five days, he had only gone through and cracked 4,000 account passwords--we're talking 0.0001% of Ashley Madison's supposed userbase here. To run just over the 14,000,000 passwords from RockYou.txt on every single user account from AM, it would take up to at least two billion years.

Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

#17

Post by simik » Mon, Jun 20, 2016, 9:29 PM UTC

pellej_s wrote: post #8

Yes, sure. You should not be using anything but Bcrypt et al for passwords (salt, salt, salt!) – but... Out of curiosity. What if these passwords were SHA-512 hashed (unsalted) rather than SHA1? Anyone know of comparable articles?

SHA-512 would be just 7-8 times slower. Not much of an improvement. Check hashcat's page for performance figures:

https://hashcat.net/oclhashcat/#performance

Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

#18

Post by gervase » Mon, Jun 20, 2016, 9:32 PM UTC

jacquesm wrote: post #4

85% cracked in a few days is seriously depressing. What does a box like the one mentioned in the article cost? Any estimate on the time to crack the remaining 15%?

At some point, the cracker is going to reach diminishing returns.

Presumably some fraction of the remaining 15% will be completely random, from people using password managers or similar. These could only be cracked by brute force (assuming they are truly random), and since they're also likely longer, it's unlikely they would be cracked any time soon - they're just not worth the computational investment to the cracker.

Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

#19

Post by afreak » Mon, Jun 20, 2016, 9:36 PM UTC

pellej_s wrote: post #8

Yes, sure. You should not be using anything but Bcrypt et al for passwords (salt, salt, salt!) – but... Out of curiosity. What if these passwords were SHA-512 hashed (unsalted) rather than SHA1? Anyone know of comparable articles?

As part of a presentation I did at a local OWASP chapter, here are some numbers based on just using CPython's Hashlib processing of 14,000,000 someodd passwords:

Intel Xeon E5-1620 3.6 GHz: SHA: 8.16 seconds, SHA256: 11.01 seconds, MD5: 8.7 seconds

AMD FX-8320 3.5 GHz: SHA: 10.63 seconds, SHA256: 13.49 seconds, MD5: 10.06 second

Intel Celeron N2840 2.2 GHz: SHA: 32.4 seconds, SHA256: 39.75 seconds, MD5: 28.95 seconds

Intel Pentium M 1.7 GHz: SHA: 37.98 seconds, SHA256: 48.12 seconds, MD5: 34.49 seconds

SHA512 isn't going to make it much better.

Re: Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

#20

Post by xyience » Mon, Jun 20, 2016, 9:38 PM UTC

sgarman wrote: post #12

afreak wrote: post #11

Earlier quoted context omitted.

No. You cannot effectively use the techniques you can use against SHA/MD5 to attack the three I mentioned. SHA and MD5 can be calculated entirely in a CPU's registers without having to rely on RAM. Bcrypt for example requires the use of a matrix as part of its calculation, slowing down the process. A GPU has so few channels from the processor to memory that it cannot be effectively done in parallel. All one has to do…

Thanks. I thought I saw an article about a recent leak with salted bcrypted passwords where they cracked weak passwords. The conclusion was there is no way to prevent a weak password from being compromised so to prevent it require longer more complicated passwords.

Weak passwords are still weak, but things like bcrypt buy you time. A bcrypt configuration might have hashing take 250ms on a server's Xeon CPU (as opposed to nanoseconds with a sha-based hash). You can try the password 'password' on say 50k hashes that were dumped, but it will take about 3.5 hours. You can get this time down by parallelizing or with better hardware like GPUs / FPGAs / ASICs, but you're still looking at a base time of 3.5 hours per attempt to go through each account. Or if you're only targeting one account, 3.5 hours to try 50k words.

If the server had bcrypt configured to take a second per password, multiple everything by 4. And so on. What I think is needed as a supplement to "use bcrypt / scrypt" is a "and use it this way so you don't accidentally open your server to DoSing or give a poor experience", because a 10 seconds-to-compute-on-a-Xeon hash is great from a security standpoint if your hashes get leaked, it sucks from a user experience to have to wait at least 10 seconds to login, and if you have to service multiple logins at once your server's not going to be able to do anything else if you just use bcrypt/scrypt synchronously.