4 ms·
That's good. However, if a good proportion of people use one of the 1,000 most common passwords, then they can hack those accounts in the time it takes to comp
by mdasen 14y ago
That's good. However, if a good proportion of people use one of the 1,000 most common passwords, then they can hack those accounts in the time it takes to compute 50M * 1,000 hashes. With CUDA, it seems that you can do hundreds of millions per second. At 100,000,000 per second, you could compute that in 500 seconds (under 10 minutes). http://www.golubev.com/hashgpu.htm http://www.golubev.com/hashgpu.htm - this claims into the billions per second.
When were talking 5B tries per second, that means trying the most common 100,000 passwords against each of the 50M accounts in under 20 minutes. The most common 1,000,000 passwords against all 50M accounts in under 3 hours; the most common 10M passwords against all 50M accounts in a little over a day.
Hashing is good, salting is better, but unless there was a work factor involved like PBKDF2, bcrypt, or scrypt, it seems like it's protection against people who don't know what they're doing more than against people who know what they're doing. I'm not the type to say that we need to protect against people who have the money to make ASICs (app-specific integrated circuits likely used by governments), but I do think protection against nVidia chips is warranted.
Now, it's genuinely possible that by "hashed and salted", they mean they used bcrypt or PBKDF2 (and simply aren't giving details in the email). But, if it's a salted SHA1, I think phishing would be harder than cracking a substantial proportion of them.
- EvanKelly 14y agoMaybe I'm misunderstanding (entirely possible!) and I think your point still stands, but isn't it 50M * 1,000 hashes * # of possible salts? EDIT: Just realized that the salts have to be stored somewhere and the attacker probably grabbed those as well. I think that answers my question.
- mpyne 14y agoNo, because the salt is stored with the password. Salts are used to defend against reversing a password hash into a password, but they don't appreciably impede bruteforcing passwords into hashes.
- nwh 14y agoIt does mean that for a large dictionary attack things will go a lot slower. Rather than one computing one hash and comparing it to 50M hashes, the same word must be hashed with 50M different salts and then compared with their respective hashes.
- mpyne 14y agoThat's a more specific way of phrasing reversing the hash into a password, yes. ;)
- hexonexxon 14y agoYou can rent miners on the bitcoin network to use their pooled hashrate to break passwords, same with moxie's service cloudcracker.com
- rmc 14y agoSalts are used to make rainbow tables useless.
- twistedpair 14y agoI'm curious why I've never heard anyone suggesting to make a public/private key pair, burn the the private key, and just encrypt passwords with the public key as your hashing function. Short of finding an exploit in GPG, you'd have to crack the public key used which would be near impossible if a long key was used. This assumes you keep that key safe. So why not literally make a key pair and throw away the key?
- pindi 14y agoA similar method is a "pepper", a form of salt common to all users and stored in the application configuration, allowing the passwords to resist attack even if the hash and user-specific salt are lost. The reason it's not often used is that the assumption is that if your database is compromised, any other commonly-used secret keys on the server will be too. It can be useful for defense in depth, though.
- marshray 14y agoSerious question: How is "pepper" any different than encrypting a traditional salted hash using a symmetric cipher as if it were any other kind of data?
- babuskov 14y agoMaybe because encryption using public key is much more CPU intensive and slower than hashing? Since you have users logging into the system all the time, you would need to encrypt the typed password in order to compare it with the record in the database, and this could put a great load on the server CPU if you have many users logging in.
- Evbn 14y agoThat is the goal. Slower hashing is harder to crack, is more secure. Login load is nothing compared to the rest of the app.
- CoffeeDregs 14y agoSounds as if you're suggesting increasing the work for the encryption/decryption? If so, there are well known ways of increasing the work and they're designed specifically for hashing [this kind of data]. I suspect the reason people haven't used pub/priv for such uses is that there are better algorithms for it.
- vog 14y ago> ... then they can hack those accounts in the time it takes to compute 50M 1,000 hashes* That's why you might want to use Bcrypt instead of SHA-1 or SHA-256. https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/Bcrypt