4 ms·
I suspect it would be better if possible to hit a bigger list. It's not to protect against an external brute force, but a leaked database table being able to i
by kevin_nisbet 8y ago
I suspect it would be better if possible to hit a bigger list.
It's not to protect against an external brute force, but a leaked database table being able to identify valid passwords, and then using that to access the service or check other services for a shared password.
It's unfortunately far too common that a SQL injection, bad employee, lost backup, whatever leaks a copy of the account table in the database, which even when using scrypt/bcrypt etc is plausible to slowly break accounts beyond the first few thousand common passwords. Depending on work factors, it's about 250ms to make a guess, which is about 345,000 guesses per cpu/core per day.
- joshuak 8y agoAdding a salt to the password before its hashed is the way to handle this type of attack. In general I'd say that most organizations need to get less fancy about password security not more. Most mechanisms that companies employ to make things more secure don't. They make things less secure because they add attack surface, or they fail to account for the behavior of actual users when faced with any additional effort. For example: https://ai.google/research/pubs/pub43783 https://ai.google/research/pubs/pub43783
- kevin_nisbet 8y agoI would point you to latacora's updated recommendations about password handling: https://latacora.singles/2018/04/03/cryptographic-right-answers.html https://latacora.singles/2018/04/03/cryptographic-right-answ... Adding a salt and hashing a password is not something someone should be doing in 2018. Use scrypt, or another one of the recommended algorithms, as it is a complete implementation that is well researched and can be simply dropped into most systems. And my response was in reference to how many password you should blacklist, which using a good algorithm is still feasible to brute force easy to guess passwords in an offline attack.