2
$\begingroup$

I have software that generates user login keys randomly, we store the argon2 hash on our server. The generated keys are very strong, 64 pRNG hex characters. Right now we just use an empty string as the salting parameter in argon2 since we figure salt is not even needed since our passwords themselves are not prone to a dictionary attack.

I don't know much about the internals of how argon2 works though... is there some internal reason to generate a random salt in which argon2 becomes insecure without it... or is it just an optional parameter provided for protecting against common strings being hashed, but can be ignored if none of your strings will be common?

Improve this question
$\endgroup$
4
  • 1
    $\begingroup$ It will be deterministic, there no danger to use. If the 256-bit has generated a source with 256-bit entropy then there is no need to Argon either. $\endgroup$
    – kelalaka
    Feb 11, 2021 at 8:50
  • $\begingroup$ @kelalaka Contractual requirement by our employer to utilize Argon2, otherwise I'd just use SHA for something like this. So you are saying if we leave the salt empty, argon2 just deterministically generates one internally? $\endgroup$
    – Albert Renshaw
    Feb 11, 2021 at 9:10
  • 1
    $\begingroup$ Normally in Argon2, there are other additional inputs like tag and associated data and they will be fixed for you in one application. All inputs password, salt, tag, associated data (a little more) are input to Argon2. If you put an empty string to salt, it will be the same function for all passwords. Normally that is dangerous due to the Rainbow tables, however, this is not your case that seems. I think the contractor won't be happy when they see the empty string. $\endgroup$
    – kelalaka
    Feb 11, 2021 at 9:27
  • 3
    $\begingroup$ Normally you'd use a KBKDF such as HKDF instead of a PBKDF such as Argon2 (but preferably not just a hash). If you have 256 bits worth of keying material. However, if it is stored as a password I can imagine the requirement. The salt is technically not required, but neither is Argon2, so yeah... $\endgroup$
    – Maarten Bodewes ♦
    Feb 11, 2021 at 9:48

2 Answers 2

Reset to default
5
$\begingroup$

If you use a fixed salt all your passwords can be attacked concurrently. Though argon2 is designed to be slow and thus hard to do a dictionary attack I see no reason to give your attacker a speedup factor of the number of users. This will obviously be on top of any other advantages the attacker may have(e.g superior hardware or cryptographical advancement).

On a system with 100 users, using a salt gives you a 100x advantage over an attacker doing a dictionary attack on the hashed password. You can use this to slow her down or alternatively tune the security parameter to make your legitimate hashing faster and less resource intensive.

Using a salt is an easy win.

Improve this answer
$\endgroup$
0
$\begingroup$

I'm working on a similar question. But in your case I don't see the advantage of a static salt even the increase of security is low.

In my use case the "passwords" are much shorter and without additional identifier (e.g. userid). On the other hand they are used short-time and one-time applicable only and must type in by hand in a locker system with max. 50 compartments (and local low power hardware).

I plan to use Argon2 to be safe again intruders in the backend-server. But a individual salt costs unnecessary run time if I must calculate up to 50 individual hashes worst case. Therefore I prefer a static salt (again rainbow tables) which allows to identify the choosen locker with one hash run only.

To my mind static salt is okay because of short lifespan and manual input.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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