3

So, in ASP.NET,

System.WebHelpers.Crypto.HashPassword("123456");

will create a hashed, salted string that is unique every time. This is great; it means that if someone managed to get hold of a hashed password (say, in a SQL injection attack) they wouldn't be able to use lookup tables to find the original password. However, as far as I can see they WOULD still be able to easily write code to attempt to brute force it locally, without involving the victim's server, e.g.:

foreach(string passwordToTry in BigListOfCommonPasswords)
if (Crypto.VerifyHashedPassword(stolenHash,passwordToTry)) return passwordToTry;

... so wouldn't it be better to add your own extra salt when calling HashPassword, where the extra salt is stored outside of the database, e.g.:

System.WebHelpers.Crypto.HashPassword("123456"+getSaltFromWebConfig());

..., or is this pointless for some reason? Seems to me worth doing to make the above brute force attack much more difficult, but I've never seen this idea mentioned anywhere in usage examples for Crypto.HashPassword, so is there something I'm missing?

EDIT: This isn't a duplicate of The necessity of hiding the salt for a hash . That question is asking whether an unhidden salt has any use to it at all. I'm not disputing that a salt stored in the same place as the hashed password is useful, or that passing an unsalted password to Crypto.HashPassword is useful. What I'm really getting at that adding your own, additional salt, stored elsewhere (even if it's the same for every user), provides an extra layer of protection on top of that provided by Crypto.HashPassword .

In the case of a SQL injection attack that exposed the database, the additional salt in, say, a web.config file, would still be protected (or would at least require an entirely different attack to access it).

System.WebHelpers.Crypto.HashPassword("123456"+getSaltFromWebConfig());

makes the hashed password much less useful for an attacker than

System.WebHelpers.Crypto.HashPassword("123456");

for certain types of attack and without much additional cost in terms of computing power or programming time.

Community
  • 1
  • 1
Rob S
  • 33
  • 5
  • 1
    Possible duplicate of [The necessity of hiding the salt for a hash](http://stackoverflow.com/questions/213380/the-necessity-of-hiding-the-salt-for-a-hash) – Thilo Feb 10 '16 at 12:48
  • Well, that method already salts your password. So you're salting a salted hash. Is that pointless? I dunno. Would salting it three times be pointless? Or maybe four? Is five times salted pointless? I'd say that at some point before infinity salts we reach peak pointlessness. So we have a number somewhere between 2 and infinity where it becomes pointless. As we don't know the actual number, and 2 is definitely a candidate, then we might as well pick 2. –  Feb 10 '16 at 14:12
  • @Will whelp, sounds like you read the title of the post without actually reading the text of it. But thanks for your comment, we all need more sarcasm in our lives! – Rob S Feb 10 '16 at 17:04
  • Are you saying my comment was pointless? –  Feb 10 '16 at 17:35

1 Answers1

3

The salt you are describing is commonly called a pepper. The question as to whether or not to use a pepper has been answered very completely here:

Best Practices: Salting & peppering passwords?

In summary, you shouldn't use peppers because:

  • You cannot change the value of the pepper because the hash function is one way.
  • Adding a pepper effectively changes the hashing algorithm and this should only be done by experts.

There is, however, another option which can improve security if the assumption that it is harder to obtain the static secret than it is to obtain the password hashes holds true. Rather than adding pepper, simply encrypt the combination of hash and salt using a standard symmetric algorithm. This addresses both of the issues mentioned above while still improving security if the encryption key is not compromised.

Community
  • 1
  • 1
Stefan
  • 161
  • 2