Salting passwords.

[lynxus]

Hi guys,

Im looking at putting a salt on my md5'd passwords.

 

However is this going to be an issue with current passwords that are md5'd ?

 

Evidently i dont know the users passwords, only the md5 of it. So salting wouldnt work unless i started again ?

 

Or am i looking at this wrong?

 

Evidently id need to salt new passwords, buta dding a salt to already registered users is impossibe?

 

or maybe should i just stick to MD5'ing passwords?

 

Thanks

G

[MadTechie]

depends on how your salting

ie, if you used this

md5(md5($pass).$salt)

then you could update the existing hashes with

md5($existingpass.$salt)

 

EDIT: another option is a midway option where you have 2 fields 1 being the current password and 1 being the new password, if the new password is empty use the old one, but you update the new password on the next valid login, or simply post a message saying you have a new password routing and people need to use the recover password option to reset their password

[5kyy8lu3]

If you felt adventurous you could even use a dynamic salt.  This is similar to what I use:

 

Code that creates the dynamic salt, hashes, then adds salt onto the end product for later retrieval.

 

<?php
$StaticSalt = 'Whatever you want this to be.';
$DynamicSalt = md5(time() . sha1($StaticSalt) . microtime());
$Salt = substr($DynamicSalt, 0, 16); //<-------------cut dynamic salt in half
$Pepper = substr($DynamicSalt, -16, 16);
$Hash = md5($Password . $DynamicSalt);
$SaltedHashbrown = $Salt . $Hash . $Pepper; //add dynamic salt to front/back
?>

 

This is the code you use to pull the salt off to use to check the user entered password against the entry in the database.

 

<?php
$Front = substr($PasswordInDatabase, 0, 16); //<---------------------pull salt off
$Back = substr($PasswordInDatabase, -16, 16);
$ActualHash = substr($PasswordInDatabase, 16, (strlen($PasswordInDatabase) - 32));
$DynamicSalt = $Front . $Back; //<----------------------recombine the dynamic salt
$Comparator = md5($EnteredPassword . $DynamicSalt);
if ( $Comparator == $ActualHash )
{
	//correct
}
else
{
	//incorrect
}
?>

[redarrow]

I find all this salt and crap a wast of time..

 

ye it got it commercial purpose.

 

if you get your users to add a proper unique password then it wont matter if you use salt or not.

 

also adding another column in the database and generate a secret number will also help.

 

the user enter username and password secret number easy as that, no salt what so ever, just use md5 on the password, and secret number, so much easy and secure.

 

like i say hash is good but better off having a more secure idea.

 

remember what man makes man can brake.

 

 

 

 

 

[MadTechie]

redarrow, it seams you need to understand MD5 a little better, hashing isn't the start and end of adding security infact I only use it to limit the damage of the worst case scenario, you may find it a waste of time, well that's your opinion, my opinion is program for the worst, hope for the best.

 

Login/site access security doesn't mean, just MD5 a password,

 

its a shame because you had it right once!

ps. please dont also underestamate the md5 function on it own,

[redarrow]

I no that mate sorry , member(Richard)

 

i just see most users on here, doing non commercial projects and see it a wast off time going thro the pros and cons.

 

they only say at the end yee ok, cheers, and ask agin lol.

 

md5(sh1(md5("redarrow")))

 

that will do unless salt needed in a tough environment.

 

 

[redarrow]

this example is good enough mate.

 

<?php
echo md5(sha1(md5("redarrow")));
?>

 

throwing a example  i would use if i was worried about things.

 

the second example more powerful but is it, the first just as good.

 

<?php

function validateLogin($user,$pass)
{
$sqlSafeUser = this->makeSafe($user);
$sqlSafePass = this->makeSafe($pass);
$hashpass = this->getHashPass($sqlSafePass);
//more code
}
function getHashPass($string)
{
$passLength = count($string);
$salt = substr(md5($string),$passLength,32);
$hashedPass = sha1("/?3".$salt."$%^".$string);
return $hashedPass;
}
?>

[MadTechie]

Not really,

md5(md5("redarrow")."salt")

is more secure than

md5(sha1(md5("redarrow")))

they are rainbow tables for MD5 and SHA1, so 3 lookup could resolved and easy password,

 

using MD5 on SHA1 is pointless since you're passing 128-bits of information to generate a 256-bit hash, so 50% of the resulting data is redundant. thus no security improvement at all!

 

the second method is more secure.. but your using salt thus disproving your first point!.

