# Is a randomly generated long password more secure than a higher number of rounds in a PBKDF?

Usually the requirements for passwords are that they should be salted and use a high number of rounds.

My understanding is:

1. Salting a password is only used to prevent rainbow attacks
2. Using a high number of rounds is only used to prevent brute-forcing short passwords

But if a password is computer generated and only used in an automated way between 2 remote systems, is it safe to salt it, but not hash it with multiple rounds? Would using an extra long randomly generated password (like a 256 bit password) be enough to avoid needing the multiple rounds? Would just salting be enough?

• It's probably worth dwelling on the difference between a password like "SECRET" and a 256 bit one which is closer to a key. Jun 4, 2022 at 17:15
• Sorry, we cannot quantify your question. If you have a secure uniform random number generator ( CSPRNG) then hash it to generate your password/key. if you can memorize the output everything is fine. Jun 4, 2022 at 17:41

TL;DR Yes, a password with a strength of 256 bit would be much more secure than a password of around 40-60 bits (the strength of reasonably secure passwords) + a number of iterations. Even about 270 million iterations would only add 28 bits of security ($$2^{28} \approxeq 270 \text M$$).

Salting a password is only used to prevent rainbow attacks

That's not entirely correct; for one you could easily distinguish identical passwords if there is no salt (or other data) used to distinguish between use cases or indeed users.

Using a high number of rounds is only used to prevent brute-forcing short passwords

Well, yes. A normal hash is already one-way, and you need the salt for the aforementioned purposes. So the only reason to use the iteration count or work factor is to have the attacker perform many rounds of the underlying primitive as well.

Of course, if the salt is missing, the iteration count would also make it harder to build a rainbow table.

But if a password is computer generated and only used in an automated way between 2 remote systems, is it safe to salt it, but not hash it with multiple rounds?

That's not a password, that's a secret. If you'd use it correctly you might not even need a salt, although you will have to keep in mind that the secret remains the same in the protocol that you use it for (e.g. for encryption you'd need an IV or nonce to make sure the outcome is not deterministic).

Would using an extra long randomly generated password (like a 256 bit password) be enough to avoid needing the multiple rounds?

There is no such thing as a 256 bit password. Passwords consist of text, not binary. 256 random bits are common for keys such as AES-256 keys or keys used for HMAC-256.

A password could have 256 bits of entropy, spread over many characters. But such a password could not be remembered by a human for normal operations. For instance, if you'd use ASCII with all possible special characters (without space) then you'd need a fully random 39 character password ($$\log_{92}(2^{256})$$ in case you want to verify this).

And yes, for a secret key you would not need the iteration count or the PBKDF in the first place. If you need a salt or not depends on how you are going to use it. You would not need it for one-time usage. If you need a KDF then you could use a Key Based KDF such as HKDF.

• So the only reason to use the iteration count or work factor is to have the attacker perform many rounds of the underlying primitive as well. would this only be used to avoid brute force attacks? Could I achieve the same effect without the computation overhead by just adding a time delay (like 1 second) to each request? Although the attacker could then perform the attack in parallel. But still, the key size is significantly big enough to make brute force unreasonable? Jun 5, 2022 at 0:51
• You could easily generate a password with 256 bits of entropy, e.g. by selecting 16 random words from a 65536 word dictionary. And remembering such a password would not be a huge problem for a human. It would be more problematic to enter it frequently, using a keyboard, or, for that matter, to be forced to change it each year, and memorize a new one. Jun 5, 2022 at 6:21
• @KernelJames If you actually have 256 bits then any kind of brute force attacks would not be feasible. Yes, time delays may help, as long as the attacker cannot perform the attack offline and - as you've already mentioned, keeping in mind that distributed / parallel attacks are probably still feasible. But in that case you can also put in exponential delays or maximum number of tries. Jun 5, 2022 at 11:43
• Sorry, forgot the question in the title :) Jun 5, 2022 at 14:14
• @maartenbodewes If I use a 256 bit key do I also need an IV if I use AES256? Jun 5, 2022 at 14:59

Salting predated rainbow tables by a significant margin. In fact it may have come before the more general time memory tradeoff for inverting hash functions(Would have to look up but and pick exact dates to attribute the developments, but late 70s early 80s is when these stuff were happening).

Rainbow tables I was around to remember the paper "A faster cryptanalytic time-memory tradeoff" came out late 2003 IIRC. And though we commonly use rainbow tables as a synonym for time memory tradeoff they only give a factor of 2 compared to previous multiple tables with distinguishing points. They simply were the best option as these attacks became viable for many hash functions.

Back to to Salting. Salting prevents attacking multiple hashes together. If I get a leaked file with hashed passwords and no salt is used we can brute force all of the passwords together. The runtime to break at least one password drops linearly with the number of password.

Iteration count is great for slowing down the attacker, but it slows down the legitimate user as well. And though we try to combat with memory hard functions, we should assume the attacker still has a scale advantage. E.g with GPUs or custom hardware. And of course there could be cryptanalytic improvements. More entropy in the source ia more robust and won't slow down the legitimate user.