[TriLUG] don't understand salt

[Igor Partola]

Not an expert here, but have dealt with storing passwords before...

Let's say Joe and Igor are users of example.com. Igor chooses "monkeybar"
as his password. The simplest way to store it is password =
md5("monkeybar"). In other words in the database, it is stored as
"6f832b297a61aef3dfd2c5222d381b14".

There are two problems with that. First, if someone ever computed this md5,
it may now be a part of a rainbow table, a lookup table from cleartext =>
md5 (or sha1, etc.) See
https://www.google.com/search?q=6f832b297a61aef3dfd2c5222d381b14&ie=utf-8&oe=utf-8&channel=fsfro
example. Second, Joe may also chose his password as "monkeybar". Now
the attacker sees this:

igor - 6f832b297a61aef3dfd2c5222d381b14
joe - 6f832b297a61aef3dfd2c5222d381b14

This means that both Joe and Igor used the same password. Typically, the
same password will be used by a large percentage of people. This may also
imply that it's a common password based on a dictionary word. An attacker
would go for this password first.

Now, fast-forward to modern best practices. First, md5 is not end-all be
all (but let's keep using it as an example until later). Thus, we want to
store the algorithm. Let's do it like so: "algo$hash", where $ is used as a
field separator. Thus our attacker will see:

igor -  md5$6f832b297a61aef3dfd2c5222d381b14
joe - md5$6f832b297a61aef3dfd2c5222d381b14

The password hash is still the same. So let's salt it. First we pick a few
bytes of data for each user (this could even be their username). Let's say
for igor we pick "abc" and for joe we pick "xyz". Now the final password
will be md5( salt + "monkeybar" ). The way we will store this is
"algo$salt$hash". The attacker will see:

igor - md5$abc$f00e04f4b9266eb826f6e908bb5fd899
joe - md5$xyz$7acad5a537669274cf34689a547c1a57

Notice: the two final hashes are different from each other. Since the
attacker cannot reverse the hashes, he cannot figure out that the cleartext
is the same for both. Moreover, try googling the hashes; you will not find
them since "abcmonkeybar" and "xyzmonkeybar" are not currently a part of
any published rainbow tables.

When your user tries to log in, you simply look up the algorithm and the
salt used for them and then compute algo( salt + cleartext ) and compare
the result to "algo$salt$hash" in your database. In other words the
attacker and you both see the cleartext salt: it is not a secret. However,
it does add extra security.

A side note: you could even get more complicated and add a second,
system-wide salt. Thus password = algo( user_salt + system_salt + cleartext
). This may possibly add a bit of security in the case where your attacker
has access to your database (let's say via SQL injection), but not your
processes or filesystem.

Last thing I'd like to say is about hash functions. md5, sha1 and sha256
are not meant to be used for password storage. An attacker who sees
md5$abc$f00e04f4b9266eb826f6e908bb5fd899 will still be able to crack it
very quickly since md5 is a very quick hash to compute, especially on a
GPU. What you want is a function that takes a long time per hash to
compute, even on a cluster of GPU's.

I know of three functions currently being recommended: bcrypt, scrypt and
PBKDF2. It seems that bcrypt is a bit more popular, but really both are
recommended. With these functions you get to tune (system-wide) how long it
should take (via an abstract work factor) to compute each hash. As
computers get faster, you will want to increase the work factor to reflect
this.

Thus your user has to wait 0.5 seconds to authenticate, which they will
forgive you. However, an attacker trying to compute millions to billions of
hashes will now have to wait quite a while to see any results.

In other words if you are using unsalted passwords, please salt them. If
you are not using bcrypt or scrypt or PBKDF2, please switch as soon as you
can. You can even do this such that your users will not know the
difference:
http://blog.jgc.org/2012/06/one-way-to-fix-your-rubbish-password.html

Hope that helps.

Igor

On Sat, Jun 9, 2012 at 8:53 AM, Joseph Mack NA3T <jmack at wm7d.net> wrote:

> On Sat, 9 Jun 2012, Chris Short wrote:
>
>  This might help you get a better idea:
>> http://queue.acm.org/detail.**cfm?id=2254400<http://queue.acm.org/detail.cfm?id=2254400>
>>
>
> thanks. I've already read this (and googled for articles on salting) and
> although it tells me why I need a salt (which I already knew), it doesn't
> tell me how the salt is stored securely for later authentication.