5 ms·
Assume their salt+hash database leaks. It's true that salting the passwords and using bcrypt would prevent mass cracking of the database (i.e. you would have to
by OskarS 10y ago
Assume their salt+hash database leaks. It's true that salting the passwords and using bcrypt would prevent mass cracking of the database (i.e. you would have to crack each password individually, not the entire database at once), it would still be feasible to crack a single user's password if it was weak enough (which would be worth it, if the user is, say, president@whitehose.gov).
Using pepper prevents that from happening, and storing it separately from your database makes it much harder to get both.
- Achshar 10y ago> it would still be feasible to crack a single user's password if it was weak enough I'm sorry, but how? You'd need data centers worth of effort for many years.
- OskarS 10y agoThey say that the bcrypt hashing takes 100 ms on their servers. If we take that as our limitations, it means we can try 10 passwords per second. So if you had a dictionary of common passwords, plus the salt, you could try 36000 passwords per hour. If the password is "password12345" (hence "weak enough"), you could feasibly crack that. (I should say I'm not a professional security engineer so I'm probably wrong about everything and would appreciate corrections. )
- Someone1234 10y agoGreat analysis (that in my experience is largely accurate). Just want to tack on one footnote: 100 ms is based on a single CPU core. Most CPUs have 4-8 cores. So instead of 10 passwords a second you could argue 40-80 passwords a second is believable with concurrent operations (which all popular hash cracking software supports). It is definitely viable to break a single user's hashed password no matter what the scheme or work factor. Strong hashing algorithms with high work factors just stop you breaking multiple user's passwords quickly (and gives you 1-3 days of delay). It is a stop gap, not impenetrable defence like some believe. All technical people need to take a day and learn how to break password hashes. Not just the theory, but go download the software and actually do it.
- ZoFreX 10y ago> Not just the theory, but go download the software and actually do it. And now that hashcat and oclhashcat have merged[1] and are open-source[2] it's never been easier to install hashcat and start cracking passwords! [1] https://hashcat.net/forum/thread-5559.html https://hashcat.net/forum/thread-5559.html [2] https://hashcat.net/forum/thread-4880.html https://hashcat.net/forum/thread-4880.html
- Dylan16807 10y agoSpecifically, if you took the top 10k passwords from this blog post as a starting point you would be able to crack "password123" in under a minute.
- raverbashing 10y agoBcrypt with a high work factor is useless if your password is still 12345
- ZoFreX 10y agoAn additional thought: Even if you can't crack a bcrypt hash (say they picked a sufficiently complex password), you can still verify it given a particular plaintext password. So you could go through a database and discover users that are using the same password in that DB as they are on some other sites that leaked weaker hashes, for example. If the hashes you get access to are encrypted, you can't even verify them given a known plaintext password. It's a marginal, but not non-existent improvement.
- LgWoodenBadger 10y agoI'm pretty sure this is what a salt prevents.
- ZoFreX 10y agoNo - salts mean that the same password hashed twice will give different results, which prevents the use of lookup tables, and trivially discovering users with the same passwords. Given a hash and a salt, you can still verify what the password was.
- crpatino 10y agoThere is no reason to believe that other sites will pick the same salt for each user, unless they are deriving it from either the password itself, the user id, or some other piece of user private info; which would be bad form anyways. If you are not using salt, you are vulnerable to rainbow attacks within the same database.