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

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.

-
Thanks for the update. That helps. Now, if the salt and password are both stored in human memory, what is the difference between the salt and the password (besides the obvious of where you stick them when running PBKDF2)? In particular, how are each generated? –  mikeazo Jun 20 at 18:11
@mikeazo Thank you again mikeazo for your guidance! I have added the information you need. –  user7024 Jun 20 at 18:22
You don't have to delete your question just because 1 person down votes it. –  mikeazo Jun 20 at 19:05
@mikeazo I'll take the 2 point hit only because you've been so gracious! :) –  user7024 Jun 20 at 20:34
Why do you want to do this, as opposed to the standard approach of generating a random salt and storing it with the password hash? Is there an application where you think this will be preferable? There might be a better solution, but we'd need to know the context in which this question arises to determine that. –  D.W. Jun 20 at 21:34

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.)

-
Thank you otus! For this implementation, the code is public, so I won't be able to hide a global salt. But I will definitely urge users to use a secret email! I very much appreciate that! I understand the purpose of salting for password storage, but in this case where the salt is probably unknown to an attacker, does it add to overall entropy? Is it simply an extension of the password? –  user7024 Jun 22 at 19:15
@Gracchus, the global salt doesn't need to be private to make users' salts unique, which is the main reason to use one. I would not count the salt towards any entropy calculation even if secret, but it does add to entropy if it really is unguessable by attackers. –  otus Jun 22 at 19:44
Thank you so much for sharing your knowledge! –  user7024 Jun 22 at 19:48

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.

-
That's where I'm stuck. How should the salt be generated since it cannot be retrieved later by the implementation? –  user7024 Jun 20 at 21:43
@Gracchus, why can't it be retrieved later? What prevents you from storing a salt together with the password hash? If you can store a password hash, why can't you store a random salt, too, in the same place (e.g., in the same database)? If you're not storing a password hash, what are you doing with the output of scrypt and what do you mean by a cryptocurrency login? –  D.W. Jun 20 at 21:52
Sorry, @Gracchus, I'm totally lost at what you are trying to do. How does login work? Are we talking about a system where the server stores a scrypt hash of the user's passphrase, or not? If not, what is the situation? The question is not very clear on how you plan to use scrypt. Are you talking about a system where a scrypt hash of the user's passphrase is used to seed a crypto-PRNG which is then used to generate their private/public keypair? If so, that has is about key generation, not login. I suggest you edit the question to make the application a lot clearer. –  D.W. Jun 20 at 22:55
@Gracchus, I'm going to give you some advice that might sound nasty, but I mean it in the best possible way: I don't think you should be designing cryptocurrency wallet software at this stage. This crypto stuff is subtle, and if you get it wrong, people could lose money. This kind of approach to design of cryptocurrency software is the sort of thing that causes people to lose money. It's exactly this sort of "let's just throw together some code and hope it works" that has caused multiple Bitcoin exchanges to lose lots of money. (For instance, there's a reason why we use a salt.) –  D.W. Jun 20 at 23:05
{"extraction_info": {"found_math": true, "script_math_tex": 0, "script_math_asciimath": 0, "math_annotations": 0, "math_alttext": 0, "mathml": 0, "mathjax_tag": 0, "mathjax_inline_tex": 0, "mathjax_display_tex": 0, "mathjax_asciimath": 1, "img_math": 0, "codecogs_latex": 0, "wp_latex": 0, "mimetex.cgi": 0, "/images/math/codecogs": 0, "mathtex.cgi": 0, "katex": 0, "math-container": 0, "wp-katex-eq": 0, "align": 0, "equation": 0, "x-ck12": 0, "texerror": 0, "math_score": 0.3304033577442169, "perplexity": 1145.8318725136653}, "config": {"markdown_headings": true, "markdown_code": true, "boilerplate_config": {"ratio_threshold": 0.18, "absolute_threshold": 10, "end_threshold": 15, "enable": true}, "remove_buttons": true, "remove_image_figures": true, "remove_link_clusters": true, "table_config": {"min_rows": 2, "min_cols": 3, "format": "plain"}, "remove_chinese": true, "remove_edit_buttons": true, "extract_latex": true}, "warc_path": "s3://commoncrawl/crawl-data/CC-MAIN-2014-49/segments/1416400380627.44/warc/CC-MAIN-20141119123300-00121-ip-10-235-23-156.ec2.internal.warc.gz"}