Need Help With 2-Way Password Encryption How to properly store passwords in a database

Every article I've read on the internet so far suggests using MD5 or SHA1 to "encrypt" passwords in a database, but MD5 and SHA1 are hashing functions; they only go one way. So then how do I let users know what their password is if they forget it? I suppose I need a two-way encryption method, right?Can somebody please tell me what the easiest way to solve my problem is with PHP and MySQL?Thanks,Trevor

Every article I've read on the internet so far suggests using MD5 or SHA1 to "encrypt" passwords in a database, but MD5 and SHA1 are hashing functions; they only go one way. So then how do I let users know what their password is if they forget it? I suppose I need a two-way encryption method, right?
Can somebody please tell me what the easiest way to solve my problem is with PHP and MySQL?

Thanks,
Trevor

Yes it is true that MD5 and SHA1 are hashing functions. They don't actually offer encryption but instead mask the true nature of the users password in the database so it can't be copied. So when the password is created, it is hashed prior to bein placed in the database. When a password is entered for log in, it is hashed and then the hash is compared to the hash in the DB.

There is no way to retrieve a lost password that has be saved in hashed form.

There are encryption and decryption functions availible but don't offer the same level of protection as a hashed password.

Most websites offer a password reset instead of password retrieval. A new , random password is created and sent to the user's email account on file. Then the user can change their password after they log in.

SO, let us know which method you would prefer to use and we'll try to come up with a solution.

vujsa

Most websites offer a password reset instead of password retrieval. A new , random password is created and sent to the user's email account on file. Then the user can change their password after they log in.

Ah ha, that would work great. That sounds like a good solution. Thanks for clarifying!

Ah ha, that would work great. That sounds like a good solution. Thanks for clarifying!

 

Well, we need a little information from you:

How much PHP / MySQL experience do you have?

Do you want to use server sessions or will you be using a database session system?

Will every page in your website use the authentication system?

Some websites have a special section or directory which is members only.

Many websites allow members to log in as soon as they get to the site and guests and non-logged in members to acces most of the site but there may be restriction until they log in.

Have you considered a prewritten member authentication system?

Would you consider using a Content Management System which is basically a website in a box that just need content added?

Personally, I haven't written a member authentication system of my own due to the size of such a project. I know what must be done a generally have the required programming skills to accomplish such a project but lack the time and energy to sit down and do it. I tell you this to give you an idea of how much work is in front of you if you do it right.

 

Here are the basic parts of the total system:

User registration, authentication, and password reset

User types and privledges

Session handling and logging out

Content access levels and restrictions

The first part basically adds a user to the database, allows for the comparison of the user entered log in data with the data in the database, and create and send a new password to the user's email account if the password is lost.

 

The second part provides for various user levels but really only three are needed; guest, member, and Admin. For privledges, you can either set them by user type or even individual memebr or restrict access by type on each page.

 

The third part is the most important part of the system. It prevents the user from having to log into each page individually. This can either be done using a server session or with a database session. Based on you session data, the website knows if you are logged in and what access privledges you should have. Finally, you need to end the session either after a spedified amount of time or upon user log out.

 

The forth part is pretty easy to set up but kind of hard to administer. On each page you can specify what kind of page it is or which user level may access it. Basically if you want to set privledges for each user individually, then you need to identify the page by page type but if you want to restrict acces based solely on user types, then you need only tell the page which user types are allowed. This is true for every item on your website including links, menus, content, areas, and log in forms. No reason to show a memebrs only page link to a guest and no reason to show the log in for to logged in members.

 

Let me know where you need clarification.

 

vujsa

To answer your questions:

1. I've done server side scripting for three or four years and PHP/MySQL specifically for approximately two.

2. I've put together the site using server sessions, though the part of the site that requires authentication consists on only four or five scripts. Each page that I want to be restricted to unauthorized users includes another page which resembles the following:

<?phpsession_start();require_once("Smarty.class.php");if(isset($_POST["username"])) {	$username = $_POST['username'];	$password = $_POST['password'];	$password = sha1("[salt]" . $password . "[salt]");		$users = &DB_DataObject::factory('[userstable]');	$users->whereAdd();	$users->whereAdd("username = '$username'");	$users->whereAdd("password = '$password'");		if($users->find(true) > 0) {		$_SESSION['id'] = $users->id;		$id = $users->id;	}}if(!isset($_SESSION['id'])) {	$loginpage = new Smarty;	$loginpage->display("login.tpl");	exit;} else {	$id = $_SESSION['id'];}?>

This chunk of code handles the login process and checks to see if they already logged in.

3. It's described above, but to reiterate, only four or five pages need authentication. They include the chunk of code above.

4. I looked at a few authentication systems and most are just way overkill for what I'm doing. The only one that looked like it might suit my project was the PEAR authentication package, but the solution I have works pretty much the same way (that is, I implement it the same way in the pages that need to be secured).

5. PHP Nuke ain't gonna cut it It's a specialized kind of website and I'm already finished coding the bulk of it.

I tell you this to give you an idea of how much work is in front of you if you do it right.

I greatly appreciate your willingness to guide me. It seems to me I've got it working, my only concern is that I might be overlooking something fairly major that would compromise the security of the site. This security system has to eventually reliably keep secure a service that people will by paying for.

Let me know if you think I need to fix something,
Trevor

Not really pointing out to some security hack in the code snippet you have provided Trevor. But if anybody could take little time to explain this line it will be of great help for me.

$users = &DB_DataObject::factory('[userstable]');

I have little bit familiarity with PHP-MySQL scripts, and I'm trying to switch over to objects. This may explain the need of this post.

But if anybody could take little time to explain this line it will be of great help for me.

That's PEAR code. Basically, DB_DataObject is an API for a database connection. The line you qouted instantiates the class and creates object called $users. Then the whareAdd() methods are called to add conditions to the query. Essentially whereAdd() adds a WHERE clause to the query that is getting performed. You just don't see the SQL code there as its wrapped inside the DB_DataObject class. If you are interested in more detail or this wasn't clear check the PEAR manual at http://pear.php.net/



Regarding the actual topic: encryption the passwords, so that they can be recovered, itself is not a problem and doesn't pose a security risk. Just use strong enough algorithm and the passwords are safe. Well except if someone gets the key... And here's the problem: the storage of the keys. I guess big services (like MSN hotmail) use asymmetric encryption and keep the secret key somewhere else. Just use the public key to encrypt the user inputted password and compare it to the one in the database, essentially the same operation as with hashes. For the relatively rare case of lost password recovery the encrypted password could be sent to the safe place where it can be decrypted with the secret key.

As a side note to these password issues... Isn't it funny how people go to great lengths in securing the password in the dabase with multiple hashes or very strong encryption methods and then when we need the old password back or a completely new password it gets sent in unencrypted email...

Depends whether you have a lot of lost paswords to manage or not.What I do for my Unix users is :I manually put a password for the user, for instance "hey_noob".I mail that password to the user, the user is then able to connect and choose a new password.It's simple, efficient, secure if you trust mail, and rather usable if you have few users. Moreover, i would say that it's the most secure way, because you personally know who forgot his password, how often this occurs, if you need to remove this account because probably frequently hacked, etc...

im my last script i did a 3-type-encryption methodi used MD5 and than i used SHA1 in th MD5ed pass, and then i used MD5 agine on the SHA1ed MD5ed passwordso i got a maximal protection :)now i am working on my own way (like MD5)NoMore