> -----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
