Whats wrong with storing your salt in DB?

[Demonic]

Apparently if you store your salt in db the cracker has more change of cracking passwords then again if they can get a hold of your db then they have access to cpanel right, then they have access to your files, and if you didn't store salts in db but in the files what makes it so they just wont use the salt from the file, which would take shorter time to crack passwords if they get your hashed pw's from your db, then when you have a whole bunch of random salts the cracker would take forever to crack the hashes, what makes this safe anyways?  Either way theres no real way to hash your passwords to make them safe.  Like in "Pro PHP Security" said, "nothing on the internet is un-vulnerable".

[MadTechie]

Storing the salt in the database is fine.. BUT its "recommened" you store them in related table..

personally i store them in the same table.. as if they get access to see the hash and/or salt then i have a major security which i watch for from the first day of development

[Demonic]

Storing the salt in the database is fine.. BUT its "recommened" you store them in related table..

personally i store them in the same table.. as if they get access to see the hash and/or salt then i have a major security which i watch for from the first day of development

 

Yeah the salt is stored in the same table as the password or is that a nono?

[tibberous]

I just use a md5('!h6'.$password.'8mj'). That way if my hash list was to get stolen it couldn't be ran against a md5 database, and even if they got my algorithm, it would mean creating a new database. Guess a salt would be better, since then it would mean making a new database per password.

 

How about this:

 

md5('!h6'.$password.substr($password,-1).substr($password,0,2))

 

Wow! That accomplishes everything that a salt would, except you don't have to store it.

 

Damn that is awesome, from now on, that is how I'm doing my hashes.

[MadTechie]

Yeah the salt is stored in the same table as the password or is that a nono?

Its a no no to some people.. i don't have a problem with it myself.. providing you check the security

 

 

 

I just use a md5('!h6'.$password.'8mj'). That way if my hash list was to get stolen it couldn't be ran against a md5 database, and even if they got my algorithm, it would mean creating a new database. Guess a salt would be better, since then it would mean making a new database per password.

 

How about this:

 

md5('!h6'.$password.substr($password,-1).substr($password,0,2))

 

Wow! That accomplishes everything that a salt would, except you don't have to store it.

 

Damn that is awesome, from now on, that is how I'm doing my hashes.

 

No thats not as good as salt...

 

you CAN have a Site Salt as well IE

$SiteSalt = "1234"; //<--static

$password = "Hello"; //<--User set

$UserSalt = "fdsfs"; //<-- Random for each user

 

$StoredPassword =  md5(md5($UserSalt).md5($password).$SiteSalt);

[kratsg]

Here's what you need to stray away from:

 

A non-changing constant salt, IE: "site salts". However, there are two types of salts you can go with, both of them are non-constant salts. One of them is having a random generation of numbers for each user that is stored in the database, either in the same table or a related table, as mentioned prior. Another changing salt is to base it off the password. I prefer literally taking the whole password, chopping off the ends, and reversing them to create my salt. This way, if I do the same method for each password, the salt for each password would be DIFFERENT.

 

Pass = alphabet
Salt = ebahpl
Pass = 1alphabet
Salt = ebahpla
Pass = notthealphabet
Salt = ebalhplaehtto

 

As you can see, it makes all the difference, and I doubt a hacker would spend his time chopping and reversing for each password.

[rarebit]

OK, say i'm a hacker, if I was going to use a hash look-up table (for it to be of any use!), i'd obviously have access to the database, therefore if your storing the salt in the db, then i'd also probably have access to that as well, and would then be able to generate a new salted hash look-up table.

 

Basically it is better to store the salt data in a different place than within the database, then the hacker needs to dump the database and also hack the ftp to get at the source files of the cms / site (supposing that the site is secure enough not to allow them to do this from online).

 

An even more secure way of using this method is for a different salt (algorithm / data) to be used depending upon the first letter(s) of the plaintext passphrase.

[MadTechie]

An even more secure way of using this method is for a different salt (algorithm / data) to be used depending upon the first letter(s) of the plaintext passphrase.

 

Which is way i said you can also have a site password, this will be in the config file.. thus you need both salts and the users hash if they get all 3 then you need to re-think the whole site security as you must of messed up big time!

[rarebit]

I'd consider giving up or asking Matt to give me a good shoein! (How do yo' spell that?)

[Demonic]

I see it like this, if they have access to your MySQL DB, it won't really matter they deface your site wow. regardless if you have a salt or not they don't know how you added your salt.  IE:

 

<?php
$static = "site1888";
$salt = substr(md5(rand(1,999999)),0,10) . $static;
$pass = $_POST['p'];
$token1 = substr(0,4,$pass);
$token2 = substr(5,strlen($pass),$pass);
$hashed = md5($token1 . $salt . $token2 . $salt);
?>

 