[redarrow]

And in fact the only reason md5 in classed as a not so secure password protector,

because there online database decoders out there for md5, but in fact, the better you ask your web site users for strict rules for usernames and passwords, the probability off a md5 de coder getting the username and password write is low.

 

 

we live to differ lol

[redarrow]

maybe if you install mcrypt all problems solved

 

http://uk2.php.net/mcrypt

 

<?php
$key = "this is a secret key";
$input = "Let us meet at 9 o'clock at the secret place.";

$encrypted_data = mcrypt_ecb (MCRYPT_3DES, $key, $input, MCRYPT_ENCRYPT);
?>

 

or really go mad and add

http://uk2.php.net/manual/en/book.openssl.php

[redarrow]

please all read this will help a lot.

 

SAYS EVER THINK WITHOUT ANYONE KILLING THERE SELF LOL

 

Of course, one could always use other kinds of

encryption/encoding/obfuscation techniques such as XOR complement, but

this example provides an extremely secure version using methods like

Blowfish, MD5, DES, etc.

 

This took me about 4 hours to figure out and perfect, but the two

functions below will work with PHP on many versions of Linux. I have

RedHat 9, in this case. I designed this to use a pretty small

compression and encryption style, yet work just fine as far as storing

in a cookie.

 

I'm using Blowfish here, but you can switch the "-bf" to other

encryption types. For those of you with Linux, do a "man openssl" to

see the others that are available.

 

The routine isn't bad for a 15 user business app on a 2.4Ghz Pentium.

However, you'll find it's somewhat slow for larger-scale operations,

unfortunately, because you have to write 2 files for each function. If

someone knows how to use openssl without files, I'd be interested to

see your example.

 

