What is the best way to store the verifyer for posession of a high entropy secret?

Question

This is just a thought experiment. I am trying to get an understanding on when we need password hashing functions and when they don't bring any benefits (eg. to save on calculation cost).

I know that password-hashing-functions are to be used when storing password verifiers as passwords usually have low entropy. What about high-entropy secrets? Is it sufficient to salt and hash them with a normal modern hashing algorithm or should I still use a password-hashing-function to increase calculation time and memory?

Example: User uses a cryptographically secure RNG to generate a 256-bit secret which he then uses as 'password' to sign up. Is it good enough to store a salt and the sha256-hash of the salted password to compare against in the future?

Answer 1

This is the well known security/cost balance for the choice of a hashing algorithm:

• the more resource consuming the algo is, the more resilient to brute force attack [assuming the hash has been leaked]
• the less resource consuming the algo is, the more users can be accepted on a server

When you have a stateful application, the common assumption is that the login operation only scarcely occurs, and that spending time there is not a problem.

But it is true that the computation cost is commonly tweaked depending of the security requirements, and the expected load of the system.

You are true on one point: the total cost of a brute force attack is the product of the algorithmic cost of the hashing algo by the password entropy.

The problem in deciding to use a fast hashing function and hoping high entropy passwords is that you have little control on how the end user will choose its password. Because typed passwords normally have to be simple enough for a human being to be able to remember them, and type them with no typo - I cannot hope typing a 64 characters password with no typo...

A possible alternative is to use stored tokens. As they are not expected to be hand typed, the size is not a problem and you can safely use a fast hashing function. You only expect the user to securely store them, but after all it is their concern. This is for example used on GitHub. And as a GitHub user, I know that the security of my account is limited by the security of the machine/application that stores my tokens.

Answer 2

What about high-entropy secrets? Is it sufficient to salt and hash them with a normal modern hashing algorithm or should I still use a password-hashing-function to increase calculation time and memory?

Example: User uses a cryptographically secure RNG to generate a 256-bit secret which he then uses as 'password' to sign up. Is it good enough to store a salt and the sha256-hash of the salted password to compare against in the future?

Yes, but in practice you don't know that's what a user did, so you'd run it through a password hashing algorithm anyway.

However, for high-entropy things where you do control the generation (or at least know the process used), it's quite reasonable to use a single iteration of a secure (but fast) hash algorithm, such as SHA2-256 or SHA3-256. You don't even really need to salt it; salting is to defeat rainbow tables and make duplicates look different, but nobody can make a rainbow table for even 128-bit-entropy values, and duplicates are functionally guaranteed to not happen (GUIDs are not quite 128 bits of entropy, in fact). Some examples of things where this is a reasonable approach:

• API keys (essentially passwords but by machines for machines, not intended to be human memorable or even necessarily printable)
• Opaque session tokens
• Refresh tokens (typically paired with JWTs)
• Password reset tokens (typically transmitted in a URL as hex or base64)
• Cryptographic keys (if you're just checking to see if a user-supplied key is correct before using it for a bunch of encryption/decryption)

---

The reasoning behind this being OK is quite simple. Passwords get extra hashing because they're somewhat predictable; while in theory a reasonable-length password could be hundreds of bits of entropy, in practice it's more like dozens. Making the password hashing a million times as expensive is, in terms of the difficulty of brute-forcing the hash, like making the password have another 20 bits of entropy. BUT: that's still only going to get you from maybe 40ish bits of entropy (if it's a quite good password; less if it isn't) to the equivalent cost of 60ish bits. That's still over a quintillion times less work than trying to brute-force a 128-bit value. Similarly, passwords get salted so that they'll have unique hashes and you can't precompute them, but all that the salt is doing is adding some amount - typically 64-128 bits - of entropy to the password (and then storing that extra entropy in plain text, so it doesn't actually make brute-forcing any harder). A high-entropy (128+ bits of entropy) value already has more entropy than a typical password + a 64 (or plausibly even a 96) bit salt; collisions are just not going to happen, and precomputing is literally impossible because there isn't enough storage on the planet to hold the table, nor enough compute on the planet to generate it.

Answer 3

It depends on the quality of other secrets of that type. If the secret is high entropy, but it's stored as a password and other secrets are typical low entropy passwords, then you should use a normal password hashing function like Argon2. That's because you don't want to make it easy to guess the weak ones, even if there are strong ones like the ones you've described.

If all of the secrets of its type are high entropy (that is, having at least 128-bits of cryptographically secure randomness), say, because you generated random tokens for users of your API, then you can use a salted hash because it is computationally infeasible to brute force. HMAC with a strong hash function like SHA-2, SHA-3, or BLAKE2 is a great way to do this (as are other strong MACs).