It's always good to be extremely (perhaps even overly) concerned with
security, particularly passwords when it comes to securing applications.
There's a couple of thoughts I wanted to throw into this discussion that
I think it is important to remember.
* No implementation of computer security is ever full-proof
The goal of security is not to build a completely impenetrable wall. To
attempt to do that is futile because all walls are penetrable. The goal
is to build a big enough wall such that invaders, with a realistic
amount of resources, cannot intrude. Over time, the wall will need
repairs and upgrades, this is a given.
In computing, given enough time, computing power, advances in
technology, and in some cases, enough desire, all security precautions
can be defeated.
* When hashing, choose a reasonably secure enough, yet supported
method of hashing.
That basically means don't try to create your own hashing scheme, and
also, don't try to use a completely obscure hashing scheme. Wikipedia
is good at discussing the strength and availability of a particular
hashing scheme, and that is generally enough information to decide if a
particular scheme is for you. This might include information on
computation power needed to iterate, how prone it is to dictionary
attack and if collisions can be found, and if so, how easily.
* Salt each row. It doesn't matter where it's stored.
I usually store the salt in the row with the password. The thing is, if
they are keen enough to get your database, they are probably keen enough
to get the code running the site- at this point, it doesn't really
matter where things are stored, all of the ingredients are available.
So, why salt each row? The best analogy is that since, in computers,
building a wall is easy, the idea here is that instead of building a
single wall around the city, we'll build walls of equals strength around
each person. This means that basically if an attacker gains access to
everything, they still need to start demolishing each wall that was built.
In hash based security, attackers are typically going to use a
dictionary attack. Generally, unless they have access to large amounts
of computation power, they are not trying to "crack the password", they
are simply trying to find a way to reproduce the hash in your database.
This is typically done via a dictionary attack. Now, since you've
created a salt per user, instead of them caching the results of a single
salt through the known algorithm and checking those results against all
the hashs in your password table, they will need to do this process for
each and every user since the salt per user is different.
The difficulty basically went from:
difficulty = computational resources * hash speed
to
difficulty = computational resources * hash speed * number of users
As you can see, the difficulty went up linearly per user of the site
that is added. This alone might sometimes prove as a deterrent to
attackers when it comes to security.
Another thing to remember, not that this is much of a consolation, is
that at this point, the attacker has extrapolated a collision for the
hashed password, there might be a good chance (depending on the
algorithm used) that the source of this collision is not actually their
password. And hopefully, their bank is using a different algorithm than
you, so the source for this collision wont log the attacker into their
bank account.
-ralph
On 8/31/10 7:39 AM, Peter Sharp wrote:
I think that storing a per user salt and a site salt and using both in
your password hashing scheme is about the best you can really do.
If a hacker gets into your database in a way that allows them to reveal
structure and uncover your salt value, then they still won’t be able to
replicate the original password without knowing the site salt, which is
stored in code, not the database (unless your site salt is too simple).
If they can access code and database then all is lost anyway.
But this fear that a hacker might be able to get the value for the user
salt if it’s just in a column names salt in the user table is a little
bit redundant really. If they can get the salt value, then they’ll
pretty much be able to access everything else so they no longer really
need your site at all. Why try to find the key when you’ve already
busted down the door?
Also, and I hate to say it, but if a user is for some reason using their
banking password for any other public site, then they must wear the
lions share of the responsibility if or when it is discovered and used
by a malicious user. I mean, you have a role to play in the users
security, but so do they.
*From:* Hector Virgen [mailto:djvir...@gmail.com]
*Sent:* Tuesday, 31 August 2010 3:56 PM
*To:* Bill Karwin
*Cc:* fw-general General
*Subject:* Re: [fw-general] Re: Guidance on storing passwords securely
Bill, do you have any concerns about hackers recovering the user's
original (raw) password to log into their other accounts such as
banking? That's where I see the salt coming in as a protective measure
-- they would need the db as well as the code to discover the password.
--
Hector Virgen
Sent from my Droid X
On Aug 30, 2010 10:50 PM, "Bill Karwin" <b...@karwin.com
<mailto:b...@karwin.com>> wrote:
>
> On Aug 30, 2010, at 10:29 PM, Ralf Eggert wrote:
>
>> interesting stuff. But where should the distinct salt per user be
>> saved?
>> It feels quite wrong to store it in the database right beside the
>> password. Or should it be combined from, lets say: user id, email
>> address and registration date?
>
> Ideally the salt should be more strongly pseudorandom. You don't need
> to use any constant or other user-related field in the calculation of
> the salt. Just make it as random as you can make it. And make sure
> you use a distinct random salt per user.
>
> If the attacker gains access to make queries against your database,
> you've lost the game anyway, so storing the salt in a column named
> "salt" in the same table with the hashed password is not significantly
> riskier than storing the salt anywhere else that the attacker gains
> access to.
>
> In other words, don't rely on security by obscurity. Don't even favor
> security by obscurity. In some ways, I think it's better *not* to
> make your code or database obscure at all, if that encourages you to
> strengthen more effective security measures to prevent attackers from
> gaining access.
>
> Regards,
> Bill Karwin
