4 ms·
Their rationale is probably because those two don't scale very well when you want to make their efforts count, whether bcrypt's hunger for CPU or Argon2's hunge
by daneel_w 4y ago
Their rationale is probably because those two don't scale very well when you want to make their efforts count, whether bcrypt's hunger for CPU or Argon2's hunger for CPU and/or RAM. Bcrypt is very capable at bogging things down when you have lots of users authenticating very frequently, which is often the case with a POP3 server. A mere 100 e-mail clients authenticating every 2 minutes on average to check for new mail incurs a significant load even with a mild bcrypt work factor. On the opposite end PBKDF2 with 5000 rounds is much leaner, and if you enforce long passwords - which is immensely important no matter what password-hashing you use - then even fewer rounds are needed.
- zacharyvoase 4y agoWell if you want passwords to be difficult to crack if an attacker gets access to the hashes, you kind of just have to deal with it.
- daneel_w 4y agoYes, and enforcing long passwords is the primary and most important way of dealing with it. Enforcing ridiculously high CPU/RAM use for authenticating is a cost that both sides have to pay, but in itself it doesn't solve the problem at hand.
- kedihacker 4y agoJust assign passwords.
- febusravenga 4y agoI'm wondering, if pop/IMAP auth is so costly, why POP3/IMAP community not allow user to get session token and auth with it? Like JWT or anything with similar security properties. Both protocols are easily extensible...
- daneel_w 4y agoIt's only costly if the software (or its administrators) decides that it has to be. This particular product's approach (5000 rounds of salted SHA512) is not very costly, nor is it inherently insecure.