Could scrypt salts contribute to entropy if passwords & salts are only stored in human memory?

Question

I'm unsure of how exactly the salt is manipulated by scrypt and its potential contribution if any to overall password entropy if passwords & salts are stored only in human memory for a decentralized implementation.

For this implementation, a cryptocurrency login where the salt does not exist in any repository such as a user table because the resulting hash is the accountholder's signing key, a user would be responsible for generating a "username" as the salt and a password. Both would be checked for minimum combined entropy such as naive entropy / 2 > 80 to push the user toward Diceware. There are currently no other requirements.

The username approach was selected because of statistical evidence showing that their distributions possess more than 35 bits of entropy, but I do realize that this set is probably skewed because of users wanting taken names and settling for besthashcracker11 which of course will be impossible to enforce thereby reducing that number.

If that scheme is more vulnerable to the average user than the risk of a weak password/passphrase alone, should a single passphrase be broken arbitrarily into two parts? If so, how? What percentage should be the password, and what for the salt?

If salts do contribute to entropy for this implementation, how can total entropy be calculated as a function of password entropy and salt entropy if an attacker has no access to the passwords, salts, or resultant hashes?

Users can be expected to be almost totally anonymous to an attacker.

Answer 1

If you use a potentially guessable username as the salt, you should add a global salt that no other services or programs will be likely to use for scrypt. For example, a long random number. That ensures that attacking another user database does not simultaneously allow attacking your users' hashes.

However, if two users are allowed to choose the same username within your userbase, adding global salt is not enough. You need something unique per user to use as salt instead of or in addition to the username. If random numbers really are not possible, consider using email addresses, which should be unique. (Those naturally add no entropy.)

Answer 2

Using the user's username as the salt is not totally unreasonable -- but there is usually no reason to do it. If you can store the password hash, you can usually also generate and store a truly random salt. And using a truly random salt is more reliable than counting on the user to select a random username.

Using the username as the salt does have some significant drawbacks. For instance, an attacker could choose a few usernames that are likely to be common across many sites, and precompute rainbow tables for each such username. A particularly delicious username to target might be root, because it is both common and high-value. Using the username as salt would not stop this attack, but using a truly random salt would stop this attack. As another example, if I know I want to attack Alice and I suspect she uses the same username alice on many sites, I could precompute rainbow tables for that value of the salt, and then potentially use them to attack her accounts on many different sites. Again, a truly random salt eliminates the potential for that kind of attack.

For these reasons, when hashing passwords, it is usually better to generate a truly random salt, instead of relying upon anything provided by the user. There might exist specific contexts where using a username as the salt is reasonable, but that would depend upon the specifics of the application, and the question does not give us any information to make that kind of judgement.