Username/Password Authentication In mySql
 

Hi

Sorry to be filling these boards up with small problems, but I seem to be running into a lot since I'm learning PHP/mySQL while building a rather large website

Anyway, I'm implementing a username/password thing. I've got a registration form in which it uses the crypt() function to encrypt their password and store it in the database, like so:

[php]$password = crypt($upass);[/php]

However, when I ran into problems validating the password when the user logs in, I tested two users with the same password and found out that the digest (or whatever you call the encrypted password) is different each time

I've read the online documentation of the crypt() function, but I don't understand the idea of a salt. Should I supply a salt to stop the salt being generated randomly?

EDIT: I've supplied a salt as follows:

[php]$password = crypt($upass, "*****salt*****");[/php]

The salt is 15 characters, and the space for the digest in the database is also 15 characters, if that helps

Thanks

Banjo

Read this:

http://br.php.net/crypt

and this:

http://www.devshed.com/c/a/PHP/Using...rypt-Function/

Personally I just use MD5. Some people prefer SHA1 because they think it's more secure. MD5 could probably be broken faster because a few hackers have found a few algorithms that speed up the cracking process, but to my knowledge, no one has yet to break them. You don't need to worry about seeds and the text you encrypt will have the same hash every time. Be warned though that there is no decrypt function on MD5 or SHA1. No seeds or salts. It is one way encryption. Once you've encrypted a password and it's in the database, you cannot retrieve the decrypted form of it.

Apparently SHA-1 (which includes MD5) has already been cracked.

Thanks everyone! Does anyone reccommend changing from MD5 or SHA-1 following the fact that they've been cracked or would it be okay to use it? What would be the alternative?

Also I don't need two-way encryption. I'll just get the user to sign up with a password, encrypt it, then get their password when they log in, encrypt that and compare the two

I'd strongly reccomend using salts when hashing passwords. The salt can be stored right along side the hashed password in the database, or could just as well be based on a unique user ID or some other existing field. Salting mitigates a very real threat. Given that the output of a hash function for a given input must always be the same, that means that if you hash "password" once, any user with that hash can be logged in to with "password." (Well...it could be an insanely lucky collision. But that doesn't really matter; you're just comparing the hashes after all)

Unsalted hashes can make collections of the most common very appealing...

There are in fact exhaustive (but large) mappings of hashes -> passwords available. I don't have any credit on http://www.rainbowcrack.com/ at the moment, but the table list speaks for itself on just how uncrackable you're magic MD5 function is (for short input such as passwords). By salting your hashes, this isn't as much of a problem. You'd have to have a different table for every salt.

The other thing to consider is how valuable the information is that you are seeking to protect with the strongest encryption. Will it fail in the face of a simple SQL injection? Will a determined hacker attempt to crack the password, or will they merely attack other weaknesses? Perhaps breaking into the user's home or office and reading the post-it note on the monitor would be more effective.

Security is multi-faceted. The determined hacker will seek the weakest, most economically effective link. The other 99 jillion people won't even try. That's particularly true if the information you are guarding is essentially worthless.

If it's not highly sensitive information and more along the lines of something personal like a blog, forum, or even just a special little area, md5 (or alternatively sha1) are fine to use. Most forums for example still use md5.

But if you are protecting sensitive data, then not only would you want to use a good hash function, but you would also use SSL to protect your site from packet sniffing.

Yes, I forgot to mention that. It's silly to encrypt stuff in a database that is (hopefully) more or less secure from prying eyes, while the usernames, passwords, and what ever data that they protect are sent in the clear over the internet to be read by anyone along the way. And without SSL, you could just as easily be talking to a bogus server anyway. This is dangerously commonplace, however. For example, this website offers neither SSL for login nor browsing, which could pose a problem on untrusted networks such as a hotel. Sometimes I open up Wireshark just to see what goes by. That's the fun thing about WEP. There's only one key for all clients...

But there's really no excuse. You don't have to spend money to be "certified" by one of the big certificate authorities like Thawte. You can just as easily create a self-signed certificate which is just as secure but not as user friendly (it will keep popping up a warning until the users chooses to always trust that certificate). There are also free CAs available. One example is StartCom. It is included in Firefox's certificate store by default, and I believe Konqueror and Safari too, meaning that those users will not get a warning message that they'd probably ignore and click through anyway (defeating the purpose). Internet Explorer however tends to require hefty...donations to be a "trusted" CA.

Well, since my website isn't going to be storing effective information anyway (just username, password, first name, surname and e-mail) I don't think I'll need SSL or any super-strong encryption. The best hackers probably have more economically effective things to do than find out what someone's been doing on my site