[SOLVED] What it be a good idea to store the salt value in a table in your database?

[limitphp]

As I'm testing, if I ever update the salt, I have to make sure I update the $salt variable in every page I use it.

 

Would it be a good idea to just store it in a table and use the value from there?

 

I understand that once I go live and have active accounts, I can't update the salt, right?

[rhodesa]

"can't update" isn't 100% true. you need to know the salt to be able to encode the new password for comparison. the crypt function for instance prepends the output with the salt:

http://us2.php.net/manual/en/function.crypt.php

[premiso]

the crypt function for instance prepends the output with the salt:

 

Why would it be wise to store the salt as being prepended to the hash? Wouldn't that give someone who wants to access your site a leg up knowing the salt?

[rhodesa]

i am in no way an expert in this, but pulling reasons out of my ass...i would assume it's for portability. say you (worst case) loose your php code (so your salt is gone). every password is now worthless.

[premiso]

i am in no way an expert in this, but pulling reasons out of my ass...i would assume it's for portability. say you (worst case) loose your php code (so your salt is gone). every password is now worthless.

 

Yea, that would make sense...actually...weird? lol. But it still seems like a security flaw, imo. But I guess doing it that way, you could create a unique salt for each user, you just have to strip the first x characters off the string and re-use that salt.

 

Now that would probably be securer then using the same salt for everyone...interesting.

[limitphp]

i am in no way an expert in this, but pulling reasons out of my ass...i would assume it's for portability. say you (worst case) loose your php code (so your salt is gone). every password is now worthless.

 

if you loose your code, and have no way of getting it back, wouldn't salt be the least of your problems?

 

right now I do this:

salt = some value;

password = lowercase password

password = password.salt

hash(password);

 

but I don't like having to update the salt on every page ever time I get the urge to update my salt to something "even better".

[GingerRobot]

Storing the salt in the database is a bad idea. The entire point of salting passwords is that, even if someone did get hold of your encrypted password, it would be difficult to find the original string. How would they get hold of your password? Well, that's likely to involve some sort of unauthorized database access. Hey-ho, they found the salt too.

 

Of course, they'd still have to brute force the password as any pre-compiled rainbow tables would be pretty useless, but it'd still be a damn sight easier.

[bluesoul]

Oddly enough vBulletin stores the unique salt for each user as well, but in it's own field as opposed to prepended to the password.  From a security standpoint I can't see how that's any safer than no salt at all.

[premiso]

Storing the salt in the database is a bad idea. The entire point of salting passwords is that, even if someone did get hold of your encrypted password, it would be difficult to find the original string. How would they get hold of your password? Well, that's likely to involve some sort of unauthorized database access. Hey-ho, they found the salt too.

 

Of course, they'd still have to brute force the password as any pre-compiled rainbow tables would be pretty useless, but it'd still be a damn sight easier.

 

So what is the point of crypt? To be a security flaw? I fail to see why you would want to use that if it shows user's the salt...

[limitphp]

ok...so bad idea.  I won't be doing it....

thanks guys...

[gevans]

If you're going to store the salt in the database you may as well just hash the password and screw the salt altogether. It's like having two locks on your front door and leaving one of the keys on top of your mat

[PFMaBiSmAd]

The weakness with storing sensitive information in a database is that on shared hosting the database server is shared and is often remotely accessible and anyone having access to it can usually see all the database names and can sit there running unlimited username/password lookups until they find a database that did not have strong enough username/password.

 

Storing a single salt someplace that is accessible using the same username/password that allows access to the hashed passwords is just making it easier for a hacker. Using and storing a unique salt for each password just means it takes longer for someone to find a password + salt that matches (http://www.phpfreaks.com/forums/index.php/topic,234999.0.html)

 

On a shared server, assuming that file permissions are set up correctly on your server so that the other accounts cannot read your files and that you have strong username/password on your control panel and any FTP accounts, having a single salt in a configuration file (or in your script) is actually safer than in a shared database server. Most control panels/FTP accounts have bad password attempt lockout while at least a mysql server does not.

 

Anything requiring security should not be done on shared servers; remote access to database servers should be disabled; strong and different username/passwords for control panels, FTP accounts, and database connections... should be used.

[rhodesa]

but I don't like having to update the salt on every page ever time I get the urge to update my salt to something "even better".

 

to answer you question...i would use a configuration file. a simple example is:

<?php
  $config = array(
    'foo' => 'bar',
    'pass_salt' => 'myPassSalt',
  );
?>

then, on your pages, include the config file:

<?php
  require_once('config.php');
  echo $config['pass_salt'];
?>

 

this way you only have to update the values in one place. obviously this is a basic example. you will want to keep config.php outside of the web directory (if you can) or put it in a folder with 'deny from all' htaccess file in it

[limitphp]

.....

[bluesoul]

having a single salt in a configuration file

 

How would you do that?

What is a configuration file?

 

You're creating a physical PHP file that has the salt as a string.  You can then include() the file as necessary and make use of the salt that way.

[limitphp]

require_once('config.php');

 

I don't understand the require_once function....

what is config.php?

 

 

 

 

[limitphp]

having a single salt in a configuration file

 

How would you do that?

What is a configuration file?

 

You're creating a physical PHP file that has the salt as a string.  You can then include() the file as necessary and make use of the salt that way.

 

So I could create a file called salt.php

and salt.php could be something as simple as $salt = "some value";

?

 

 

[bluesoul]

having a single salt in a configuration file

 

How would you do that?

What is a configuration file?

 

You're creating a physical PHP file that has the salt as a string.  You can then include() the file as necessary and make use of the salt that way.

 

So I could create a file called salt.php

and salt.php could be something as simple as $salt = "some value";

?

 

Absolutely.  Just make sure it's a PHP file and not plain text, so it gets processed instead of displayed to the web. (ie, salt.php and not salt.html)

[premiso]

So I could create a file called salt.php

and salt.php could be something as simple as $salt = "some value";

?

 

I wouldn't so bluntly name it that. Use a hash or something like mysite.php. I would also put it outside the root of the www directory so it cannot be accessed via the web. Heaven forbid a functionality issue with your site and php files were made viewable...