4
$\begingroup$

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).

Edit 2: This question and answer tackle my question in a general context (not Argon2 specific) very well.

$\endgroup$
6
  • $\begingroup$ 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. $\endgroup$
    – Paul Uszak
    Commented Oct 3, 2018 at 12:02
  • 1
    $\begingroup$ 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. $\endgroup$
    – staxyz
    Commented Oct 3, 2018 at 12:55
  • $\begingroup$ 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. $\endgroup$
    – Maarten Bodewes
    Commented Oct 5, 2018 at 14:29
  • $\begingroup$ @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. $\endgroup$
    – Paul Uszak
    Commented Oct 5, 2018 at 17:29
  • $\begingroup$ 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. $\endgroup$
    – staxyz
    Commented Oct 7, 2018 at 9:42

1 Answer 1

3
$\begingroup$

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.

$\endgroup$
4
  • 1
    $\begingroup$ 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. $\endgroup$
    – Paul Uszak
    Commented Oct 5, 2018 at 21:42
  • $\begingroup$ @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. $\endgroup$
    – rmalayter
    Commented Oct 6, 2018 at 1:48
  • $\begingroup$ 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. $\endgroup$
    – staxyz
    Commented Oct 7, 2018 at 9:53
  • $\begingroup$ @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. $\endgroup$
    – rmalayter
    Commented Oct 7, 2018 at 17:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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