11–20 of 27 posts
Earlier quoted context omitted.
Scrypt isn't an option on memory constrained devices.
Password hashing is done server side, the client only needs to worry about TLS. Are you thinking about some specific use case? Also, it's not a good idea to base your security parameters on the compute power of the most underpowered device in the chain.
Step 1) Use Scrypt instead Step 2) There is no step 2
For the vast majority of developers, bcrypt, scrypt, argon and PBKDF2 provide functionally equivalent security. It's not generally productive to nitpick between secure password hashing/key derivation functions. Unless you specifically know you can't use one of these in particular, you should just pick whichever one has a safe implementation in a secure cryptographic library that you can use. Basically, just don't use…
> For the vast majority of developers, bcrypt, scrypt, argon and PBKDF2 provide functionally equivalent security
1) The "vast majority of developers" should not be implementing login systems, period. The chances most people have of not falling for any OWASP gotcha, making sound security choices, and implementing them correctly, is pretty much nil. Leveling the argument to this makes many things that should not be done sound passable.
2) They do not, categorically, provide "functionally equivalent security" (especially not for bare PBKDF2). This is a myth people believe in because they normalize their perception of deviant behaviour[0], and frame the situation as "if my database never gets pwned, any one of these is fine", which is just an argument based on wishful thinking, akin to "I can drive recklessly as long as I don't crash", but we don't use this reasoning to nullify seat-belts: the choice of algorithm is important precisely, and perhaps exclusively, for when all your other security mechanisms failed.
The reality though, is that more often than not, when databases gets pwned you never find out about it because monitoring and security practices is often lackluster, and then you keep believing that these things don't matter.
[0] https://en.wikipedia.org/wiki/Normalization_of_deviance
As a general rule for their security properties: Scrypt > Argon2 > Bcrypt, and PBKDF2 should be avoided. You should prefer the first one of these you can find with a robust implementation (which as @lanecwagner pointed out may not always be Scrypt, and that's fine, as is Bcrypt if you have implementation constraints)
> Why not compare passwords directly? Back in the days before hashed or encrypted passwords, there was an interesting security hole in TOPS-10 on the PDP-10 due to direct password comparison. Guess the password "aaaaaaaa", but put it in memory so that a page boundary falls between the first and second "a", and the second page is not resident. TOP-10 allowed a user process to ask to handle its own page faults. Do that…
Step 1) Use Scrypt instead Step 2) There is no step 2
Assuming you can find a battle testing implementation
If you're on Golang, Rust, or C though: leverage your options!
> Why not compare passwords directly? Back in the days before hashed or encrypted passwords, there was an interesting security hole in TOPS-10 on the PDP-10 due to direct password comparison. Guess the password "aaaaaaaa", but put it in memory so that a page boundary falls between the first and second "a", and the second page is not resident. TOP-10 allowed a user process to ask to handle its own page faults. Do that…
Earlier quoted context omitted.
For the vast majority of developers, bcrypt, scrypt, argon and PBKDF2 provide functionally equivalent security. It's not generally productive to nitpick between secure password hashing/key derivation functions. Unless you specifically know you can't use one of these in particular, you should just pick whichever one has a safe implementation in a secure cryptographic library that you can use. Basically, just don't use…
While I agree with the sentiment of what you're saying, I take issue with this part specifically: > For the vast majority of developers, bcrypt, scrypt, argon and PBKDF2 provide functionally equivalent security 1) The "vast majority of developers" should not be implementing login systems, period. The chances most people have of not falling for any OWASP gotcha, making sound security choices, and implementing them cor…
Because password may be thought of as a first line of defense, folks have trouble with the notion of your password encryption being the last line of defense.
There are quite a few things we do that “bookend” other operations. I’ve certainly seen my fair share of people getting those wrong too (eg, teardown should often happen in the reverse order of setup, FILO)
Earlier quoted context omitted.
Password hashing is done server side, the client only needs to worry about TLS. Are you thinking about some specific use case? Also, it's not a good idea to base your security parameters on the compute power of the most underpowered device in the chain.
Devices that need access restrictions without network connectivity have to use something to protect credentials. You can't hand wave your way out of that.
That being said, for these cases you could use Argon2 which is mostly (entirely?) based on ARX constructs and will work well on embedded/underpowered devices
There are also some symmetric encryption shenanigans that can be done, but if you can use something other than password-based auth you're free from pretty much all of these problems, with probably much better security
Earlier quoted context omitted.
For the vast majority of developers, bcrypt, scrypt, argon and PBKDF2 provide functionally equivalent security. It's not generally productive to nitpick between secure password hashing/key derivation functions. Unless you specifically know you can't use one of these in particular, you should just pick whichever one has a safe implementation in a secure cryptographic library that you can use. Basically, just don't use…
While I agree with the sentiment of what you're saying, I take issue with this part specifically: > For the vast majority of developers, bcrypt, scrypt, argon and PBKDF2 provide functionally equivalent security 1) The "vast majority of developers" should not be implementing login systems, period. The chances most people have of not falling for any OWASP gotcha, making sound security choices, and implementing them cor…
Yep, agree. This also supports the idea that you shouldn't get too hung up on which to use, because hopefully that decision was made for you and one of these was selected.
> They do not, categorically, provide "functionally equivalent security"
Eh, disagree, if your database is breached and your digests are salted, any of these is fine. Of course there are technical differences because these are literally different algorithms, the actual difference in security provided by each is one of degree, not category. Unhashed vs hashed, and SHA2 vs bcrypt are what I'd call differences of category.
Step 1) Use Scrypt instead Step 2) There is no step 2
Main page, including the signed tarball: http://www.tarsnap.com/scrypt.html