> -----Original Message-----
> From: Eric Butera [mailto:[EMAIL PROTECTED]
> Sent: Sunday, January 20, 2008 12:24 AM
> To: Jochem Maas
> Cc: Nathan Nobbe; PHP General List
> Subject: Re: [PHP] password hashing and crypt()
> 
> On Jan 19, 2008 8:02 PM, Jochem Maas <[EMAIL PROTECTED]> wrote:
> > Nathan Nobbe schreef:
> > > hi all,
> > >
> > > recently ive been debating a bit about the use of the crypt()
> function and
> > > the best practice thereof, im hoping you can help to clarify this
> for me.
> > >
> > > so, the crypt function
> > > http://www.php.net/manual/en/function.crypt.php
> > > has a second parameter, $salt, which, if not supplied will be
> automatically
> > > generated and presumably become a prefix or suffix of the returned
> string.
> > >
> > > now, the article on the phpsec website
> > > http://phpsec.org/articles/2005/password-hashing.html
> > > recommends to externally create a salt and to store that in a
> separate field
> > > in the database, which would then be used for subsequent password
> > > verification.
> > >
> > > theoretically, however, if the password is generated without a user
> supplied
> > > salt,
> > > there is a salt already embedded in the password anyway.
> > >
> > > so, i have the following questions
> > >
> > >    1. is the phpsec technique bloated or unnecessary
> >
> > I can't see a dictionary attack being thwarted by the salt given that
> the salt
> > is made available when a password is checked. I'm struggling to see
> how a salt
> > will help if it's made available. but it's late, may be better brain
> can enlighten us :-)
> >
> > then again your question is a little skewed due to the fact that
> sha1() is
> > used in the phpsec article and your talking about crypt - which
> encryption is
> > better as it stands is the first question to ask no? AFAIK sha1() is
> > recommended over DES but maybe I'm misinformed.
> >
> > >    2. is it better to create a user supplied salt, and why or why
> not
> > >    3. is crypt() 'intended' to be used w/o a user provided salt,
> since it
> > >    is a stable algorithm
> >
> > depends on the use - i.e. using it inconjunction with a .htpasswd
> file
> > will required no salt (auto-generated salt), other usage recommends
> using
> > an explicit salt.
> >
> > all this salt is hurting my eyes - I have a blind spot.
> >
> >
> > >
> > > any other direction or hints you can supply are much appreciated.
> > >
> > > thanks,
> > >
> > > -nathan
> > >
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> 
> They say sha1 has been compromised.
> http://en.wikipedia.org/wiki/SHA_hash_functions
> 
> I always make sure that I use a site specific salt which is just
> appended on the user supplied value.  I started doing that when I read
> that people had created huge databases of hashed values that they can
> just search on.  At least this way no matter what the password isn't a
> dictionary word.  As for if that really adds value in the end I can't
> say as I'm not really a security expert.
> 
> Eg. hash('sha256', $input.$salt);
> 
> --

Let me share what I've read in a cryptography book some time ago. I hope to
remember it well, but for me it served as an explanation about what the
"SALT" is all about (for those of you who don't have a clue, like me). I
will put aside any cryptographic considerations like the strength of the
algorithms or steganography analysis. 

Let's build a scenario (yeah, I was kind of a teacher in the past, lol). For
the sake of simplicity, let's assume the following:

1 - You have a database (actually, a table) of 10 rows with user encrypted
passwords, and somebody (the cracker) had made it to sniff in and get access
to it. Let's assume passwords are encrypted using MD5 and the cracker knows
it.
2 - No other data has been compromised, or no other compromised data means
anything to the cracker. He only wants to reverse engineer your passwords,
meaning by that "to get valid passwords that match the encrypted (hashed is
the word) ones". Let's say that having those passwords, the cracker can
login to your system and do some interesting stuff, which is the only
ultimate goal of his.
3 - The cracker has a dictionary of 100 words to try, he hopes to find a
match within that dataset. Whether he finds one or more passwords using the
dictionary is not relevant to this scenario, but the metric here is how much
computational effort he has to make to reverse engineer the encryption.

Now, what would the cracker have to do to get one or more valid passwords?
Probably something like:

1 - Apply the MD5 function to the words in the dictionary. He gets a "hashed
dictionary" which probably he has already built long a go (for doing some
other "obscure task").
2 - Compare each of the values in the hashed dictionary to the passwords
table to find matches.

Step 2 can be optimized in several ways, but I'll not get deeper into it (I
won't either give you O[X] values, as I don't have a clue, but some figures
can be made). Also, there's the chance that two users chose the same
password, and the hashes would be equal (in this case you would have only 9
passwords to match).

Now, let's change the scenario and let's say that instead of a table of 10
encrypted passwords you have a table of 10 encrypted passwords and 10 random
SALT values that were used to generate them. According to that, you have the
following equivalence:

$encryptedPassword = md5($password.$salt); // Or similar

This complicates things for the cracker, because:

1 - He must know how the salt was used to generate the password (was it
concatenated before the password, after the password or both)?
2 - He has to generate 10 dictionary hashes (one for each salt value,
assuming each salt value is different). So now the hashed dictionary has
actually 1000 entries instead of 100. And he MUST recreate the hashed
dictionary for each attack he wants to perpetrate to one of these tables
(assumed he has sniffed in more than one place).
3 - Even if he finds two hashes are equal in the passwords table, he won't
guess two passwords in one shot, because the SALT values for each password
would be different.

I remember I first came across to the SALT thing while doing an SMF
integration (don't remember the SMF version, but I remember I had to do
things manually that time, now SMF has an API of some sort I think).

Ok, that's all folks. Now, I'll have a glass of water (or better yet, wine).

Regards,

Rob


Andrés Robinet | Lead Developer | BESTPLACE CORPORATION
5100 Bayview Drive 206, Royal Lauderdale Landings, Fort Lauderdale, FL 33308
| TEL 954-607-4207 | FAX 954-337-2695
Email: [EMAIL PROTECTED]  | MSN Chat: [EMAIL PROTECTED]  |  SKYPE:
bestplace |  Web: http://www.bestplace.biz | Web: http://www.seo-diy.com

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

Reply via email to