Re: store salt in database

amygdala schrieb:

But what then is the surplus value of the salt if it is stored in the record
of the user? To my understanding the salt is used to make it difficult to
apply 'brute force' to decypher passwords, if the database is compromised by
a hacker, right? But if a hacker knows the salt, cause it is stored in the
same record next to the hashed salt+password, applying 'brute force' to it
would just as 'easy' again, wouldn't it?

Yea and No :-)

Think about this, you have a database of one million users and you do
not use salts at all. I bet there will be a lot of users who a) use a
guessable password and b) many who use the same password.

With unsalted password hashes, a hacker could take a dictionary, compute
all hashes over it and store it in a database. Then he can reverse
lookup the hashed he has stolen to get the password. Even worse, he can
check if there are duplicates in the stolen hashes and he will know that
all of these users use the same password. To compute a dictionary of say
one million entries is easily possible.

Now to salts - before hashing the password you add a random salt of some
bytes (lets say just 4) to the password and store them along with your
hash. If a hacker now wants to do a lookup like above, he has much more
work to do. He knows the salt and needs to guess the password - he can
use his dictionary and compute a hash for every entry and the salt. He
needs exactly the same amount of time and space like above to crack a
single entry. But -

- he can't precompute his dictionary for every salt - 4 Bytes are 32
Bit, there are 2^32 possible salts - 4 billion times more space and
compute power is needed to create and store such a database

For exampke take my one million passwords all 20 characters long and a
128bit hash - both need 52 Bytes together, a total of about 50 MByte
is needed for a lookup table without salt.

With 32 bit salt, he needs to compute such a table for every possibile
salt, 2^32 * 52 * 10^6 = 2 * 10^17 Bytes (one PetaByte is 10^15
Bytes).

- if he can't see before computation who uses the same password, except
if two users have the same password and salt

So, cracking a single password is as easy as without a salt - but salts
make precomputed (and faster) attacks much more compilcated.

Cheers,
Jan


.

Relevant Pages

  • Re: Proposal for Lite Encryption for Login Form without SSL
    ... This way the password is not sent to the server ... simply copy the server-side salt used to hash the pw in the ... password in the database, it does make public the server-side salt ... This would be the equivalent to a public key in public key encryption ...
    (comp.lang.php)
  • Re: Is this secure
    ... I use SHA1 to hash my passwords. ... Both the hashed password and salt are stored in the database. ... but then i'd need the salt to create a saltedhash to compare ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: UsernameTokenManager and a hashed password database
    ... your SALT value is the password now... ... >> should be able to reconstruct the cleartext pwd based on the 'shared ... > here and is definitely an unknown at the server-side database. ... If a hacker steals the hash from ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Simple VB.NET Web Application Encryption/Decryption of password
    ... It looks like Michael answered your second question. ... contains a hash and salt, you would return a byte array containing the hash ... SQL 6.5 (it depends on some database settings, ...
    (microsoft.public.dotnet.security)
  • Re: Is this secure
    ... I use SHA1 to hash my passwords. ... Both the hashed password and salt are stored in the database. ... but then i'd need the salt to create a saltedhash to compare ...
    (microsoft.public.dotnet.framework.aspnet)