3 ms·

> It’s very likely that a lot of your user’s passwords are going to be cracked While I agree that peppering your passwords is good practice, this is just flat-

> It’s very likely that a lot of your user’s passwords are going to be cracked While I agree that peppering your passwords is good practice, this is just flat-out wrong - with a salted modern hash algorithm it should be cryptographically infeasible to crack passwords from a database dump, and if you are using an insecure algorithm, it is just as easy to recover the pepper as the passwords. > Very few will make any mention to how password policy plays a significant part in ensuring the security of any stored values. As a reminder, the NIST recommends enforcing only minimum length and known-vulnerable password requirements: "Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets." [1] [1] https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 https://pages.nist.gov/800-63-3/sp800-63b.html#sec5

himalayanyeeti 8y ago
To learn more about how passwords are actually secured, consider reading this blog post: https://blog.benpri.me/blog/2019/03/02/reactive-hashing/ https://blog.benpri.me/blog/2019/03/02/reactive-hashing/
- larkeith 8y ago
  Dynamically adjusting the hash count is an interesting idea (though I would strongly recommend using a better measure of entropy than password length alone), but I'm not really sure how this answers my concerns - as attackers will generally have at least one known username-password combination, it is trivial to recover the pepper if the database is not strongly enough hashed. If you use high password complexity as an excuse to lower hash counts, you only make it easier for attackers to recover the pepper. It also doesn't really address the root failure of password policies, in that many users will simply pad passwords with required characters and/or be more likely reuse a single password that fulfills standard requirements. Comparison against lists of compromised/vulnerable passwords remain a better way to ensure complexity, preferably in combination with a password strength meter.

himalayanyeeti 8y ago

To learn more about how passwords are actually secured, consider reading this blog post: https://blog.benpri.me/blog/2019/03/02/reactive-hashing/ https://blog.benpri.me/blog/2019/03/02/reactive-hashing/

larkeith 8y ago
Dynamically adjusting the hash count is an interesting idea (though I would strongly recommend using a better measure of entropy than password length alone), but I'm not really sure how this answers my concerns - as attackers will generally have at least one known username-password combination, it is trivial to recover the pepper if the database is not strongly enough hashed. If you use high password complexity as an excuse to lower hash counts, you only make it easier for attackers to recover the pepper. It also doesn't really address the root failure of password policies, in that many users will simply pad passwords with required characters and/or be more likely reuse a single password that fulfills standard requirements. Comparison against lists of compromised/vulnerable passwords remain a better way to ensure complexity, preferably in combination with a password strength meter.