I followed the recommendation of choosing threads, memory consumption and the number of iterations (in that order) on my machine. But now I wonder which passwords (by means of entropy) are actually secured by this set of parameters.

Clearly, a single letter is not secure, regardless of the parameters; but on the other hand, using a 256-bit entropy password renders the usage of argon2 pointless. So the security of my hash certainly depends on the relation between password strength and argon2 parameters. Since I am using old and not powerful hardware I am concerned, that the time it takes for me to calculate the hash is negligible for a large scale attacker. (This might be even worse for hashing on mobile phones or embedded devices.)

So the question is: Given a certain set of argon2 parameters, what is the minimal entropy a password should have so that the hash can be assumed to be secure?

Alternatively: Given a certain set of argon2 parameters, how many passwords can the fastest supercomputer available today (in 10/20/50 year) check in a second?

Edit: I am using a strong (>= 128-bit) password for locking my password manager, but entering this several times is tedious. So I thought using a key file that is protected by a simpler password. Since I am syncing stuff to the cloud, the hash of the simpler password can not be considered a secret. In order too choose a simpler password that is still considered secure, I need to be able to estimate the protection gain from using a strong KDF (e.g. argon2).

  • Although, often it is not possible to use 256 bit entropy passwords. I say password rather than key advisedly. Password complexity rules won't allow it on many web sites. – Paul Uszak Oct 3 at 12:02
  • 1
    What do you mean with "I say password rather than key advisedly"? Anyway, I want to reduce password complexity. My goal is to use the simplest password that is still strong enough when paired with argon2. – xwst Oct 3 at 12:55
  • State preserving services can accept (very) low entropy passwords by only allowing a specific number of authentication attempts (PIN on debet or credit card). This doesn't help for protecting a password hash database of course but sometimes it pays to think out of the box. Similarly maybe you can use the phone's own authentication measures to secure your application. – Maarten Bodewes Oct 5 at 14:29
  • @xwst If you poke around here, you'll see that it's almost impossible to accurately measure the entropy of a password. I would expect it to be > 100 characters long for an entropy of 256 bits, and many websites won't allow that. And many daft complexity rules demand weird formatting that blurs the distinction between password and key. – Paul Uszak Oct 5 at 17:29
  • Actually it is quite easy to determine password entropy if you generate them yourself (assuming your RNG is decent) and you certainly need less than characters for 256-bit entropy. Besides, I've edited my question, because I am not concerned with web services, so I tried to claify this. – xwst Oct 7 at 9:42

You should have ≈128 bits or more entropy in any password you want to remain secure regardless of the password hashing function.

Rationale: slow password hashing functions only add a constant-time factor to brute-force search. Since you don’t know the processing capabilities of any potential attacker, the only safe path is to use a very high-entropy password Such a password would be securely stored even if hashed with a single iteration of MD5 without salt.

So what do fancy iterated, “memory hard” functions buy us?

They help against, but do not prevent, attacks on low entropy passwords, the sort that humans can actually memorize. In effect, they increase the work factor required for a dictionary, brute-force, or hybrid search by a fixed amount. You could view this as “extra bits of security”, but you’ll only know how many bits you still need “to be secure” if you know with fair certainty the computational abilities of your attacker.

If your adversary is a nation-state’s security apparatus, the number of “bits of entropy you need” in the password differs vastly from that when your adversary is me. So the only truly safe thing to do is to always use a high-entropy input password, which renders the fancy hash function pointless.

Slow password hashes are implemented to mitigate the costs to users of a breach of the password hash database. They cannot make low-entropy passwords “always secure” unless they themselves utilize 2^100 operations, making them completely impractical.

  • 1
    Of course, you're playing the same game as the OP with "high-entropy input password." The higher the entropy, the greater the need to write it down (on a Post-it stuck to the screen). Multiply that by number of passwords. Especially with monthly expiry. A perfect salt mitigates this and adds credence to the question. – Paul Uszak Oct 5 at 21:42
  • @Paul_Uszak LastPass/KeePass/1Password do in fact exist, so you don’t have to remember multiple high-entropy passwords. However, we need to retire passwords entirely. Usability of the various passwordless options is still woeful. I’m hopeful about SQRL as an easy-to-use passwordless single-factor, but it’s been “really close to ready” for several years at this point. Who knows what will work... but passwords definitely do not work. – rmalayter Oct 6 at 1:48
  • I read your answer as "KDFs don't provide any reliable security", which means that people just use them because they hope that they improve security? You nicely summarized my dilemma. I know that I can use strong passwords, but I don't want to in this special case. (See edit of my question). On a side note, I disagree with you about the passwords. They are a simple and secure solution on an individual basis. I couldn't care less about the fact that other (common?) people are unable to use them properly. – xwst Oct 7 at 9:53
  • @xwst I’m saying “password-based KDFs do not provide security guarantees, they merely slow down attackers.” They are certainly useful for mitigating the impact of certain attacks, but cannot provide a guarantee of security against hash-cracking when a password hash is exposed. A 128-bit-entropy password can provide such a guarantee against hash-cracking, even if the hash is exposed. – rmalayter Oct 7 at 17:55

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.