function Encrypt($val, $pass) {
$val = str_replace("'", "#%$", $val);
$file = tempnam('','php-encrypt-');
exec("echo -E '$val' > $file.dec");
exec("openssl enc -a -bf -in $file.dec -out $file.enc -e -pass
pass:$pass");
$myfile = file("$file.enc");
exec("rm $file");
exec("rm $file.dec");
exec("rm $file.enc");
while (list($line_num, $line) = each($myfile)) {
$result .= $line;
}
$result = base64_encode($result);
$result = urlencode($result);
return $result;
}

function Decrypt($val, $pass) {
$val = urldecode($val);
$val = base64_decode($val);
$file = tempnam('','php-decrypt-');
exec("echo -E '$val' > $file.enc");
exec("openssl enc -a -bf -in $file.enc -out $file.dec -d -pass
pass:$pass");
$myfile = file("$file.dec");
exec("rm $file");
exec("rm $file.enc");
exec("rm $file.dec");
while (list($line_num, $line) = each($myfile)) {
$result .= $line;
}
$result = substr($result, 0, strlen($result)-1);
$result = str_replace("#%$", "'", $result);
return $result;
}

Here's a sample of how big the encrypted string can be when I used the

password "wow":

6 chars = 44 chars

20 chars = 76 chars

50 chars = 134 chars

100 chars = 224 chars

 

Here's a sample encrypted string:

VTJGc2RHVmtYMSt4azRFdjN2QXlzVkJZRFBMMTdHNmNlQWdGZF F0ZmlkNS9CQndPOGtIOGV3PT0K

[MadTechie]

Well that's even less secure..

why replace HASH (one-way encryption) with encryption (2 way)

(that goes for your first post before you replaced it with the above, and the one above)

 

PS its nice to give credit when you pull from another site

http://www.justskins.com/forums/get-string-encryption-without-reconfiguring-or-recompiling-php-76812.html

[redarrow]

There not such thing as a perfect encrypted username and password.

 

you can add all the best 3rd party applications to anythink you like and by chance someone will

create a stupid username and password like (god god bang your in.

 

so it all comes down to telling your customers to use strict rules to prevent this happening.

 

by adding another column to a database and getting a random number to be entered into the web site is a very secure way(( off course you need to use salt and md5.

 

but md5 on it own would be enough in this case..

 

apart from all that, if anybody is stupid enough to have any personal bank details or credit cards on a online web site with out ssl, and all the best encryption man can throw at them to protect there users, then don't add your details.

 

[MadTechie]

That's not the point of MD5.. holy hell, MD5 has NOTHING to do with the security level of the password.. its to make something non-reversible THAT'S IT.. adding salt is used to render *rainbow tables unusable, adding a filter to force the user to use a complex password has NOTHING to do with MD5 or Blowfish or DES or ANY encryption method,

 

*a Rainbow table is a simply a list of words with their MD5 equivalent

 

Now i thought i make that clear in my previous post

 

I have been though all this before so i am stopping here.. if you don't get it, then theirs nothing i can do!

What is the point of MD5?

[redarrow]

Richard i understand how it all works, i think you can guess that surly.

 

the point is if the user does not add a proper user name and password from the beginning your in.

 

so it best practice for new php programmers to  understand that from the beginning when it comes

to security.

 

you don't just add php function's like md5 , sha1, and others before understand online security concepts.

 

Richard all what you said is correct by the way i love debating friend.

 

[MadTechie]

True, they shouldn't just add it without knowing why.. the i don't understand why you would say the following

 

I find all this salt and crap a wast of time..

Hardly it protects against rainbow table lookups

 

if you get your users to add a proper unique password then it wont matter if you use salt or not.

These are two different areas, unique passwords can still be in a rainbow tables.. they are like brute force, so its worth salting your password.. of course a unique password is always recommend but that to stop guesses

 

the user enter username and password secret number easy as that, no salt what so ever, just use md5 on the password, and secret number, so much easy and secure.

this is a different subject.. this is about a login not MD5, however the password and secret number should have MD5+salt

[5kyy8lu3]

Salting only really helps for when a hacker gets access to your database and pulls passwords.  They plug the password in, and it won't work.  Beyond that, it doesn't offer much increase in security.  Salting and all the hashing in the world won't stop a brute force.  Brute force is even faster now using parallel processing with gpu's (like cuda).

 

Yes, you can rainbow table lookup a few passwords, look for static characters (those being the salt), and then rainbow lookup the dynamic part.  Nothing will ever be 100% hack proof.  The best protection?  Using complex passwords.  Capital letters, numbers, characters, and making the password long (10+ characters).  The amount of time and processing power it takes to brute force "abcdefghij" vs "Zg3m70aF!Q" is almost an exponential difference.

 

That being said, whether it's for a "commercial" site or not, it's NOT a waste of time.  It's not very hard to type a few characters to hash something before throwing it into a database.  Even adding a salt is stupidly easy, so why not do it?  I don't see how you could call that a waste of time.

[lynxus]

Hi All,

 

LOL I was not expecting so many replies.

 

Thanks for your input.

I do realise that its not adding security all i want to do is insure that if my DB is pulled ( unlikey ) that all the hacker will get is useless info and then putting the passwords against a rainbow will be useless.

 

Password wise i think md5ing and salting will do me just fine. ( Not just to give the password some form of unreadability but to make it harder for hackers to reverse later on. )

 

Thnak yall for your very informative posts

 

[waynew]

$salt = "7983ndend93498!uhdh(jskwewytpsdh!278jdkjNS";
$mypassword = "somethingclever";

$encrypted_pass = sha1($salt.$mypassword.$salt);

 

Wallah. Using something like:

 

$encrypted_pass = md5(md5($mypassword));

 

only serves to increase the chance of a collision.

[waynew]

Salting only really helps for when a hacker gets access to your database and pulls passwords.  They plug the password in, and it won't work.  Beyond that, it doesn't offer much increase in security.  Salting and all the hashing in the world won't stop a brute force.  Brute force is even faster now using parallel processing with gpu's (like cuda).

 

Yes, you can rainbow table lookup a few passwords, look for static characters (those being the salt), and then rainbow lookup the dynamic part.  Nothing will ever be 100% hack proof.  The best protection?  Using complex passwords.  Capital letters, numbers, characters, and making the password long (10+ characters).  The amount of time and processing power it takes to brute force "abcdefghij" vs "Zg3m70aF!Q" is almost an exponential difference.

 

That being said, whether it's for a "commercial" site or not, it's NOT a waste of time.  It's not very hard to type a few characters to hash something before throwing it into a database.  Even adding a salt is stupidly easy, so why not do it?  I don't see how you could call that a waste of time.

 

You can stop brute force by using a very good captcha AND by disabling accounts after a defined number of failed login attempts. Brute force can easily be stopped.

[MadTechie]

You can stop brute force by using a very good captcha AND by disabling accounts after a defined number of failed login attempts. Brute force can easily be stopped.

 

Thats not really true, yes you can do that for your own web login but if they have your HASH then they can run it on any system they like! and if they got your hash then your probably have bigger problems.