This question is theoretical, but will help with my understanding.

All of my passwords are securely generated using 64 random letters (both uppercase and lowercase) and numbers.

Using the argon2i password hashing algorithm, if I supply this long random password for both the message and the salt, will it still remain reasonably secure. In all cases the salt will be equal to the password being hashed.

My understanding about salts leads me to think, since the password is already sufficiently complex and random, that the salt always being the same exact value as the message/pw doesn't necessarily make the password reasonably discoverable. How does this apply to argon2i?

  • 2
    $\begingroup$ "...All of my passwords are securely generated using 64 random letters.." I would not call that a password simply because it contains only printable characters. A password is something that has to be remembered and will thus likely be low-entropy and re-used. Password-hashing techniques are designed to mitigate some of the worst effects of passwords. It's not clear why you don't simply generate a key for the underlying crypto primitive. $\endgroup$ Commented Mar 23, 2020 at 15:00
  • 4
    $\begingroup$ "All of my passwords are securely generated using 64 random letters" Then you don't need a salt. You can be statistically certain that your password has never existed (and will never exist) on any computer in any form until you generated it. $\endgroup$
    – user55497
    Commented Mar 23, 2020 at 21:21

3 Answers 3


The whole point of a salt is to be unique to a set-password operation, so that attackers can't reuse work when they target multiple accounts (multiple users on the same server, multiple servers, or both). Using the password as the salt completely defeats the purpose.

The salt does not need to be unguessable or secret. The reason it's almost always a long-ish random string is to be statistically unique (in the literal sense), not to be securely unique: it's random so that the chance of two set-passwords using the same salt accidentally is negligible, not so that an adversary cannot guess it. A unique server name plus thread identifier plus timestamp would work as well, but that's not commonly done because it's hard to ensure you get a unique string this way in all environments (e.g. on a cloned virtual machine).

Most libraries automatically generate a random salt during the set-password operation and store the salt with other metadata together with the output of the password hashing function. In most programming environments, you'd need to do some extra processing to force a different salt during the set-password and check-password operations, and to change the storage format so that the salt is not stored (otherwise you'd just be storing your password in plain text). Do not do this extra processing: it would add complexity, only to reduce security even if implemented perfectly.

A password with 64 characters on a 62-character alphabet has about 381 bits of entropy, which is overkill: any data that it protects, or its transmission in communication, would at most be protected by a 256-bit key. 43 characters would give you 256 bits. 20 characters would give you 119 bits. With a password that long (and randomly generated, otherwise length is irrelevant), you don't actually need a password hashing mechanism: the purpose of password hashing mechanisms as opposed to ordinary hashing is to make guessing harder, but guessing a 119-bit secret is infeasible in the first place. So from a theoretical perspective, because your password is already high-entropy, using Argon2i or any other password hashing function with a defective salt won't actually reduce the security of your system. But you still shouldn't do it, both in case the system is ever used with a “normal” (lower-entropy) password and because it would increase the implementation complexity.

  • $\begingroup$ So if I were to just hash that password/key with sha3-512, would it be technically infeasible to brute force find the password/key from the hash alone? And ty for your answer! $\endgroup$
    – rubixibuc
    Commented Mar 23, 2020 at 15:22
  • $\begingroup$ And be infeasible to brute force or by any other means find a input that generates the same hash? $\endgroup$
    – rubixibuc
    Commented Mar 23, 2020 at 16:21
  • 6
    $\begingroup$ @rubixibuc Yes. With a password that has this much entropy, you could use an ordinary hash. If it would take more than the age of the universe to brute-force it, it's immaterial whether it would only take 10 times more or 1 trillion times more. It's more of an access token than a password. $\endgroup$ Commented Mar 23, 2020 at 18:28
  • $\begingroup$ @b0fh What is wrong? In particular, what is wrong with a predictable (but still unique) salt? And how does a salt that's identical to the password reduce to a plaintext password if you don't store the salt? It obviously does if you do, but I guess that's maybe not so obvious if you don't understand how password hashing works so I'll add a note. $\endgroup$ Commented Mar 25, 2020 at 8:58
  • $\begingroup$ @Gilles'SO-stopbeingevil' right, sorry, that was not clear. If you don't store the salt there is no issue, I agree, but it's not clear from the original question what they are implementing and how; and I think it's really dangerous to have a such a question laying around, that states using the plaintext as a salt is safe. Other people might read it and apply it to a different, incorrect context. I'd withdraw the comment if there was a clear bold disclaimer that it only applies if you are implementing your own storage and making sure you don't store the salt. $\endgroup$
    – b0fh
    Commented Mar 25, 2020 at 11:35

Gilles already explained it sufficiently but using a unique salt brings another advantage: Users with identical passwords will not have identical hashes stored in the database. Unfortunately not all people use safe passwords and many use identical passwords.

Knowing that a certain system is not using unique salts but instead using the actual password as a salt would also allow pre-computation of hashes without having access to the database.


I'm not sure I understand the question (mostly because I don't understand what you mean with "supply this long random password for both the message and the salt"), but if you supply the password as salt to argon2i, the question I most pressingly would have: where is the salt stored? Most systems using argon2i would store the salt, in cleartext, in a usually easy to access location (e.g. with the message).

So while passing a password as password and salt though argon2i should not have detrimental effects on the password or the result, but depending on the system using it, you might expose your password this way.


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.