Encrypting password sha1(md5(md5(sha1(md5(sha1(sha1(md5($pass))))))))

[ibinod]

it has been a quite long that i have been encrypting password this way

 

sha1(md5(md5(sha1(md5(sha1(sha1(md5($pass))))))))

 

it's because it's real easy to decrypt md5 and sha1 simple hashes

 

infact i am inserting passwords on my database like this

 

mysql_real_escape_string(sha1(md5(md5(sha1(md5(sha1(sha1(md5($pass))))))))),

 

what do you guys think about this is it a better solution than md5($pass) || sha1($pass)

 

or i am completely idiot doing that

 

 

or are there better secure way for password encryption

 

pls give me some suggestion

 

 

thanks a lot

[taith]

i agree 100%... theres MANY sites out there that recordes simple md5/shai1 and their receptive encrypt...

 

personally... i'd do it more like this... but thats just to further complicate life of a decrypter :-)

 

md5(sha1(md5(sha1(sha1($pass)))).md5($pass).sha1(sha1($pass)));

 

or whatnot...

 

so their not simply having to backtrack... they also have to guess where to cut between the encrypts...

 

call me paranoid if you'd like...

[Mark Baker]

i agree 100%... theres MANY sites out there that recordes simple md5/shai1 and their receptive encrypt...

You can make it even harder by introducing a level of bitwise logic:

$encryptedPassword = md5(md5(sha1($plainTextPassword))) ^ md5(sha1(md5($plainTextPassword)));

 

 

[limitphp]

When a user registers on my site, and I send the info to be INSERTED into the database.  Should I encrypt it in the INSERT statement?

 

ex:

mysql_query("INSERT INTO user (username, password, fname, lname, email, date)	VALUES ('$username', 'md5(sha1(sha1($password)))', '$fname', '$lname', '$email', DATE_ADD(NOW()))");

 

I figured it'd be easier to just ask in this thread instead of starting a new one.

 

 

[Mchl]

mysql_real_escape_string(sha1(md5(md5(sha1(md5(sha1(sha1(md5($pass))))))))),

 

What is that supposed to be? What are you expecting to escape? sha1() returns only hexadecimal characters.

