# Using cryptographically random password as both the password and the salt

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?

• "...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. – President James K. Polk Mar 23 '20 at 15:00
• "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. – Boris Mar 23 '20 at 21:21

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.

• 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! – rubixibuc Mar 23 '20 at 15:22
• And be infeasible to brute force or by any other means find a input that generates the same hash? – rubixibuc Mar 23 '20 at 16:21
• @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. – Gilles 'SO- stop being evil' Mar 23 '20 at 18:28
• @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. – Gilles 'SO- stop being evil' Mar 25 '20 at 8:58
• @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. – b0fh Mar 25 '20 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.