Hacker News new | ask | show | jobs
by kaiju0 1942 days ago
SHA and MD are fast hashers. You want slow hashers for password security like b-crypt and s-crypt.
2 comments

PBKDF2 is a slow algorithm specifically created for password hashing. It's in the same family as bcrypt and scrypt.
> PBKDF2 is a slow algorithm specifically created for password hashing.

Yeah, over 20 years ago. It's woefully out of date by modern standards.

PBKDF2 doesn't even attempt memory hardness, so there are whole classes of attacks on later generation slow hashing algorithms that don't even apply to PBKDF2 because of how old it is. Argon2 is extremely resistant to Time-Memory-Trade-Off (TMTO) attacks, which older algorithms like bcrypt and scrypt are vulnerable to.

PBKDF2 is essentially a linear slowdown, which is effectively pointless these days.

Math doesn't age. Cheers.

bcrypt and scrypt, the successors to PKDF2, are both more than a decade old.

RSA is half a century old and it's still up to date by modern standards. In fact nobody has came up with anything better.

Edit: Actually, bcrypt might be as far as 1999, possibly older than PBKDF2.

> RSA is half a century old and it's still up to date by modern standards. In fact nobody has came up with anything better.

RSA is currently a minefield of gotchas and few security companies even get it right. Just generating a good key is actually a very difficult task. It is also very computationally slow and has many practical issues for the level of security it provides.

There are many superior replacements in both pqc and elliptic spaces. I would take EdDSA over rsa-pss any day of the week.

RSA is extremely simple, it's just multiplications and powers. It can be reasonably explained to high school students. The tooling is mature and keys are trivial to generate safely with a openssl command.

EdDSA is another level entirely. I don't know how you can recommend elliptic curve cryptography with a straight face if you think RSA is hard.

P.S. It's a myth that EdDSA is faster. This depends on operation (signing vs verification) and key size.

Elliptic curves are also quite simple. Computing a public key boils down to point addition with a modulus.

The private key is a byte string and the quality of it only depends on the random generator. It’s trivially fast to generate 32 bytes of decent quality random numbers these days. There are many insecure rsa generation methods with weak criteria. Too many are fossilized in libraries and crypto cores. Rsa also has half a dozen padding schemes and most are now considered weak or vulnerable.

EC is generally considered much stronger for a much smaller key size.

Note that we are talking about a single RSA operation. So attacks that require repeated trials are not relevant here.
> essentially a linear slowdown

Why does it have to be linear? Just use 1M irritations today, 2M irritations next year, 4M irritations the year after that, and you'll have an exponential version of it.

You can even take your 1M irritated hashes from this year and execute an additional 1M more irritations on them to update them to 2M irritations when you want to upgrade.

Doesn't PBKDF2 fix that as long as you use a very large number of irritations?
In theory, absolutely.

In practice, bitwarden's server limits the max iteration count on a user account to something that remains insecure. They refuse to fix it.

https://github.com/bitwarden/server/issues/589

What do you think about this reply on that thread? https://github.com/bitwarden/server/issues/589#issuecomment-...
For me is not a big deal. If your password is Hunter22 than you have bigger problems than PBKDF. It doesn't matter if they PBKDF it 30 milion times. Longer passwords are harder to crack and I still don't understand why people not using passphrases in their passwords.

Having 2fa enabled on all other accounts it makes me sleep better if somehow one day BW or any other password manager gets compromised.

Use a longer and more complex master password. You're welcome.
You're the sixth person to reply to me with this "advice". My own password is 30 characters and I self-host bitwarden_rs, patched to permit a higher KDF iteration count.

This has nothing to do with my usage.

Is sharing you password length wise? Knowing the # of chars you have reduced the number of iterations needed to complete a brute force attack.

255! vs 255! / (255 - 30)!

My math could be off though, i haven't work with factorials since i was in the university

I don't think you want a factorial involved.

With unknown size, cracking 30 characters takes time proportional to n^30 + n^29 + n^28 etc.

Cracking just 30 is proportional to n^30.

The difference is negligible. A percent or two.

It's a trick. OP's password is actually 29 chars long, but the attacker will now start at 30 characters, and never brute force the actual password. Nicely played.
Evidently there is no problem then.