PHP Developers Network

Nice to know about the password hashing.. I've always used md5 and never knew it might be compromised


Thanks for the great topic, califdon!

Thanks, but your thanks should go to the authors of the tutorial, Celauran and social-experiment. I only encouraged them to consolidate some of their earlier ideas and I published it here as a "sticky" post. Glad it has been helpful to a lot of the users here.

We should probably look at updating this in light of the addition of password_hash() in PHP 5.5.0

It might be nice to include use of:

*PDO and prepared statements
*ReCaptcha for registration
*Login throttle using ReCaptcha see stackexchange answer: http://stackoverflow.com/questions/2090 ... pts-in-php

I'm not a fan of reCAPTCHA in general, and registration forms in particular I like to keep simple. Email, password, done.

Right. Thanks for keeping the credit for them. Yep, It's been helpful.

Thanks Celauran. That's a great idea.

You have been so helpful not only in this thread, but in the entire forum.

Best,

Great tutorial. It really helped me out.

What I'm now facing is the following. What is a user forgets his password? I can't, for good reasons, see his password. The only thing I can do is delete his account, and let him register under the same name, email, etc.
How about a secure "forgot password"-page? How do I do this? Or even reset the users password to a standard one, like "welcome"?

Thnx

Glad you found the tutorial helpful.
If it's worth protecting a site at all, it's not a good idea to have any "standard" password. You shouldn't need to delete an entire account, just adopt a password reset process. I think the customary approach is to provide a "Forgot Your Password?" button that does something like:

1. Updates the user account to an encrypted temporary random password, then
2. Sends an email to the user at the email address supplied at the time of registration, containing the unencrypted temporary random password and a link to your secure password update page.

The secure password update page (or you could require the user to login first with the temporary random password) requires the user to input the current password (in this case, the temporary random password) and the desired new password, TWICE, for confirmation. After checking that the current password is correct and that the 2 new password entries are identical, update the user account.

If your site requires stronger protection, there are more sophisticated strategies, such as 2-step verification, where a one-time random number is sent to the mobile phone number provided by the user when they registered, then they are directed to a special verification page that requires that one-time random number to be input by the user. For something like a social site, though, that may not be necessary.

Thnx Califdon.

Most of the registration/login procedure on my website is a copy/paste of the tutorial. So adding an "forgot password" feauture is gonna be a bit of a challenge. I'll try, and see what I can come up with.

Really useful and easy-to-learn tutorial. I followed all of your tips here and applied them in my current project. I have a question though on Forgotten Passwords.
My project is OFFLINE - units are connected only thru LAN - so I cannot use the Send to Email approach.
One solution I can think of is allow the Administrator to see user details such as names, usernames, and passwords.
Another is to send notifications to the client unit thru LAN. But I'm still a novice to PHP,Javascript and others so I don't know how to do it.

So how do I decrypt or un-hash the passwords so I can echo it in a textfield?
Any advice or suggestions will be much appreciated..
Thanks in advance!!!

I'm glad that you were able to use the information in the tutorial and apply it to your project.

So my first comment is that, in your local network deployment, you are less vulnerable to outside hackers, including botnets and other mass attacks. Still, I understand that you want a system that is secure. One principle is that you never decrypt or unhash passwords! When validating a user, you ALWAYS hash or encrypt whatever the user has entered, then compare that with the stored (hashed) value--it either matches or it doesn't. Even the system administrator has no ability to decode a stored password and see what the plaintext version is. That's why, when a password is forgotten, you cannot inform a user what their password is, you must ALWAYS replace it with a NEW password, either a random one which you generate and send the plaintext to the user in an email (perhaps impractical in your case) or you require the user to generate their own NEW password. If it were me, I think I would apply the same rules to a closed LAN system, but I suppose in some circumstances it might be reasonable to design a semi-secure system where passwords were encoded by an algorithm that is reversible, just to make it difficult for others to decode, but allowing the system or its administrators to recover them. I would only do that, however, if the data in the system wasn't "sensitive" and the potential harm that might result from a compromised account is really low.

If you decide that you do want to have a reasonably secure LAN system, and you don't have an internal email system, you might consider alternatives like requiring any user who has forgotten their password to apply in person to the system administrator, who would then issue a new password, using a script that is not accessible to users, or something like that.

the problem with allowing administrators to see passwords is that they have to be stored as plain text; i'm sure you trust your sysadmin 100% but if someone else got access to his computer / or got hold of his login credentials they'd own the system and can access any other account they wish to.

Califdon makes a good suggestion about having the user requesting a password in person; because there is no way to send the password, this seems to be the most secure way. Something to note in a case like this is that the user has to update to a new password ASAP to keep their accounts secure.

Maybe this is getting unnecessarily complex, but what about adding a temporary password field? If an admin updates a user's password, that hash is written to the temporary password field. Logins can then check against the actual password (in case the user remembers) or the temporary password to grant access. If the temporary password was used, the user is redirected to a page forcing them to reset their password, at which point the temporary password field is emptied?

Thanks a lot for the replies guys!!! By the way, I'm an IT student and I'm still learning my ways to PHP, so a big thanks for the new insights.
I'm gonna go with califdon because it seems to be more reliable and practical, but still thank you to celauran..might consider your suggestion in my next projects.