MD5, MySQL, and salts

------=_NextPart_000_0006_01C66234.589DDD00
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Guys,
I'm working on securing user passwords in a MySQL 4 database with a PHP5
frontend. I remember being told in one of my classes (I'm currently a
college junior) that the best way would be to hash a salt and the password
together and then store the hash in the database instead of the plain MD5
hash. My question is, what is a good method for the server and the database
to agree on a salt value to use? I know i could use a predefined variable,
but I was wondering if something dynamic might be better (timestamp, current
date, something like that). Any ideas? Thanks in advance!
-Sean

------=_NextPart_000_0006_01C66234.589DDD00--

Re: MD5, MySQL, and salts

On 4/18/06, Sean Mumford wrote:
> Hi Guys,
> I'm working on securing user passwords in a MySQL 4 database with a PHP5
> frontend. I remember being told in one of my classes (I'm currently a
> college junior) that the best way would be to hash a salt and the passwor=
d
> together and then store the hash in the database instead of the plain MD5
> hash. My question is, what is a good method for the server and the databa=
se
> to agree on a salt value to use? I know i could use a predefined variable=
,
> but I was wondering if something dynamic might be better (timestamp, curr=
ent
> date, something like that). Any ideas? Thanks in advance!

If it's a dynamic salt, how are you going to access it when you have
to compare ?

There was an article either on phpsec.org or shiflett.org which talks
about this.. can't find the link right now :(

--
Postgresql & php tutorials
http://www.designmagick.com/

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: MD5, MySQL, and salts

For an example, look at how UNIX/Linux stores regular login passwords. In
short, the salt is the first two characters in the password. When comparing
passwords, you take the salt and the user supplied password, encrypt, then
compare the two encrypted strings. If they match, the recently supplied
password matches the original. AFAIK, that is the only way to verify
passwords encrypted with a one-way algorithm.

Giff

-----Original Message-----
From: chris smith [mailto:dmagick@gmail.com]
Sent: Monday, April 17, 2006 4:36 PM
To: Sean Mumford
Cc: php-db@lists.php.net
Subject: Re: [PHP-DB] MD5, MySQL, and salts

On 4/18/06, Sean Mumford wrote:
> Hi Guys,
> I'm working on securing user passwords in a MySQL 4 database with a
> PHP5 frontend. I remember being told in one of my classes (I'm
> currently a college junior) that the best way would be to hash a salt
> and the password together and then store the hash in the database
> instead of the plain MD5 hash. My question is, what is a good method
> for the server and the database to agree on a salt value to use? I
> know i could use a predefined variable, but I was wondering if
> something dynamic might be better (timestamp, current date, something like
that). Any ideas? Thanks in advance!

If it's a dynamic salt, how are you going to access it when you have to
compare ?

There was an article either on phpsec.org or shiflett.org which talks about
this.. can't find the link right now :(

--
Postgresql & php tutorials
http://www.designmagick.com/

--
PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit:
http://www.php.net/unsub.php

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: MD5, MySQL, and salts

This begs the question of what would this method buy you over MD5?
Some people have "issue" with like passwords looking the same with MD5
encryption, also a one way hash.
But if you know the salt, then like passwords would also look the same,
right?
-B

Giff Hammar wrote:

>For an example, look at how UNIX/Linux stores regular login passwords. In
>short, the salt is the first two characters in the password. When comparing
>passwords, you take the salt and the user supplied password, encrypt, then
>compare the two encrypted strings. If they match, the recently supplied
>password matches the original. AFAIK, that is the only way to verify
>passwords encrypted with a one-way algorithm.
>
>Giff
>
>-----Original Message-----
>From: chris smith [mailto:dmagick@gmail.com]
>Sent: Monday, April 17, 2006 4:36 PM
>To: Sean Mumford
>Cc: php-db@lists.php.net
>Subject: Re: [PHP-DB] MD5, MySQL, and salts
>
>On 4/18/06, Sean Mumford wrote:
>
>
>>Hi Guys,
>>I'm working on securing user passwords in a MySQL 4 database with a
>>PHP5 frontend. I remember being told in one of my classes (I'm
>>currently a college junior) that the best way would be to hash a salt
>>and the password together and then store the hash in the database
>>instead of the plain MD5 hash. My question is, what is a good method
>>for the server and the database to agree on a salt value to use? I
>>know i could use a predefined variable, but I was wondering if
>>something dynamic might be better (timestamp, current date, something like
>>
>>
>that). Any ideas? Thanks in advance!
>
>If it's a dynamic salt, how are you going to access it when you have to
>compare ?
>
>There was an article either on phpsec.org or shiflett.org which talks about
>this.. can't find the link right now :(
>
>--
>
>Postgresql & php tutorials
>http://www.designmagick.com/
>
>--
>
>
>

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: MD5, MySQL, and salts

