locked
Salted-Hash Password questions RRS feed

  • Question

  • Hello all.
    I wanted to find a secure and fast way to store passwords in a database and I found some interesting examples on the Internet with salted hash, which proved to be more secure than a simple hash. First of all, should this salt be unique? What I mean is when the user logs into the system, should the resulting hash be computed using a fixed array of bytes for the salt(like password for a two way encryption algorithm) ? Second question regards the optimization part. If I want to implement this in a real-life application the recomandation is to keep the salt separate from the password. What exactly doeas this mean? To have a separate column in the database?
    I'm sorry if this questions seem stupid to you, but i'm new to the field of cryptography and I never faced this task before.
    Best regards,
    Ariel

    Wednesday, February 27, 2008 6:20 PM

Answers

  • The reason for the salt is to prevent dictionary attacks against the hashes, where the attacker has a pre-computed set of hashes and passwords that map to them. Using a salt common to all passwords is better than nothing as it makes it unlikely that the attacker will have a pre-computed dictionary of hashes using that salt, however if they could find out your salt it would make it possible to compute a dictonary and crack the passwords. Using a unique salt per password is the best, however, as it makes it pointless to compute a dictonary as it would only work on one entry.

    Because the salt is used only for this reason, there's no need to encrypt or otherwise obfuscate it, you can simply store it alongside the password hash in a separate column, e.g.

    PasswordHash BINARY(256)  -- or whatever your password hash size is
    PasswordSalt BINARY(16)  -- or however big you make your salt

    The salt itself doesn't have to be very big. A couple of bytes is fine as hash functions are designed to have very different outputs for slightly different inputs.

    Another option worth considering for performance reasons, however, is to use the user name as the salt. This is trickier as you need to canonicalize it (e.g. make sure you always convert to lower case and use a specific encoding to convert the string to bytes) and you also need to update the password hash if the user ever changes their user name, but it allows you to compute the hash directly on login without looking up the salt from the database. How high you need your performance to be dictates whether this extra complexity is worthwhile.
    Wednesday, February 27, 2008 11:57 PM