6

I have two salts, each user has a unique salt that is stored with the user info in the database. The second salt is one that is specific to the website. Both are needed to hash the passwords.

Problem is I don't know where I should keep my website salt. Right now it resides in the PHP method that runs the hashing algorithm. Should I keep it in a file outside the /var/www/ and have PHP open and read the file? I don't want to store it in the database because that would defeat the purpose of having two salts should my database be compromised.

Any suggestions?

ircmaxell
  • 163,128
  • 34
  • 264
  • 314
Stephen Gilboy
  • 5,572
  • 2
  • 30
  • 36

5 Answers5

13

One option not mentioned yet? An environmental variable served by the server. You can do it in httpd.conf, or in a .htaccess. Since Apache doesn't serve .htaccess files, you don't need to worry about hiding it as much...

SetEnv WEBSITE_SALT 232lhsdfjaweufha32i4fv4239tauvkjn

That way, all you need to do in your application is $salt = getenv('WEBSITE_SALT');. The benefit here is that it's transparent to the application...

ircmaxell
  • 163,128
  • 34
  • 264
  • 314
  • 2
    Why isn't everyone upvoting you? This is great! – Undo Apr 03 '13 at 13:42
  • 1
    I can see a problem here. In most applications, users have the same passwords like "password" or "letmein". If you generate an MD5 hash of the same value with the same salt, then the same hashed value is generated, thus allowing a potential attacker to detect patterns and pwn the user passwords in the application. I tried the same salt with python's hashlib: (extract below) `plaintext = 'Hello World' salt = '232lhsdfjaweufha32i4fv4239tauvkjn' h1 = hashlib.md5(salt + plaintext).hexdigest() h2 = hashlib.md5(salt + plaintext).hexdigest() print h1 == h2 >> True` – Abhay Bhargav Jun 02 '16 at 03:27
5

Yes, keep it in a PHP config file somewhere, preferably in a folder above the directory that is the web root.

Summer
  • 2,488
  • 3
  • 23
  • 32
1

Storing the website salt in a file that can never be served is your best option here. There's no point in encrypting the salt, or keeping it with the others as you pointed out. Just make sure the file you store it in cannot be served if requested (outside the root www works) and ensure it has proper permissions set.

ventaur
  • 1,821
  • 11
  • 24
-1

Just stick it in a variable inside a .php file. For a minor bit of added security-by-obscurity, you can store it in (say) base64-encoded format, and name the variable something completely innocuous, like

$this_is_not_the_salt_you_are_looking_for = base64_decode(.... encoded salt string here ...);

For an extra-extra bit of security, place the .php file somewhere outside the webroot, so that if for some reason the webserver's config goes belly up and starts serving up raw PHP code, the file containing the salt info isn't directly accessible.

Marc B
  • 356,200
  • 43
  • 426
  • 500
-3

Most people will store a constant salt in a configuration file. This is fine, but the whole point of using a SALT is to ensure your data is not readable by an outside source.

I've seen a lot of people actually store the salt in database in the accounts field. Here's the twist though. It was uniquely generated upon account creation so every user has a unique salt.

It's not about the salt though--it's about how you're encrypting the data.

sha1($password.md5(md5($password.md5($salt))))

Even with the salt you would likely never be able to crack this. So never worry about storing it in your database if you decide to go unique per account. Just ensure that your encryption process is strong!

BGPHiJACK
  • 1,277
  • 1
  • 8
  • 16
  • First, don't feed the output of one hash function into the input of another directly. That's not good. Second, just do a normal stretching rather than that odd looking code. See [this post](http://stackoverflow.com/questions/4948322/fundamental-difference-between-hashing-and-encryption-algorithms/4948393#4948393) for more information... And hashing != encryption. There's a huge difference... – ircmaxell Feb 17 '11 at 22:39
  • also using special math algorithms your double password md5 hashing can be reverse engineered (especially since MD5 isn't safe at all anymore) – xorinzor Dec 04 '12 at 21:18