31–40 of 65 posts
> Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. https://github.com/P-H-C/phc-winner-argon2
So there's a bunch of people here saying Argon2, whereas I thought one of the current best recommendations was scrypt. Can someone explain the trade-off between them? Why would you pick one over the other? Or are both "pretty much fine" for most workloads and a casual user shouldn't worry too much?
bcrypt, scrypt, Argon2: it doesn't practically matter. Actual cryptographers don't stop recommending safe and well-tested algorithms just because newer ones have been published. There has been no cryptanalytic break in bcrypt or scrypt. The benefits of Argon2 are largely academic for common workloads.
For what it's worth the php implementation of password hashing offers a function to determine whether it's time to rehash a password. https://www.php.net/manual/en/function.password-needs-rehash... The idea is to alert an application program to the need to regenerate the hash at the time it has the plaintext password in hand (when the user has just presented it for login). This is a great idea; rehashing a long-stand…
PHP truly has exemplary built in security functions, other language / standard library teams should look at this in awe. It's pretty unique that a language, among its included batteries, actually makes it easy to correctly not roll your own crypto.
I always say the best piece of advice on this is, "Don't store passwords." Like shown in other comments, the landscape of what should be used changes frequently. Truthfully, I haven't had to write anything that stores passwords for several years, and until now I hadn't heard of Argon2. That's frightening to me and shows how far out of the game I am now. Finding a trusted 3rd party who's responsibility is to stay on t…
It does not. I agree with you that you shouldn't store passwords if you don't have to, but bcrypt and scrypt are still absolutely fine. You do not need to choose Argon2. Cryptographic algorithms shouldn't be deprecated just because something new came out, they should only be deprecated when there is a specific, published cryptanalysis that weakens them.
> Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. https://github.com/P-H-C/phc-winner-argon2
I have started to look at a model where the device itself is the password. How often do we realistically need to concern ourselves with the scenario where multiple users are utilizing the same physical device in 2020? Imagine every device has a cookie/token with 256-512 CSPRNG bytes which uniquely identify it. The server uses this as the exclusive means of authentication. For sensitive application scenarios, an in-ap…
(Cracking Passwords with Cheap Hardware at Defcon):
Earlier quoted context omitted.
Is there any scrypt or argon2 implementation for nodejs that has as nice an api surface as the bcrypt package? Specifically, it will generate a salt for you (included at the beginning of the generated hash). This has the great properties of: can't forget to use or store the salt; use a weak salt; or forget to use the time-safe compare function. I want to minimize the number of footguns available to the person coming…
This argon2 implementation[0] looks good to me. It uses a native module so it should be fast, and I like the look of the API. It returns the salt and params with the hash in one string, so storing and verifying looks real simple. It appears to be maintained. It has TS type declarations, if you are into that sort of thing. Here is an scrypt just in JS[1]. It will also run in the browser, if you need to hash client sid…
I think it's fine enough if I stick with bcrypt, and that's what I'm planning to do, but I saw this was on the front page, so I opportunistically made the comment hoping that someone with experience in this area (e.g. tptacek) might see the question and jump in :)
[0] https://latacora.micro.blog/2018/04/03/cryptographic-right-a...
With password storing, you want to cover your ass. One way to do it is follow guidelines of known authority, e.g. NIST or OWASP. OWASP has nice document: https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor... It boils down to this: > Bcrypt is the most widely supported of the algorithms and should be the default choice unless there are specific requirements for PBKDF2, or appropriate knowledge to tune Argon2…
Interesting how many corporate security policies act like they don't even know NIST exists. Password rotations for users are audit crown jewels but recommended against by NIST
With password storing, you want to cover your ass. One way to do it is follow guidelines of known authority, e.g. NIST or OWASP. OWASP has nice document: https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor... It boils down to this: > Bcrypt is the most widely supported of the algorithms and should be the default choice unless there are specific requirements for PBKDF2, or appropriate knowledge to tune Argon2…
Interesting how many corporate security policies act like they don't even know NIST exists. Password rotations for users are audit crown jewels but recommended against by NIST
Per wikipedia:
> From 2004, the “NIST Special Publication 800-63. Appendix A,”[2] advised people to use irregular capitalization, special characters, and at least one numeral. It also recommended changing passwords regularly, at least every 90 days. This was the advice that most systems followed, and was "baked into" a number of standards that businesses needed to follow.