And multiple hashing gives you no better protection (some argue it's worse actually). Just use more secure hashing algorithm ( hash - choose one) and salt your passwords (and salt them good).

 

http://phpsec.org/articles/2005/password-hashing.html

[limitphp]

mysql_real_escape_string(sha1(md5(md5(sha1(md5(sha1(sha1(md5($pass))))))))),

 

What is that supposed to be? What are you expecting to escape? sha1() returns only hexadecimal characters.

And multiple hashing gives you no better protection (some argue it's worse actually). Just use more secure hashing algorithm ( hash - choose one) and salt your passwords (and salt them good).

 

http://phpsec.org/articles/2005/password-hashing.html

 

So, when a user registers on my site, and I send the info to be INSERTED into the database.  I should encrypt it and salt it in the INSERT statement?

So, inside the table users, passwords will be stored encypted and salted....

 

 

[limitphp]

I see one thing, after reading that article you linked to, Mchl.  If a hacker can get access to your database, is it likely that they can probably get access to your php files too?  Thus seeing your method of how you hash and what your salt is equal to?

[Mchl]

Not necessarily.

He could use mysql injection, to get contents of database, but still now nothing about salting algorithm.

I had my PHPnuke hacked once (well, three times actually, but I'm talking about one particular time ), where hacker just posted all stored passwords (hashed) as a news item on front page (and as it was aggregated into RSS channel, we've had a lot of embarrassment)

 

One more thing: If they have access to your php files, they know your database credentials. Game over

[limitphp]

Not necessarily.

He could use mysql injection, to get contents of database, but still now nothing about salting algorithm.

I had my PHPnuke hacked once (well, three times actually, but I'm talking about one particular time ), where hacker just posted all stored passwords (hashed) as a news item on front page (and as it was aggregated into RSS channel, we've had a lot of embarrassment)

 

One more thing: If they have access to your php files, they know your database credentials. Game over

 

I see.  Thanks for the info.

So, how do you hash?

say I have $password and $salt

How do you hash it?

[Mchl]

$hash = hash("sha512",$password.$salt);

 

sha512 is actually pretty strong, and a bit of a overkill. It's 64bytes long. Finding a collision for it would take some time.

[limitphp]

$hash = hash("sha512",$password.$salt);

 

sha512 is actually pretty strong, and a bit of a overkill. It's 64bytes long. Finding a collision for it would take some time.

 

Ok, so if I use this, what type should my password field be and how long should I make it?

ex) varchar (50)

[Mchl]

char(128)

(I told you it's a bit of an overkill )

[limitphp]

also, how long should the salt be?

is something like k2jhaq895kjh6z0 good?  about 15 characters long?

 

128....dang.....is that going to slow things down as you get into the 10,000 user range.....

 

why char and not varchar?

 

[Mchl]

Why not use some less common chars in your salt? %$:"<šđČ

If you're not comfortable with 128 bytes for password hash, you can use some other version of sha algorithm (there are three more to choose from). sha512 is just the strongest (of sha family) available through hash function.

[limitphp]

Why not use some less common chars in your salt? %$:"<šđČ

If you're not comfortable with 128 bytes for password hash, you can use some other version of sha algorithm (there are three more to choose from). sha512 is just the strongest (of sha family) available through hash function.

 

Nice....good idea.  Thanks for the info. 

[redarrow]

What ive been told and been using and was recommended from the zend group...

 

And yes it true you can add all diffrent methods for password protection.....

 

Dont forget it not just the code that we need to protect passwords,

we also need the user to understand to use proper password names ....

 

MOST WEBSITES AND PROGRAMMERS SEND THE USER THERE PASSWORD FOR

SECUITY REASONS..

 

 

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

if you have told your users to use very fine passwords in a order that makes only sence

to them

the md5 is a grate powerfull function.....

 

<?php

// post password
$password=$_POST['password'];

//This is a common password name well unprotected...

//passwords should be charecter djddj number 34443 charecter even mixed better.... 

$password="god";

echo " this is the password uncrypted $password it unsecure <br><br>";

// let secure the password with md5.

$password=md5($password);

echo"<br><br> this password $password is secure one way not able to be uncripted <br><br>";

// now the password is in a md5 format and encrypted you think it's secure wrong,
// becouse the name off the password was a normall everyday name like god it not,
//secure, there are hundreds off databases that collect encripted passwords, with the format off 
//md5, and others.


//let realy secure password.

$password=md5(sha1(md5($password)));

echo" This is my password $password very secure";

// there issent no database that supports yet the un encryption to uncript 
// md5 and sh1 then md5 out there, Even if it exists it be very hard to get the 
// encrypted password correctly formatted....

?>

[limitphp]

What ive been told and been using and was recommended from the zend group...

 

And yes it true you can add all diffrent methods for password protection.....

 

Dont forget it not just the code that we need to protect passwords,

we also need the user to understand to use proper password names ....

 

MOST WEBSITES AND PROGRAMMERS SEND THE USER THERE PASSWORD FOR

SECUITY REASONS..

 

 

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

if you have told your users to use very fine passwords in a order that makes only sence

to them

the md5 is a grate powerfull function.....

 

<?php

// post password
$password=$_POST['password'];

//This is a common password name well unprotected...

//passwords should be charecter djddj number 34443 charecter even mixed better.... 

$password="god";

echo " this is the password uncrypted $password it unsecure <br><br>";

// let secure the password with md5.

$password=md5($password);

echo"<br><br> this password $password is secure one way not able to be uncripted <br><br>";

// now the password is in a md5 format and encrypted you think it's secure wrong,
// becouse the name off the password was a normall everyday name like god it not,
//secure, there are hundreds off databases that collect encripted passwords, with the format off 
//md5, and others.


//let realy secure password.

$password=md5(sha1(md5($password)));

echo" This is my password $password very secure";

// there issent no database that supports yet the un encryption to uncript 
// md5 and sh1 then md5 out there, Even if it exists it be very hard to get the 
// encrypted password correctly formatted....

?>

 

Good point, I didn't even think about that.  Request your password if you forget it.  So, should you ever store a hashed passowrd in your database?

So, Mchl, if you store hashed passwords in your USER table, you won't be able to send a password to a user if they forgot it.

Also, why char and not varchar?

 

[limitphp]

I guess if they forget their password, just let them click a link and change their password.  There's no reason why they even need to know it again if they forget it.

[redarrow]

CORRECT

 

if a user wants to recover a password you then have to create one for them,

and send it via email or text....

 

you update the database via there id or email address.....

 

then when the users logs in then they can change there password to a unique password name.........

[Mark Baker]

Good point, I didn't even think about that.  Request your password if you forget it.  So, should you ever store a hashed passowrd in your database?

So, Mchl, if you store hashed passwords in your USER table, you won't be able to send a password to a user if they forgot it.

Correct, a hashed password has to be reset (issuing a new password) if the user forgets it

[Mark Baker]

I guess if they forget their password, just let them click a link and change their password.  There's no reason why they even need to know it again if they forget it.

There's not really much point in setting passwords if the users can simply click a link and change it without doing something to prove who they are....

But I seem to recall an early version of Windows Lite called "Joe" which used exactly that principle. If the user got their password wrong three times in succession, it assumed they'd forgotten it and allowed them to simply reset it

[genericnumber1]

Doing a million function calls is overkill... just use a salted MD5 hash. Yeah, collisions happen, but they happen in virtually every hash. The chances of an md5 hash you salted matching a short-length collision are astronomically low. Don't be so paranoid

[limitphp]

I guess if they forget their password, just let them click a link and change their password.  There's no reason why they even need to know it again if they forget it.

There's not really much point in setting passwords if the users can simply click a link and change it without doing something to prove who they are....

But I seem to recall an early version of Windows Lite called "Joe" which used exactly that principle. If the user got their password wrong three times in succession, it assumed they'd forgotten it and allowed them to simply reset it

 

I mean, send a link to their email address.  So, only the user with that email address would know the link.  And then from there, let them create a new password.

 

I'm not sure how to do that yet.  I assume you could create a page that takes in a querystring.  And the value of that querystring could be a long uniqueID?

 

 

 

 

[limitphp]

Doing a million function calls is overkill... just use a salted MD5 hash. Yeah, collisions happen, but they happen in virtually every hash. The chances of an md5 hash you salted matching a short-length collision are astronomically low. Don't be so paranoid

 

I'm really new to this, but what is a short-length collision?

 

What about using sha256? 

[genericnumber1]

collisions are just where two strings have the same hash value.. what I meant is if you have a string encrypted

 

omgsupersecretlongstringiamgoingtoencrypt

 

and it has the same md5 hash as

 

hai

 

it's a security vulnerability.. but the probability of that is virtually zero. I've always used salted md5 hashes, and I'll use them until someone's rainbow tabled them all or I find something I like better.

 

sha256 makes an sha hash twice as long as an md5 hash (which is 128 bits I believe). Theoretically (and logically) it means less collisions.

 

Whether you use sha or md5 really isn't a HUGE decider in your security.. pick a good salt and just don't worry about it until you need to