Login methods?

RWB

I am wanting to look into a secured log in interface, but curious what I should do to get it done... how to store usernames and passwords for example. I'll try to figure it out from there, but like do I use SQL to store them or maybe a separate file like XML or something? Then use PHP to retrieve them?

jhenry

The way I store usernames and passwords is similar to the following

Have an SQL database that contains the username, the password hash, and a randomly generated password salt.

The hash is the following:

md5( md5($users_password) . md5($users_salt))

The users password is retrieved from the form, and the salt is grabbed from the database using the username as the primary (unique) key.

This way, the users passwords are stored in an unbreakable form. However, this creates the problem of not being able to retrieve the passwords in case the user forgets. You'd have to create a form to generate a new password and salt, then send the user the new password and update the hash and salt in the db.

Once the data is stored, you can use any SQL compatible language to access it. I prefer PHP, so the above salt example is PHP code. Run it over an SSL connection, and you're good to go!

If you have any questions, ask away!

RWB

Umm... Salt???

Linc

RWB wrote:

Umm... Salt???

A salt is a random string of characters, like Df2^+. It's used to further randomize the result of the hash. (The 'hash' is the outcome of the irreversible algorithm that the password is put through, in most cases the md5 algorithm).

Take vBulletin, for another example.

You type in a new password. vBulletin takes what you typed, and appends the unique and random salt that each user has stored in the database with their user info. Then, it takes the md5 hash of the resulting string. Then, it takes the md5 hash of THAT. This is what gets stored in the database and your cookie. Anytime you type in your password, it does this process over again and compares the results.

Appending the salt means that someone couldn't reproduce your hash (putting the same word through the md5 algorithm will always give the same hash, of course, otherwise it wouldn't work) even if they knew your password. Honestly... I don't know what use that would be anyway, but there you have it.

RWB

Oh man, I don't know where to begin haha

Nosferatu

So the plaintext salt string for each user is stored in the database? Then that plaintext salt string is used in the validation process when a user is logging in? For example, you would evaluate:

md5(md5($entered_pw) . md5($stored_salt)) == $pw_hash_from_db

during user authentication?

jhenry

Yeah, the salt would be plain-text and would be stored with the hash. The idea is to prevent users from brute-forcing your members' passwords, even if they get a copy of your database. Most people use the same password and email combination for everything, so if someone got your email address and brute-forced your password, they might have the presence of mind to see if you have a paypal or newegg account or something similar...

Hopefully, you'll not have to worry about someone getting your database. However, the extra layer of protection is a good idea.

lightnin

using salt is an excellent idea.

i had a former employer that SOLD an application to another company that had the weakest auth i've ever seen ever... ever...

username admin
password ' or 1=1

would get anyone in as the admin.

for the love of all things holy, please use SOMETHING to clean up user input as well or you could be asking for trouble on so many levels.

Nosferatu

Ok, thanks! It makes sense now.