[aur-dev] [PATCH] Support for salted passwords
Hi archers, Here's a patch that adds support for storing salted passwords in the database. The salt is a random string for each user and is stored along with the password in the Users table. Salt is created and password is salted when old users log in. New users get salted passwords when they register. What do you think? Denis.
On Mon 05 Apr 2010 09:50 -0400, Denis Kobozev wrote:
Here's a patch that adds support for storing salted passwords in the database. The salt is a random string for each user and is stored along with the password in the Users table. Salt is created and password is salted when old users log in. New users get salted passwords when they register. What do you think?
Hi Denis. I thought the idea behind salt is that if someone gets the database, they can't crack the passwords because the salt is secret. If you include the salt in the database, then it wouldn't be much more difficult to crack than the regular password hash, would it? So how would we go about keeping the salt secret if it's in the same database as the password hashes? I might not fully understand the concept though.
On Thu, Apr 15, 2010 at 2:00 PM, Loui Chang <louipc.ist@gmail.com> wrote:
On Mon 05 Apr 2010 09:50 -0400, Denis Kobozev wrote:
Here's a patch that adds support for storing salted passwords in the database. The salt is a random string for each user and is stored along with the password in the Users table. Salt is created and password is salted when old users log in. New users get salted passwords when they register. What do you think?
Hi Denis. I thought the idea behind salt is that if someone gets the database, they can't crack the passwords because the salt is secret.
If you include the salt in the database, then it wouldn't be much more difficult to crack than the regular password hash, would it? So how would we go about keeping the salt secret if it's in the same database as the password hashes?
I might not fully understand the concept though.
That's not fully correct. Salt is not meant to be secret; it is meant to prevent the use of rainbow tables or precomputed hashes. The idea behind salt in this case is for each user's password to be hashed with a different salt. This means if someone is to crack one person's password, it doesn't help them at all with the remaining passwords in that same database that they got their hands on because the salt is unique for every user. -Dan
I don't want to confuse the issue by introducing another, but while we're on the topic... A salt is exactly what Dan described, the salt value is not secret, in fact it's usually stored right next to the hashed password, or concatenated to it, in many cases. To put it in a more concrete sense.... let h(x) = hash of string x , S=a salt value, and P=plaintext password (and ^ is concatenation). Typically what you store in the database for salted passwords is : S ^ h(S^P) There is another related concept, called pepper, which introduces a very small amount of random data which is not recorded anywhere, but is concatenated to the salted password prior to hashing. Typically a byte or 4 bits of data are used for this. The idea being that it is relatively inexpensive for the server to try up to 256 different peppers... but for a bruteforce attacker it adds 2 orders of magnitude more guessing per password. For these, what you store in the database is : S ^ h(pepper ^ S ^ P) . -Simo On Thu, Apr 15, 2010 at 2:10 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Thu, Apr 15, 2010 at 2:00 PM, Loui Chang <louipc.ist@gmail.com> wrote:
On Mon 05 Apr 2010 09:50 -0400, Denis Kobozev wrote:
Here's a patch that adds support for storing salted passwords in the database. The salt is a random string for each user and is stored along with the password in the Users table. Salt is created and password is salted when old users log in. New users get salted passwords when they register. What do you think?
Hi Denis. I thought the idea behind salt is that if someone gets the database, they can't crack the passwords because the salt is secret.
If you include the salt in the database, then it wouldn't be much more difficult to crack than the regular password hash, would it? So how would we go about keeping the salt secret if it's in the same database as the password hashes?
I might not fully understand the concept though.
That's not fully correct. Salt is not meant to be secret; it is meant to prevent the use of rainbow tables or precomputed hashes.
The idea behind salt in this case is for each user's password to be hashed with a different salt. This means if someone is to crack one person's password, it doesn't help them at all with the remaining passwords in that same database that they got their hands on because the salt is unique for every user.
-Dan
On Thu, Apr 15, 2010 at 3:10 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Thu, Apr 15, 2010 at 2:00 PM, Loui Chang <louipc.ist@gmail.com> wrote:
Hi Denis. I thought the idea behind salt is that if someone gets the database, they can't crack the passwords because the salt is secret.
That's not fully correct. Salt is not meant to be secret; it is meant to prevent the use of rainbow tables or precomputed hashes.
The idea behind salt in this case is for each user's password to be hashed with a different salt. This means if someone is to crack one person's password, it doesn't help them at all with the remaining passwords in that same database that they got their hands on because the salt is unique for every user.
Dan is right - salted passwords are used to reduce the efficiency of rainbow table attacks on the database. I'm no security expert, but it is my understanding that assigning a random salt to each user is considered pretty secure. Some implementations are even simpler - there is a single salt for all passwords in the database, the idea being that an attacker wouldn't be able to use a readily available set of rainbow tables and would have to compute his own set for the salt used. Such implementation is used by CakePHP web framework, for example. Denis.
participants (4)
-
Dan McGee
-
Denis Kobozev
-
Loui Chang
-
Simo Leone