3 ms·
> The "vast majority of developers" should not be implementing login systems, period. Yep, agree. This also supports the idea that you shouldn't get too hung u
by fractionalhare 6y ago
> The "vast majority of developers" should not be implementing login systems, period.
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.
- luizfelberti 6y agoI originally used categorically to mean "unambiguously explicit and direct", but adding to what you said (with which I mostly agree), Scrypt actually does provide a categorical increment to security by being ASIC-resilient. There are differences among them between classes of attacks they're susceptible to, provable security properties, and how paranoid should you should be in respect to advances cryptanalysis. I tend to weigh these as significant factors given that the dynamics of password-based auth can very well lead to a database leak screwing someone over 20 years into the future, although I admit that you can't get too picky nowadays and I'd be very glad if we, as a species, could have what you described as a lower-bound (with the exception of PBKDF2, of course :P)