15 ms·
Why we are still using PBKDF2-SHA256 despite being aware of its limitations
- dheera 6y agoWhat's wrong with PBKDF2-SHA256? I use PBKDF2-HMAC-SHA256 for an almost-stateless password manager.
- deleted 6y ago[deleted]
- kaiju0 6y agoSHA and MD are fast hashers. You want slow hashers for password security like b-crypt and s-crypt.
- dheera 6y agoDoesn't PBKDF2 fix that as long as you use a very large number of irritations?
- sneak 6y agoIn 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 https://github.com/bitwarden/server/issues/589
- Shoop 6y agoWhat do you think about this reply on that thread? https://github.com/bitwarden/server/issues/589#issuecomment-751418282 https://github.com/bitwarden/server/issues/589#issuecomment-...
- batrat 6y agoFor 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.
- Harvesterify 6y agoUse a longer and more complex master password. You're welcome.
- sneak 6y agoYou'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.
- the_mitsuhiko 6y agoEvidently there is no problem then.
- luis8 6y agoIs 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
- throwaway744678 6y agoIt'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.
- Dylan16807 6y agoI 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.
- luis8 6y agoMy bad, I was thinking in permutations but those does not allow repeated entries. It make sense now, like you said the difference is negligible.
- user5994461 6y agoPBKDF2 is a slow algorithm specifically created for password hashing. It's in the same family as bcrypt and scrypt.
- px43 6y ago> 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.
- user5994461 6y agoMath 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.
- goalieca 6y ago> 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.
- user5994461 6y agoRSA 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.
- est31 6y agoThe advantage of algorithms like Argon2 is that they are way harder to implement scalably in hardware than SHA256 is. Or in other words, it's easy to build an ASIC that's 1000x as powerful to compute SHA256 hashes as a recent Intel CPU than to build something that's 1000x as powerful to compute Argon2 hashes. You might still be able to, but then power usage is hopefully closer to a 1000-fold of the Intel CPU than the SHA256-ASIC is.
- SAI_Peregrinus 6y agoIt's not memory-hard. That makes it much, much faster on GPUs than CPUs, which tends to mean it's much faster for attackers than legitimate users. It's also likely vunlerable to side-channel attacks, since nothing in its design tries to resist those. It's not broken by any means, and still vastly better than just a salted cryptographic hash, but it's not as good as Argon2id.
- alserio 6y agoIf I may ask a question: how would I use a memory hardened algorithm on a server if the server ram can't scale infinitely? It seems to me that a few concurrent user logins would effectively DOS the server for any reasonable configuration of argon2
- SAI_Peregrinus 6y agoYou don't actually need it to use that much RAM. It's more about memory bandwidth. An attacker can increase the memory bandwidth by using block RAM like in an FPGA or on-die RAM in an ASIC, but both of those are far more expensive than discrete DDR DRAM modules. So with appropriate memory usage (enough to saturate the cache lines) it can be cheap enough for the server to run yet still more expensive to build an ASIC platform for. Of course an ASIC can use DDR as well, but then it's stuck with the same memory bandwidth as the DDR module and gains no particular advantage. Argon2id with t=3, m=92MiB, p=1 should be slower than bcrypt with cost 12 on most modern GPUs. That's not actually all that much memory, you can handle quite a few concurrent logins on a server with those settings. 10 concurrent logins per GiB of RAM dedicated to the task. And it should only DOS the login process, so it might make taking out your auth process (or server) easier but won't necessarily harm any other part of the site.
- alserio 6y agoThank you. I find a GiB for 10 concurrent logins still a bit too much for some use cases but you have given me a better understanding of the trade-off involved.
- __s 6y agoRead the opening comment on the issue It's reasonable to expect an attacker to have a SHA256 ASIC given Bitcoin making those a commodity Potentially this can be offset if your server has https://en.wikipedia.org/wiki/Intel_SHA_extensions https://en.wikipedia.org/wiki/Intel_SHA_extensions but if you're running on cell phones that's not there See also https://bitcoin.stackexchange.com/questions/36253/what-mining-performance-can-we-roughly-expect-from-the-intel-sha-extensions-of-t https://bitcoin.stackexchange.com/questions/36253/what-minin...
- henriquez 6y agoIf it's not broke, don't fix it. The underlying hasher is most important anyway. Crappy passwords will always be susceptible to rainbow attacks.
- sneak 6y agoNo, not with salt and a high enough iteration count, they won't be.
- e12e 6y agoI think gp is a bit off - weak passwords will be vulnerable to a dictionary attack - even if reasonably salted. But won't be vulnerable to rainbow attacks in any meaningful sense (assuming sensible salt/hash/iterations).
- goalieca 6y agoPbkdf2 itself is not the best for the same reasons why sha256 was listed. I do agree that argon2 is better.
- user5994461 6y agoPBKDF2 and SHA256 are fine for all use cases and have libraries available in all languages. argon2 has nothing better to offer. Practically there are 3 argon variants to chose from and they all require careful configuration. It's pretty hard to start with, assuming you can find libraries for it in the first place, last I checked it wasn't commonly supported. It's a perfect example of theory versus practice. Argon is a researcher's wet dream, ideal by some algorithmic definitions, yet it has no benefits in practice.
- CyberRage 6y agoAre you serious? Even something that would be considered "bad" argon2 set-up is far better than anything that is based on SHA256. Modern GPUs and ASICs can perform millions of SHA operations per second, even with a poorly configured Argon2, you reduce that massively.
- user5994461 6y agoYou can't compare plain SHA256 with PBKDF2. PBKDF2 can take a million SHA operations to hash one password, if you configure it to (default is somewhere 10k to 1M). If you were to leak your company database with 1 million customers and hashed passwords, there's some theoretical considerations to be made on resistance to GPU and ASIC cracking, practically you're in a pretty bad place whichever algorithm was used. ^^ P.S. Cryptography would have more weight if half the passwords weren't a variation of password2021 and hunter22.
- goalieca 6y ago> You can't compare plain SHA256 with PBKDF2. But you can. It’s literally just N times the hash. Typically the number of iterations is chosen to be somewhat slow on the server that derives it. But a specially designed rig can execute this with extreme parallelism and speed.
- woliveirajr 6y agoIf I understood correctly, the points are: - using longer passwords (or salts) is better than increasing the number of rounds - having the same database on different devices (top-CPU x older cellphone) have impacts on the performance for the user but not for the attacker (as a powerful hardware will be used) Seems fair, for the average user. And the top user will prefer a longer password anyway.
- user5994461 6y agoFirst sentence is really the problem in the modern era. The best most people can remember as a password, is some variations on common words and their date/place of birth. Hence it doesn't matter what algorithms a database is using, computer will crack most passwords very effectively, provided with common words and minimal rules. The only solution to secure against cracking is to have way more complicated passwords (very long), but people can't remember them.
- xxpor 6y agoMy threat model isn't a directed attack, it's DB dumps with unhashed or unsalted passwords from random websites. I want to use a unique password on every site, and password managers provide a convenient way of doing that. Even if every BW vault leaked, if it takes half a day to run through 8 a-zA-Z0-9, it's not practical to do that for every vault. On the other hand, if I'm being targeted, even increasing that to a month wouldn't really matter. Every "critical" site I use also supports u2f 2fa, which I've turned on. So even if they got my passwords, there's the 2nd factor they don't have. tl;dr: Just use a damn password manager, even one that has arguable issues such as this improves the average person's security by orders of magnitude.
- vinay_ys 6y agoWhat do you use for 2FA tokens?
- xxpor 6y agoYubiKeys (4 I think? It's been a while since I bought them)
- sneak 6y ago> Every "critical" site I use also supports u2f 2fa, which I've turned on. What US bank do you use that supports U2F, or do you not include banking in "critical"?
- masterofmisc 6y agoI don't know about the US but Barclays in the UK has had multi-factor authentication for years now. Is that not the case in the US?
- fmajid 6y agoIf it is TOTP/HOTP based rather than U2F (6-digit codes), it is vulnerable to real-time spoofing.
- henns 6y agoI think this misses the point: we should be doing everything we can to deprecate PBKDF2 because of the big differences between what a specialized attacker can do vs. the defender. As a rough estimate: a $2k bitcoin miner can do 2^45 SHA-256 hashes/sec whereas your $2k laptop can do 2^16 hashes/sec; the attacker has ~a billion x advantage over you that can be multiplied based on their funding. At that point, doing even 10,000 PBKDF2 hashes may not make much of a difference. argon2, scrypt and other memory hard password hashing algorithms reduce the orders of magnitude advantages of the attacker by requiring RAM. Attackers might be able to purchase RAM cheaper than the defender, but nothing close to a billion times cheaper. Addressing concern #3 (want to have a password set on a laptop that decodes in a reasonable amount of time on a low-end smartphone), you could restrict the RAM to some small amount (like 256MB) if you anticipate needing to use a low-end device. This will still be a vast reduction in the attacker's advantage over PBKDF2.
- user5994461 6y agoA $2k computer can do billions of hashes a second. 2^30 You're off by about 20 orders of magnitude (the joy of binary exponents).
- contravariant 6y agoI'm confused, 2^14 = 16384 is slightly more than 4 orders of magnitude, where did you get 20 from?
- bscphil 6y agoAn "order of magnitude" has no precise numerical meaning, it depends on what base you're working in. If the log of the number in base b increases by 1, you've increased 1 order of magnitude with respect to that base. (I don't know why the parent said "20", my instinct is to say 14 orders of magnitude here.)
- deleted 6y ago[deleted]
- fuoqi 6y agoThe model of hashing user plaintext passwords on server-side is itself a deeply flawed one. User password and master keys derived out of it should NEVER leave user-controlled computer. For authentication password-authenticated key agreement protocols [0] should be used, anything but it means that service does not treat user security as a high enough priority. [0]: https://en.wikipedia.org/wiki/Password-authenticated_key_agreement https://en.wikipedia.org/wiki/Password-authenticated_key_agr...
- est31 6y agoI think that's the problem here: Bitwarden hashes the passwords on the client side but it runs on various client devices, some more powerful than others, and others not able to run efficient Argon2 implementations.
- tmikaeld 6y agoThen make it a users choice?
- onli 6y agoHow? Seriously interested. This is cross-plattform software. How do you change that from PBKDF2-SHA256 to Argon in a way that still lets you use your desktop PC as well as your 4 year old budget Android device? And then support user configuration on top of that? Same about raising iterations. The submitted github comment also makes that point, this is actually hard to do.
- CyberRage 6y agoOffer the user the choice for other solutions with a performance penalty? Choice is always better. for people who care\worry, they can change to something more resistant to cracking.
- selykg 6y agoAs someone who worked in this field. Offering "options" when a vast majority of the user base don't even understand that their data is encrypted, is often a poor approach to take. Users will forget their Master Passwords even and because they forgot them they will believe they've been "hacked" and blame you. Users on Hacker News and similar sites where users actually understand the underlying technology to some degree are the exception, not the norm. Adding options does not help a vast majority of the user base and it complicates your codebase further. Imagine making that change and less than 1% of your users actually use that feature?
- infogulch 6y agoUser-defined passwords are a bad choice for an encryption KDF. I'm not disagreeing with sibling xxpor's tl;dr that worse is better here; getting everyone on password managers would be a huge net win for personal security. But debating the choice of KDF is missing the elephant in the room: that user passwords simply lack enough entropy for use as secure key material. It's like debating which kind of paper you should use to repair a huge hole in your bunker with a paper mache. That said, asking the user to manually type full-size generated keys between devices is simply a nonstarter. But what if the user stored their passwords in a private Matrix room? Matrix' solution to sharing encryption keys between devices is by being the communication channel by which users approve new devices from existing devices; upon approval the room's encryption key is sent to the new device encrypted using the new device's public key. That is, the room key can only ever be seen by the devices themselves. (I think this is a reasonable summary of encryption in Matrix, please correct me if I'm mistaken.) This is basically using a Matrix room as a general distributed, encrypted data store. Thoughts?
- tialaramex 6y agoA lot of the sub-threads seem to have decided to talk about using PBKDF2-SHA256 as a password hash like crypt(), which actually isn't what the linked report is about. PBKDF2, as its name suggests, is a key derivation function. We can use these as password hashes, and people do, but we can also use them to turn any human memorable password (like "stonks", "S&SMBMBbc&wem" or "fzg76@PRU385!") into a nice 128-bit or 256-bit symmetric encryption key and that's what they're doing in tools like Bitwarden or 1Password. In this role, you very much have a practical option to just pick a decent password. "stonks" is not a good password, the second one is a Rhianna lyric ("... but chains and whips excite me") but the third one is a pretty obscure reference and it's neither likely that your adversary would "guess" it nor that the sort of brute force attacks envisioned would hit this random looking 13 character password. Anyway, even as a password hash I've made the argument previously that stronger hashes only marginally improve things, far too many of your users will pick "stonks" or if you insist on eight characters maybe "stonks!!" and even if you have Argon2 tuned way up the attacker can reverse that because it's too obvious. If your users picked unique random passwords (as they might with tools like Bitwarden or 1Password, even though I personally use zx2c4's pass) then it doesn't matter if you use a terrible hash like some turn of the century PHP forum using MD5, because that's still safe with such passwords.