It might be overkill to have a sitewide salt in the mix. If somebody
gains access to your system, more than likely they can read the sitewide
salt from a source file.
Usually, SHA(pwd + salt) is fine. The algorithm is important so sha
512 is good but slow as well. The longer the salt; the better. The
more random the salt; the better. I tend to use UUIDs for salt because
it's important to use unique salt values.
Adding in a sitewide salt is no different than just using a longer user
salt except that the site wide is mostly static (bad). The more
characters in the salt means that computing rainbow tables takes longer
because more bytes have to be crunched. Just be sure to store the salt
in the database in plain text.
.pjf
Jason Allen said the following on 12/05/10 13:26:
Ok,
I'm going to use SHA-512 just because I can.
When the user submits their password (when creating an account)
I will (in crude mockup code)
set usersalt = rand(0-9,a-z)
set pw_pre_hash = 'form.password + sitewidesalt + usersalt'
set pw_hash = hash(pw_pre_hash, "SHA-512")
insert into user table
pw_hash, usersalt
This way, when I need to chekc their password I just fetch their hash
and usersalt then combine their submitted password with the usersalt
and sitewidesalt, and compare it to the hash.
Good enough?
--
Open BlueDragon Public Mailing List
http://www.openbluedragon.org/ http://twitter.com/OpenBlueDragon
mailing list - http://groups.google.com/group/openbd?hl=en
!! save a network - please trim replies before posting !!
