1

A number of encryption functions include their tuning parameters in the output. For example, SCrypt, which I've been considering for an app I'm building, outputs in the following format:

$<version>$<params>$<salt>$<hash>

It seems to me that if an attacker didn't know these values, it'd make life harder for them... but if my app doesn't know the values, then it makes things tricky for me and my users. I understand that many implementations then go on to hash this output to obscure the parameters; I presume that there is therefore a way of doing this that doesn't weaken the overall scheme or increase the chance of collisions. However, by my understanding, if this second hashing pass is reversible, then it's of limited use because an attacker can reverse it as easily as we can and get the parameters we were trying to hide from them - and if it's not reversible, then we still have the problem of the parameters being inaccessible to us as well, so I don't see how it's that different from just cutting the parameters off. I could always have the parameters as constants in the app's code, of course, but that then relies on the quality of my code obfuscation, which is something I've never been too confident about (call it healthy paranoia). It also means I couldn't migrate users from old versions without losing their passwords and anything else I have encrypted, and setting up logic to use the old and new methods in parallel seems to me like having two doors instead of one, which feels less secure.

Do these parameters really need protecting from attackers, and if so, what's the safest way to do so?

Improve this question
2
  • While it might be intuitive that less information is more secure, these parameters have nothing to do with the security of the encryption and hiding them will only serve to give a false sense of protection, or worse divert attention away from hiding the important stuff - the passwords/keys.
    – lynks
    Commented Mar 25, 2013 at 17:33
  • My reasoning is that for a given algorithm the attacker has to hash possible passwords and compare them to the hash. If the attacker doesn't know the settings used to generate the hash, then they have to try each password multiple times to cover the various possible combinations of settings (where they can't be deduced from the hash). If they don't know the algorithm used, then they have to try each password even more times, for each algorithm it might be (assuming the output isn't recognisably from one algorithm). Of course I won't be any less careful with the actual keys; this is just extra.
    – anaximander
    Commented Mar 25, 2013 at 19:28

1 Answer 1

Reset to default
1

The "parameters" need not be secret. They are not meant to be secret. It is difficult to keep them secret. So, short answer: don't bother.

On a general basis, you don't want to show the hash output to just anybody. That's why, on Linux systems, /etc/shadow is not world-readable. Similarly, you don't give a dump of your Web site database to just anybody. However, there can be occasional mishaps, in which the attacker can learn part or all of your system data. You keep password hashes, instead of just the passwords, precisely for that reason. Password hashing is a "defense in depth" thing. Separating, e.g., the salt from the hash is then a "defense in deeper depth": it makes sense only if you assume that the attacker breached through the external defenses (he could get a glimpse at your site database, e.g. with a SQL injection attack) but could not breach them totally (he somehow obtained a partial database dump, which includes the hash values but not the salts, or vice versa). This is not a very probable scenario, so it is rarely worth the effort.

See this answer for a detailed discussion (in particular the sections about "salt secrecy" and "pepper").

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .