Using cryptographically random password as both the password and the salt

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.