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.
You're off by about 20 orders of magnitude (the joy of binary exponents).
From what I can see, a more realistic estimate for a single core on a desktop is in the 2^26 range. Keep in mind that the PBKDF2 defender is single-threaded by design, whereas the attacker is not.
This still represents ~a half million x advantage for the attacker/$2k they spend. For $1m, they can guess passwords ~200 million times faster than you.
If we assume memory is the limiting factor for argon2, then even if a specialized attacker can use it at scale for 1/20th the cost, a 20x advantage is much better for the defender than a 500,000x advantage.
> What is crucial here is that we don't want to have the defender stuck with a slow implementation of something that the attacker will have a highly optimized implementation for.
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.
What US bank do you use that supports U2F, or do you not include banking in "critical"?
It might not be quite as good but email 2FA behind U2F protected email gets you pretty close
- 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.
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.
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.
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 but if you're running on cell phones that's not there
See also https://bitcoin.stackexchange.com/questions/36253/what-minin...
[0]: https://en.wikipedia.org/wiki/Password-authenticated_key_agr...
As for Bitwarden's implementation: it doesn't send the password to the server, it sends, basically, a PBKDF2 hash, which is different from the one used for encryption. The leaked hash can't be used to decrypt the database unless it's bruteforced. However, the protocol is not ideal, there's a weakness that I wrote about here: https://dchest.com/2020/05/25/improving-storage-of-password-...
AFAIK, 1Password uses SRP with PBKDF2 for verifier.
No, there is an important difference: leaking this verifier does not let an attacker to impersonate user at will. See my other message [0].
Is my understanding correct that you derive two keys from user password, one used for authentication and one for decrypting encrypted content which does not leave the user's computer? In that case, yes, it's somewhat better than the typical scenario, though I personally would still prefer if a proper PAKE was used for authentication. It may not apply to your service, but leaking encrypted data can still result in exposing certain meta-information, which may be important, so it's better to be extra-safe in such matters.
Citing the OP:
>Sure, you might tolerate a longer unlock time, but is the security gain really worth the cost to your battery?
I think the battery concern is over-blown. How often do you login into a service? I think that for typical use-cases, amortized battery-cost of a login is negligible. And for other use-cases you can let users choose.
Like what? It looks like personally my phone is 4x slower than my desktop. So if I calibrate for one or two seconds on my phone, the security should be pretty acceptable. Do I need to worry about devices much slower than that?
I don't think a 3s wait for a session, for greater security, and that on an unoptimized device is going to be breaking UX.
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.
Modern GPUs and ASICs can perform millions of SHA operations per second, even with a poorly configured Argon2, you reduce that massively.
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?
