Hi all,
I want to send an email, those who are already registered in my site, now they forgot their password to login…
Accepting username/email from user,then forward the mail with password…
Help me regarding this…
Thanking you…
Are you looking for a complete php script for that or just the general idea on how to do this?
First of all it depends on how you store passwords - hashed, encrypted or plaintext. Hashed value usually cannot be converted back to original, so you will have to create a new temporary password and send it to user.
encrypted value usually can be decrypted
plaintext is easy, just get the value from database and email it.
Do you need to know how to send someone an email with PHP? There is a mail command. http://www.php.net/manual/en/function.mail.php
Passwords should never be stored in the clear. The should be hashed, and they should be salted. This process perforce destroys whatever the original password was.
Last password recovery system I wrote followed this logic
- User provides email address.
- System generates a random reset hash and sends an email with a link containing that hash.
- If the user doesn’t follow the link in 1 hour the hash is discarded.
- When the user follows the link back in they are prompted to provide a new password.
The hash in the link in effect acts as the temporary password.
What kind of database are your passwords stored in? I have code if you need it.
Other than hash, you can use encryption with php’s mcrypt library. This way they are not stored in plaintext but can still be decrypted with the secret key, so basically it will be possible to restore the password to plain text and send it out. I think this is just as secure but better because you can decrypt it, you just have to be sure that the decryption key is secure and cannot be accessed by any unauthorized person.
imho hashing a password or anything that doesn’t allow the password to be unencrypted is better.
If a password can be unencrypted then it’s “theoretically” possible that an admin person or anyone with access to the data in the database could unencrypt the passwords. With hashing, like sha1(), a hashed string cannot be restored to its original value and so is much better security wise imho.
If a user clicks the “Forgot Password” link I normally do the following:
- prompt them for their username.
if the username exists in the database then
-
generate a random string of characters between 6-8 chars long to be the new temporary password.
-
send the new password to the registered email address of the username in 1)
-
when the user logs in with the new temp. password they are immediately prompted to change their password to something else before they can proceed any further.
It all boils down to how you want to password recovery to work. If you want to make it easy for end user and just send him a password, then encryption is better than hashing. the user will thank you.
Of cause if you store the codes for nuclear weapons launch then you better hash it and then hash that hash again just to be sure.
Maybe - but I think my users would thank me even more if they knew no-one had access to their “real” password.
What you guys have to realise is that the OP is just looking for the simplest password recovery method.
I would advise the OP to disregard all the hashing and encrypting mentioned above. It does not have to be that complicated. First ask the user to type in his email, if it matches the one you have on record, then send to the user their original password in the database. As simple as that. If the user believes that his password is compromised, he certainly will change it through the password change utility(I assume you have one). What people have to realise is that even if you prompt user to change password, they tend to change it to the old one if they happen to remember. So sending the original one saves a lot of hassle for both the programmer and the end-user.
That might be “easier” but is definitely less secure because to send the original passowrd means that whoever has access to the data in the database can see and use, for malicious purposes if they want to, the actual password of every registered user.
Depending on the application, a malicious user could possibly do a lot of damage before the real owner of the account even realises someone else has accessed their account.
Imho, storing actual passwords in a database is a huge no-no 
Also, it’s quite possible that if the passwords are misused, stolen or whatever by a malicious user, the website developer could be legally liable for some if not all damages for not taking more secure means, with very little extra coding, to protect users’ passwords. I don’t see the point of putting oneself in that possible situation unless a client strictly specifies they want the actual passwords stored.
I did not say the actual password should be in plain text format in database. On the contrary. The password should be in encrypted form in the database. But the password recovery script could pick the password from the database, decrypt it and send it to user.
You may argue that the password could fall victim to the “man in the middle” style attacks in the Internet. Yes. I agree. But we all know that even the securest of method is not secure after all. In other words, security is not 100%. There is always a degree of insecurity that every developer is willing to live with, unless one is developing code for the Pentagon. Further, the OP is just starting out. You were once like him, and I am sure you were not obsessed with security then. Once he learns more and more, it will dawn on him that he should tighten his code and make it more secure. I am not arguing that one should forget security all together. But don’t make it a hindrance when one is learning the very basics.
I disagree :disagree: because that is only marginally better than storing the actual password because a malicious user or anyone with access to the data in the database or determined hacker could eventually decrypt the passwords.
Hashing a password makes it totally impossible for it to be recovered by anyone afaik.
Agree in general, but personally I am not prepared to settle for 90% security, for example, when with very little extra coding I can get 99.99% security
I haven’t seen anything in the OP’s posts that suggests hashing a password would be a hindrance to them. It’s very little extra code to hash a password.
A determined hacker can just intercept your network packets and sniff out the password that you type in the form. I know, now you going to recommend we all login via ssl. Now all sites are even setup to use ssl, I hardly see any outside or ecommerce sites.
That’s true - but it boils down to maximising security and minimising the probability of unauthorised access to passwords.
Like I said before, I am not prepared to accept 90% or whatever security, when I can easily get at least 99.99% security with very little extra code.
I am yet to be convinced that encrypting and decrypting passwords is just as secure as hashing passwords. To my undestanding of hashing, hashing is much more secure than encrypting and decrypting.
Hi!
For resetting password I would use scheme similar to what Kalon proposed.
Regarding encrypting vs hashing - There would have to be serious reasons for being able to recover the original password: *) Server implements authentication mechanism, that requires it to know the actual password;
*) Server needs this password to run background requests on behalf of user against systems that require this cleartext password (e.g. Check mail);
*) The password is used (deriving encryption key from it) to encrypt data and losing it would mean losing data (which is acceptable course of action if intended so)
The aforementioned are not commonly seen. Usually seing these things means that there are multiple background systems that won’t work together unless credentials/passwords/keys are available to them.
If you are not facing the issues above, then propper hashing scheme (with salt and hash used in hmac mode) would be prefferable. The less user sensitive data you have, the better you sleep. (~;
While I agree hashing is the preferred option for seasoned coders, it still does not guarantee 100% security. Such is the nature of the Internet. I doubt you can get 99.99% of security either. There can be all kinds of potential security holes. So what is the solution? Using SSL for simple registration/login script as lampcms.com put it? To achieve anywhere near your preferred security level would entail using SSL. That is wholly unnecessary? Or would you say you would always use SSL each time a simple login/registration is required?
How is hashing more difficult than encrypting? 
And yes, thanks to FireSheep everyone now is scratching their a… head and thinking of ways to protect session cookies (apart from using SSL not just for login/registration but for every request that depends on session to determine authorization).
Agree :agree: but imho everything else being equal, the overall security of the application will be higher if the password is hashed and not encrypted and then unencrypted when necessary.
I would only use SSL where the client security specifications of the application required SSL. That obviously depends on the sensitivity of the data being sent over the www and how much risk the client wants to carry regarding securing their users’ information.
I think the most telling aspect of this thread is … the OP asked the question 4 days ago but hasn’t returned to say whether any of the answers supplied in this thread provides him/her what he/she needs.