CODEWITHSUNDEEP
authenticationhashsalt-cryptographypassword-encryption
Marcel Marino
Marcel Marino

Reputation: 1002

Storing Salts for Passwords

I've been doing some research about storing salts, and apparently the most common way to do it is to store it in a separate column in the same table as the username and password. I've seen that all over this and other websites, but to me this is like putting the key right next to the safe. If anyone ever gets access to the authentication table the hackers would win. If they do but the salt isn't found there they wouldn't have as much to go on.

I operate a three tiered system and would prefer some method of storing the salt somewhere on Java operated middle-tier that is behind a firewall and not accessible directly from the internet. Perhaps some XML or something that none of the other parts of the application will touch?

Upvotes: 0

Views: 1599

Answers (1)

Anti-weakpasswords
Anti-weakpasswords

Reputation: 2712

Let's go over what the salt really is, then. It's a way of making sure

  • Two users with the password aren't obvious.
    • "password" with PBKDF2-HMAC-SHA-512, 10000 iterations, keeping only the first 32 bytes of output, stored in Base64, and a salt of empty string is ALWAYS

      9MpQfAfQvTG8d5oIdWgmpv2d2X1DrCXkspoJM6vqA/M=

    • Thus, if you have 5% of your users with that as their password hash, you can be pretty sure it's either "password" or "12345" or one of the other worst passwords.

  • Attackers cannot precompute attack lists in advance of leaks and then nearly-instantly match their "rainbow table" of results to the leak to eliminate that entire precomputed list, then get on with cracking the hard passwords without wasting precious time on the easy ones.

    • So, if we have an attacker with a password list of "password" and "12345", and you use no salt, they have already figured out that those results with the setup above are:

      9MpQfAfQvTG8d5oIdWgmpv2d2X1DrCXkspoJM6vqA/M=

    • and

      I2bEyBbaxTBvHdJ7rIu7kdR2liwGMCg62lyuoj41NB8=

    • Thus, the attacker gets your password list however, and they nearly instantly eliminate spending any computation time on the MANY of your users chose terrible passwords, which means they have more time, and combinations, left to try on the higher difficulty targets.

  • If you use a 16 byte cryptographically random salt for each userid, then instead of needing to perform the hash algorithm once for each password*rule on their list, they have to perform it 2^128 times for each, which is computationally infeasable at this time, let alone the storage requirements.

There's no point in keeping the salt secret - it serves those two purposes without any need for more secrecy than the password hash itself.

Upvotes: 2

Related Questions