True in some form, it always comes down again to the strength and
integrity of the original password.

Yes, even if a salt is unknown and it is a plain text, dictionary
password, then it doesn't take much for a brute force attempt at just
using the first two characters of each word and salting it with the word
to create the hash and seeing if it matches.

But just knowing the two character salt doesn't overly help in
decrypting the hash. Using a custom hash particularly using part of the
key itself as the hash increases the integrity and uniqueness of the
hash by an exponential factor. You have two values now that are
affecting the hash output value.



Something to chew on...

-J B

> This begs the question of what would this method buy you over MD5?
> Some people have "issue" with like passwords looking the same with MD5
> encryption, also a one way hash.
> But if you know the salt, then like passwords would also look the
> same, right?
> -B
>
> Giff Hammar wrote:
>
>>For an example, look at how UNIX/Linux stores regular login passwords.
>>In
>>short, the salt is the first two characters in the password. When
>>comparing
>>passwords, you take the salt and the user supplied password, encrypt,
>>then
>>compare the two encrypted strings. If they match, the recently
>>supplied
>>password matches the original. AFAIK, that is the only way to verify
>>passwords encrypted with a one-way algorithm.
>>
>>Giff
>>
>>-----Original Message-----
>>From: chris smith [mailto:dmagick@gmail.com] Sent: Monday, April 17,
>>2006 4:36 PM
>>To: Sean Mumford
>>Cc: php-db@lists.php.net
>>Subject: Re: [PHP-DB] MD5, MySQL, and salts
>>
>>On 4/18/06, Sean Mumford wrote:
>>
>>>Hi Guys,
>>>I'm working on securing user passwords in a MySQL 4 database with a
>>>PHP5 frontend. I remember being told in one of my classes (I'm
>>>currently a college junior) that the best way would be to hash a salt
>>>and the password together and then store the hash in the database
>>>instead of the plain MD5 hash. My question is, what is a good method
>>>for the server and the database to agree on a salt value to use? I
>>>know i could use a predefined variable, but I was wondering if
>>>something dynamic might be better (timestamp, current date, something
>>>like
>>>
>>that). Any ideas? Thanks in advance!
>>
>>If it's a dynamic salt, how are you going to access it when you have
>>to
>>compare ?
>>
>>There was an article either on phpsec.org or shiflett.org which talks
>>about
>>this.. can't find the link right now :(
>>
>>--
>>
>>Postgresql & php tutorials
>>http://www.designmagick.com/
>>
>>--
>>
>>
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.1.384 / Virus Database: 268.4.2/314 - Release Date:
> 16/04/2006
>
>



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.1.384 / Virus Database: 268.4.2/314 - Release Date: 16/04/2006

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: MD5, MySQL, and salts

you need the key to be easily available, so row id or a set date field(one
that does not change as opposed to a timestamp type field)

bastien

>From: "Sean Mumford"
>To:
>Subject: [PHP-DB] MD5, MySQL, and salts
>Date: Mon, 17 Apr 2006 15:33:58 -0400
>
>Hi Guys,
>I'm working on securing user passwords in a MySQL 4 database with a PHP5
>frontend. I remember being told in one of my classes (I'm currently a
>college junior) that the best way would be to hash a salt and the password
>together and then store the hash in the database instead of the plain MD5
>hash. My question is, what is a good method for the server and the database
>to agree on a salt value to use? I know i could use a predefined variable,
>but I was wondering if something dynamic might be better (timestamp,
>current
>date, something like that). Any ideas? Thanks in advance!
>-Sean

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: MD5, MySQL, and salts

On 4/18/06, Giff Hammar wrote:
> For an example, look at how UNIX/Linux stores regular login passwords. In
> short, the salt is the first two characters in the password. When compari=
ng
> passwords, you take the salt and the user supplied password, encrypt, the=
n
> compare the two encrypted strings. If they match, the recently supplied
> password matches the original. AFAIK, that is the only way to verify
> passwords encrypted with a one-way algorithm.

I badly worded my response, but yes you're right.

Anyway I found the article I was thinking of:

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

(which ironically suggests the opposite of what I said - use a random salt =
:P).

--
Postgresql & php tutorials
http://www.designmagick.com/

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php