5 ms·
In practical terms, that's still not very many. GPUs can do 2 GH/s for a simple hashing function. Your 44 bit password can be cracked in 4 hours by a single GPU
by Taek 9y ago
In practical terms, that's still not very many. GPUs can do 2 GH/s for a simple hashing function. Your 44 bit password can be cracked in 4 hours by a single GPU, or in minutes by a cluster.
A large KDF helps, but damages user experience and again starts to become fragile if your threat model includes ASICs (a $3m expense or so for an attacker. That's a practical sum for many applications).
To put things in perspective, a CPU can do about 2^20 hashes per second. A $3m ASIC cluster (made entirely from scratch) can do about 2^52 hashes per second. It's obscenely asymmetric.
For high security accounts, you really want like 64 bits of entropy in your password plus a KDF, or you want 80 bits without a KDF.
KDFs have another major problem. If you forget a word in your password, and you also have a KDF, you have to fight your own KDF to discover that last word. You don't want that barrier.
edit: was off by a factor of 1000 in my ASIC math. $3m in ASICs can do about 2^52 hashes per second, not 2^42
- yflu 9y agoThen I add another word or two and make that 44 bits 55 or 66 bits. The strategy itself still works, even if the particular details of implementation change.
- Ajedi32 9y agoThe XKCD comic includes this note: > 1000 Guesses/Sec (Plausible attack on a weak remote web service. Yes, cracking a stolen hash is faster, but it's not what the average user should worry about.)
- tempay 9y agoProvided they don't use the same password for several services
- Ajedi32 9y agoIn which case, sooner or later they'll probably end up using the password on a site that stores passwords in plaintext, and after that no amount of entropy will help.
- jandrese 9y agoOr the website hashes the password, and then stores a plaintext (or weakly encrypted) copy in the database as well so they can make sure you don't use a "similar" password on the next change. And in fact keep like 30 passwords in the database so hackers can get a good sense of how you construct your passwords. All for better security of course.
- sersi 9y agoOh that'd be a treasure trove for security researchers. I think we should work on an opensource gem or plugin for cakephp that does this and hope a website uses it. It would be very good data for research into the psychology of choosing passwords. Just imagine all the potential findings!
- tome 9y ago> For high security accounts, you really want like 2^64 bits of entropy in your password plus a KDF, or you want 2^80 bits without a KDF. I think you mean 64 bits and 80 bits!
- Taek 9y agoOops. Fixed.
- ykler 9y agoThis is wrong assuming, as is recommended practice, you use a hashing function like bcrypt or scrypt that is designed to be resistant against massive ASIC speedups, right?
- Bartweiss 9y agoI wouldn't call it wrong, but I agree that it's for fast hashes without salts. Since sites still use that (and we can't check what they're using pre-leak) it's still relevant, though.
- marcosdumay 9y ago> you have to fight your own KDF to discover that last word. You don't want that barrier. You pretty much want it. Why would you make your password easy to brute force so that you can recover it in case you forget it? This makes no sense. A 6 word phrase reaches your 64 bits target (on the GP's 2-48 word dictionary). It is still easier to remember than a base64 dump of a 64 bits random number. I still fail to see anything wrong with passphrases.
- Taek 9y ago8 words is enough without a KDF. If you know 7 of the 8 words and there is a KDF, you might not be able to figure out which word is wrong or missing. But if there is no KDF you may be able to forget up to even 3 words. Being able to brute Force your own password is a good thing if you can at least depend on knowing most of it.
- corobo 9y agoDon't sites also salt (and pepper?) passwords though? Does this still apply in the scenario that they have done so? Edit: Realised Google exists, currently reading https://stackoverflow.com/questions/16891729/best-practices-salting-peppering-passwords https://stackoverflow.com/questions/16891729/best-practices-...
- Bartweiss 9y agoThat math is for fast hashes without salting, agreed. Of course, plenty of sites that lose passwords also make those mistakes...
- dspillett 9y ago> Don't sites also salt (and pepper?) passwords though? They should salt. They should do many things. But we know some sites don't, we suspect many sites don't. Unless you know otherwise never assume a site is handling your data, including your login credentials, securely.