Regardless, access to your hash can be safe and unsafe depending on how you hash it, so hashes in the database is alright for me right next to the password.

 

 

[rarebit]

well some just use crypt option where you just pass the pass and salt. Others like the DIY way

[Demonic]

well some just use crypt option where you just pass the pass and salt. Others like the DIY way

 

I don't use crypt but yeah .

[rarebit]

An even more secure way of using this method is for a different salt (algorithm / data) to be used depending upon the first letter(s) of the plaintext passphrase.

 

Which is way i said you can also have a site password, this will be in the config file.. thus you need both salts and the users hash if they get all 3 then you need to re-think the whole site security as you must of messed up big time!

 

Are you just basing this on a site password? My way uses say 26 (++*2- different ways of salting, and depending upon first char(*s) a different hash is used, therefore the lookup table generated would massive, e.g. a minmum of 26 times the size of a basic lookup,    (8^26)*26 and that's just for a max of 8 char passwords using only char's, (a total of 7.858e24) (I think?)

[MadTechie]

my basic example

you CAN have a Site Salt as well IE

$SiteSalt = "1234"; //<--static

$password = "Hello"; //<--User set

$UserSalt = "fdsfs"; //<-- Random for each user

 

$StoredPassword =  md5(md5($UserSalt).md5($password).$SiteSalt);

[rarebit]

Not quite as safe, but what's the implications of:

        md5(md5(pass))

[rarebit]

Yes I like it mad-techie, yet I presume that the users salt is stored in the db also, yes meaning that each user requires own lookup table generating, and also access to site salt.

 

With my version the possibilities may be less numerous (could be resolved, but still considerable), but no storage of the extra salt would exist other than the password itself, ( and site salt).

 

Therefore even with all possible information (except password) being a given, a lookup table could be generated for yours but not for mine (it would require one for each salt function, and if this also based the init for the function based upon the password itself then it also gains the safety as yours as well)!

[PHP_PhREEEk]

Now I'm thinkin' pepper...

 

yeah...

 

PhREEEk

[MadTechie]

Therefore even with all possible information (except password) being a given, a lookup table could be generated for yours but not for mine (it would require one for each salt function, and if this also based the init for the function based upon the password itself then it also gains the safety as yours as well)!

 

Erm.. i think your wrong on that.. a lookup table can exist on both.. but mine would be much larger and longer to lookup.

[rarebit]

No yours would be a single table, the other way would require multiple look up tables. Also certain data would be unknown because it's generated by the data within the unknown passphrase itself...

[MadTechie]

My way uses a phase stored in a config.php file which is not part of the SQL system and the tables doesn't have to be a single table!

 

i fail to see how you can even consider that

        md5(md5(pass))

is safer than

you CAN have a Site Salt as well IE

$SiteSalt = "1234"; //<--static

$password = "Hello"; //<--User set

$UserSalt = "fdsfs"; //<-- Random for each user

 

$StoredPassword =  md5(md5($UserSalt).md5($password).$SiteSalt);

 

[Wolphie]

I did search salts on here and it found this topic, hence the reply so late - Because i was trying to understand how they were used.

So I don't infact use a salt stored in a database.

I've modified tibberous's method:

 

<?php
function secure_password($password) {
$password = md5(sha1('!h6' . $password . substr($password, -1) . substr($password, 0, 2)));
$password = sha1($password . '@^$' . md5($password));
$password = str_rot13(substr($password, 3) . 'zFq');
$password = sprintf('%s%x', $password, crc32($password));
return $password;
}
?>

 

I used crc32 to give it an unusual length.

[maexus]

I've read through most of this thread and here is my thoughts. Actually securing your database is the most important thing. If they have access to your database, any sort of hashing techniques are only going to slow someone down. Security through obscurity is not the answer.

[Wolphie]

Well, people gaining access to your database is inevitable, however people cracking hashed passwords is also inevitable one way or the other. So if slowing them down as much as possible is the only thing you can do then so be it - I'd rather slow someone down giving me a chance to catch them, rather than using a weak encryption method and them getting all my important data easily.

[kratsg]

I've been thinking... a hacker does not need to have passwords at all.

 

If he has access to the database, he could just as easily register with the site (creating his own, KNOWN, password) and copy that over to multiple user accounts and just as easily gain access... right?

 

It's almost like there's no surefire way to stop this method.

[aschk]

I was all geared up (after reading all the but the last post) to say that it doesn't matter whether you use a salt or not to store passwords in your database.

They ALREADY have access to all the data they're ever going to need. They can modify/add/alter anything they want already because they can connect to MySQL as an authenticated user (as you stated in your original spec for this thread).

 

However, the only thing that they won't be able to do is add another user (to the user table) and then use the website, because they won't know your hashing technique. Why would they want to use the website anyway if they already have their hands on all your data