I want to to implement password recovery in my web application.
I'd like to avoid using secret questions.
I could just send the password by e-mail but I think it would be risky.
Maybe I could generate a new temporary random password and send it by e-mail but I think it is as risky as the above point.
Can I send a url by e-mail for example http://example.com/token=xxxx
where xxxx is a random token associated with the user. So when the user navigates to that url he/she can reset the password.
When I was in the Air Force the security rule we had was: When setting or resetting passwords, do not send the user id and the password in the same email. That way, if someone is intercepting emails snooping for passwords, he has to successfully intercept BOTH emails, and be able to connect them, to breach security.
I've seen a lot of sites that use the "go to this URL to reset your password". Maybe I'm missing something -- I don't claim to be a security expert -- but I don't see how that is any more secure than just inventing a new, temporary password and sending it. If a hacker intercepts the email, why can't he go to that link and see the new password as well as the legitimate user could? It looks to me like extra hassle for the user with no security gain.
By the way, congratulations on NOT using security questions. The logic of this device escapes me. Since the dawn of computer security we have been telling people, "DON'T make a password that is information about yourself that a hacker could discover or guess, like the name of your high school, or your favorite color. A hacker might be able to look up the name of your high school, or even if they don't know you or know anything about you, if you still live near where you went to school they might get it by tryinging local schools until they hit it. There are a small number of likely favorite colors so a hacker could guess that. Etc. Instead, a password should be a meaningless combination of letters, digits, and punctuation." But now we also tell them, "But! If you have a difficult time remembering that meaningless combination of letters, digits, and punctuation, no problem! Take some information about yourself that you can easily remember -- like the name of your high school, or your favorite color -- and you can use that as the answer to a 'security question', that is, as an alternative password."
Indeed, security questions make it even easier for the hacker than if you just chose a bad password to begin with. At least if you just used a piece of personal information for your password, a hacker wouldn't necessarily know what piece of personal information you used. Did you use the name of your dog? Your birth date? Your favorite ice cream flavor? He'd have to try all of them. But with security questions, we tell the hacker exactly what piece of personal information you used as a password!
Instead of using security questions, why don't we just say, "In case you forget your password, it is displayed on the bottom of the screen. If you're trying to hack in to someone else's account, you are absolutely forbidden from scrolling down." It would be only slightly less secure.
Lest you wonder, when sites ask me for the city where I was born or the manufacturer of my first car, I do not give an actual answer tot he question. I give a meaningless password.
</rant>
First off, do not store a plain-text copy of the user's password, or even an encrypted version. You want to only ever keep a hashed copy of the user's password.
As for recover solutions, I find that the recovery link to change the user's password is the best solution in my experience. It will probably be a bit more convenient for the user, while being largely the same from a security point of view as sending a new random password to be changed after next login. I'd still recommend having the recovery url expire after a reasonable short period of time, as well as only being usable a single time.
Hard to say what you should do, as pretty much any solution to this problem will weaken security. Unless maybe you want to investigate sending an SMS, callback verification, one-time password generators, or other such schemes that take password recovery to a different medium.
However, what you should not do:
Send the password - because after all, as has already been mentioned, you don't have it.
Generate a new temporary password - not only is this as insecure as sending the password, it also leads to the possibility of a denial of service attack. I can go to the site, pretend to be you, request a new password and then (if you haven't checked your email) you can't log in, don't know why and have to request a new new password ...
The token is probably the way to go. Receiving it notifies a forgotten password request, but doesn't take any action unless you confirm. You would also make it a one-time token with a relatively short expiry time to limit risk.
Of course, a lot depends on the application. Obviously protecting financial and other sensitive information is more critical than preventing your account being hacked on mytwitteringfacetube.com, because while it's inconvenient, if someone wants to steal someone's identity on a social network site, they can just open their own account and masquerade with stolen information anyway.
Obviously, you can't send the original password by email, because you're not storing it (right?!). Sending a temporary password (that must be changed, because it only works for one login), and a link to reset the password are equivalent from a security point of view.
I don't unnderstand the attitude towards the secret question method. It's not like I am going to make my password "BlueHouse" and then make my security question "What are your two favorite things?" and the answer "Blue and Houses". The security question is not the magic key to get the actual password. It's usually a way to get a new password sent to the email address on file. I don't know how else you guys do it, but it sounds like you do one of two things.
1) The user clicks a "I forgot my password" button and the new password is sent to the user.
2) The user clicks a "I forgot my password" button and then has to answer a security question before getting the new password emailed to the address on file.
Seems to me that option number 2 is more secure.
Why is sending a token any more secure than sending the password? If an email account has been hacked, it's been hacked. It doesn't matter if there is a link to reset the password, a token, or a new password. Don't forget, most sites don't say "The new password has been sent to the following email address for you to hack into". A hacker would need to guess the email address that needs to be hacked.
I agree with Andy. Aren't security questions normally independent of the password? (mine are) Meaning they have a question and an answer and aren't related to the password. It seems like this is used to prevent spurious password reset requests and actually does have a use.
Imagine - someone could go to a site's "forgot password" utility and enter a zillion email addresses - or just one person they want to annoy. If the password is reset at that point, the people belonging to those email addresses would have to then notice in their email the password reset and login to the site with the reset password next time they went there. With the security question, this isn't as easy for someone to do.
I see Amazon sends a link to the given email. They also require you to enter a captcha to prevent DOS attacks. Because it's a link, I imagine that means they did not reset the password immediately and it would be reset once the user clicks the link. With the scenario above, the user would just see the email and note that "no I didn't do that" and go about their business not having to change their password needlessly. A security question might have prevented the attempt at the beginning and the legit user from getting the email in the first place.
Here's a whitepaper on it:
http://appsecnotes.blogspot.com/2010/09/latest-forgot-password-best-practices.html
This one actually recommends secret questions as a major part of the authentication process. And sending an authentication code via email and requesting it is just an add-on layer you can optionally include.
It really comes down to how much security you want to have. One the one end of the extreme is a password reset process that involves contacting and certifying that you are who you claim to be, e.g. via id, because your mailbox could be compromised as well. Actually, as people tend to use the same password everywhere this is very likely. On the other end there is the standard approach that involves just sending out an email with a random new password.
"Secret" questions and answers are just another form of username and passwords with the fatal flaw that they are usually incredibly easy to guess, so good that you don't want to use them.
To your point about the token, I don't think it makes a big difference in overall security. Whether you send out a token that allows a user to change the password or whether you send out a random password right away doesn't make a big difference.
Just make sure the token is only usable once and preferably only in a limited time span, e.g. +24h after requesting it.
And, as pointed out by previous answers, NEVER EVER store plain passwords. Hash them. Preferably add salt.
Here's how I resolved it:
I added retrieve_token and retrieve_expiration fields to my 'users' table.
The user requests a password reset by providing their email and filling out captcha. A random hashed value is generated for their retrieve_token field - i.e. md5($user_id.time()), while retrieve_expiration will be set to a datetime that expires in next 45 minutes. Email is sent out to the user with a link:
https://example.com/reset-password?retrieve_token=912ec803b2ce49e4a541068d495ab570
SSL should be mandatory when authentication is required. You can also add a table for logging reset requests that stores email and the IP address. It helps track down possible brute attacks and you can block attacker's IP if necessary.
You could implement security question for requesting password reset, but I feel captcha would be enough to discourage anyone from repeating the request multiple times.
#Jay. The reason why you go to a URL to reset your password instead of just sending someone a new temporary password is more than just security. Without something like a URL with a token, a person could reset another persons password. There is no need to gain access to the email. If someone had a bone to pick with someone, they could just keep initiating a new password reset. Then the poor target has to logon and change the password again and again.
By sending a token, the user's password does not change until they login with it and confirm it. The spam of reset emails can be ignored. Tokens are just as easy (if not easier) to generate as a new password by using a GUID, it's not really extra hassle for the developer.
Also, because the GUID is unique (a generated password might not be), a token can be tied to a username. If the incorrect username is given on the URL, then the token can be cancelled (i.e. when a different person initiates it and someone intercepts it.. assuming that the username isn't the same as the email).
#Jay. The proper use of security questions is to initiate a password reset email, not for actually resetting the password. Without a mechanism such as a security question, one could initiate a password reset. Althought seemingly beign, sending a reset email could be sent to an email that might no longer belong to the original owner. This is not rare. For example, when employees leave a company, often those mails are forwarded to another employee. A security question, adds a low level of obfucation to that scenario. It also reduces issues where one person keeps initiating a password reset on the wrong account causing some poor sod to get unintentionally spammed. Security question are really not meant to be truely secure, they are just meant to reduce scenarios such as those. Anyone using a security question to actually reset the password is doing it wrong.
Regarding security question/answer. As a user of websites I personally don't use them (I enter garbage in them). But they are certainly not useless or meaningless as some say here.
Consider this situation:
A user of your site has left his desk to go to lunch and didn't lock his workstation. A nefarious user can now visit the page for recovering/resetting password and enter the user's username. The system will then email the recovered/reset password without prompting for the security answer.
Here's an example of how someone did it with Node.js, basically generate a random token, an expiry time, send out the link with the token attached, have a reset/:token route that ensures a user exists with that token (which is also not expired) and, if so, redirect to a reset password page.
http://sahatyalkabov.com/how-to-implement-password-reset-in-nodejs/
Related
I am implementing forgot password feature for my website, and while looking at other websites for best practices, I found that gmail enforces this, no other site I looked at enforced this constraint.
There is a lot of rather out-dated ideas about passwords and password security.
If a user has a password compromised -- and then however many days later they change it -- the attacker is now blocked from the system.
Should that user ever go back and re-use his old password, then the hacker might decide to retry that account/password and regain entry into the system.
Of course, it opens up a whole new set of problems. Make it so a user can't remember his password and they will start writing them on sticky notes taped to their monitor.
Personally? On all the sites I've worked on, I've never thought it important to add password expiration /or/ limits on what passwords may be (re)-used.
I would have thought it provides little to no added security. You are trusting the user to not lose their password but I guess it can go both ways.
If they have to choose a new password then they may have to write it down or be more likely to forget it again however if they have a new password it is less likely that someone who knows a password they use could use it to access your website.
Either way make sure you are storing the hashed password for comparison and not plain text.
I'm wondering what the best behavior is when a user requests a password reset for an email that doesn't exist.
Context: user is not logged in. They just enter an email and hit a reset button.
If I tell the user requesting the reset immediately that the account doesn't exist, that's both a bit of security hole and a privacy issue.
If I do nothing and it's an innocent mistake (they thought they had an account), they'll be wondering what the heck happened. Most mysterious option, least subject to abuse.
I can send an email that says a password reset has been requested but there's no account (and should be ignored blah blah blah). This seems the least noxious but it is a little subject to abuse.
Update: On further consideration, I don't really so how 1 is a big deal since they can get the same information by simply trying to sign up/use the same email ... unless I'm missing something ...
I personally would go this way:
User enters e-mail address.
Screen says "request will be processed, e-mail has been send" or something along those lines.
If there is no account linked with this e-mail address: don't send a mail, but don't tell the guy requesting.
If there is an account linked with this e-mail: send the reset e-mail including the usual "if this wasn't you simply ignore this mail, if you suspect abuse please contact $foobar"-message.
Here is why i would NOT tell anyone whether an account is linked with this e-mail address: Privacy. If you told everyone, everyone could check if $person is using $service.
Figured i would include why i wouldn't send a mail if there was no such user: Why should i? The user will probably either know which email address he used or try several at once (or only wait a short time span). Of course there are cases in which it would be a bit more userfriendly if one would send those mails, but they aren't important enough to negate the abuse potential.
There is not much abuse potential if only one website does that stuff (as long as they wouldn't send multiple mails in a short timespan), but imagine every webservice going this way. You would just have to collect a few of those services and then emailbomb someone 'you' dislike, without hitting any spamfilter!
Personally, i'm a fan of:
The user enters an email.
Whether or not the email exists, say that it has been requested, and if you do not receive an email shortly, try again or contact us.
In the email, state a password request was submitted, and if it wasn't the user, then to ignore the email.
Also,
If you're worried about bots scraping your site for emails, add a Captcha.
If you're worried about people hacking accounts, add a second layer that prompts for a secret question answer.
In my opinion the third option is the best compromise between user-friendlyness and security. Option 1 seems to be to big of a privacy issue. Using option 2 the user can not know if he has an account, but registered with another email address or if the reset system doesn't work.
I would do something like this
Ask for the username or email
If that email or username is present, send all the email to the person, with the reset password.
Finished :)
I have an Android app that I allow users to have a password in and "lock" the app so their friends can't look inside without their password. It doesn't use a web service or anything, and the password is stored in a private file within the app. Problem is, the users like to forget their password, then email me asking me to do something about it. Right now I can't. So what I want to do is have something that creates, and consumes a random password. The user could email me, and I could give them some random key the app could recognize, and let them in so they can change their password.
It doesn't have to be anything super secure. Any help is appreciated.
I don't think its a good idea to implement a "backdoor" in your application. THis will create a very bad taste.
If i understood correctly, you want to "unlock" the application, not knowing if the user doing this is in some way authorized. I steal a device, send you an email and you take care i can see the data. Sounds bad...
All (good) safes i know rely on the user to take care of their keys. They want security and they are responsible.
EDIT
You can provide a "security question".
Anything else i tried to construct for an "autonomous" password reset raises sever security questions (what are the authentication/authorization mechanics)
EDIT
How far are you willing to go? Assuring the possession of something (like an SMS or mail account) may reduce the issues and give some impression of security. So you can intercept SMS or mail from a PREDEFINED (application settings) account with lets say the key word "unlock". If not set, this feature is disabled. SMS interception should no be that hard.
Why don't you just build password reset functionality in the app itself? If it's not using a web service, why do you or your server need to be involved at all?
If they don't remember their security passwords, for example, your server could store an md5 hash of their password to match up their mobile device with their record on your server so you can send them a key to reset the app.
Couple of thoughts:
Is there any sort of registration process? If so, at registration time you could randomly generate a second password that you don't tell the user but just keep on file for such contingencies. Or similarly, you could offer users a "password recovery" option -- click this button to generate a backdoor password.
You could have some algorithm that generates a password from the machine id of the device and that works as an alternate password. If you were a big organization with millions of copies of your app out there, or if the information in your app was super secret, this would be a super bad idea, as sooner or later hackers would figure out the algorithm and then they could break into any machine they wanted to. But if you're a small target, it's likely no one would work hard enough to crack it.
Do you necessarily know anything about your users? Like could you generate a password from their credit card number or their address or some such? Of course this makes you vulnerable to any hacker who could discover whatever information about a potential target.
Anything like this you do you are going to create a big potential security hole: What if someone steals someone else's device, then emails you and says they lost their password? How do you know it's the rightful owner of the data? If anybody can call or email and say, Hey, I lost my password, please let me in the back door, then you have no security any more.
I'm looking to add password-reset functionality to my site and have been browsing the numerous threads discussing various aspects of that issue here on SO. One thing I haven't really seen clarified is how much information to require from the user for confirmation before sending out the reset email.
is email alone enough?
email + account username?
email + account username + some other identifying value all accounts must input?
I don't want my site to seem like an old wrinkly nun with a ruler, but I don't want people to be able to abuse the password reset system willy-nilly.
Suggestions?
I use just an email and send an email to that person with an activation code in a link. That activation code expires within 2 days and once it gets uses it also is invalidated.
This means the person has to have access to that email account in order for it to work, and it can only be used once.
It is not uncommon to use the email + account username, but my email IS what you sign in with, there are no usernames. The decision is up to you.
I think email is enough without it becoming a nuisance.
First concern should be security. How bad would it if another person got a hold of a user's password? If this is unacceptable, I'd say what Babiker said - email and a security question of some sort, preferably something that's never communicated between the site and the user, with the exception of sign-up process or a security settings edit by the user. The assumption here is that the user's email account has been compromised.
If security is not a huge deal, i.e. there are no real privacy/financial/etc risks involved, I think email is enough. To minimize risk for nuisance, you could do what Kerry suggested - i.e. not reset the password automatically, but provide a verification link. Also, you might want to place some restrictions on how frequently the feature can be used by a given user to prevent someone from filling your inbox by repeatedly entering your email.
Email
Some other identifying value all accounts must input. Like a security question.
I'm wondering what the best method is for creating a forgot password function on a website. I have seen quite a few out there, here are a few or combination of:
passphrase question / answer (1 or more)
send email with new password
on screen give new password
confirmation through email: must click link to get new password
page requiring user to enter a new password
What combination or additional steps would you add to a forgot password function? I'm wondering about how they request the new password and how they end up getting it.
I'm operating on the principal that the password cannot be retrieved; a new password must be given/generated.
Edit I like what Cory said about not displaying if the username exists, but I'm wondering what to display instead. I'm thinking half the problem is that the user forgot which email address they used, which displaying some sort of "does not exist" message is useful. Any solutions?
I personally would send an email with a link to a short term page that lets them set a new password. Make the page name some kind of UID.
If that does not appeal to you, then sending them a new password and forcing them to change it on first access would do as well.
Option 1 is far easier.
A few important security concerns:
A passphrase question / answer actually lowers security since it typically becomes the weakest link in the process. It's often easier to guess someone's answer than it is a password - particularly if questions aren't carefully chosen.
Assuming emails operate as the username in your system (which is generally recommended for a variety of reasons), the response to a password reset request shouldn't indicate whether a valid account was found. It should simply state that a password request email has been sent to the address provided. Why? A response indicating that an email does/doesn't exist allows a hacker to harvest a list of user accounts by submitting multiple password requests (typically via an HTTP proxy like burp suite) and noting whether the email is found. To protect from login harvesting you must assure no login/auth related functions provide any indication of when a valid user's email has been entered on a login/pass reset form.
For more background, checkout the Web Application Hackers Handbook. It's an excellent read on creating secure authentication models.
EDIT: Regarding the question in your edit - I'd suggest:
"A password request email has been
sent to the address you provided. If
an email doesn't arrive shortly,
please check your spam folder. If no
email arrives, then no account exists
with the email you provided."
There's a trade-off being made here between ease of use and security. You have to balance this based on context - is security important enough to you and your users to justify this inconvenience?
Send email with new password.
FORCE a password change when they arrive and key in the new password.
This ensures that the person who wanted the password will be the only only getting in to the account.
If the email is sniffed, someone could get in to the account (of course), but the real party will discover this immediately (as their password you just sent them doesn't work).
Also send confirmations of password changes to the users.
If someone get the new password, and then an email saying "thanx for changing the password", they're going to be rather puzzled and will talk to an admin if they didn't do it.
Using the email verification/password reset link will give you better security.
If you look around this is how most websites do it and people are pretty used to this verification, so I'd recommend using this type of authentication.
I would think (gbrandt's) Option 2 would be a great method if it is combined with some personal information you already have for the user. i.e date of birth.
When the user requests a new password (reset) via entering his email address, he also has to enter a correct date of birth (or something else) before the password is reset and a new one is emailed to the user.
Only those who know him well can possibly annoy him by resetting his password! It cant be a stranger or a bot
Upon 5 or 7 bad email-address & date of birth combinations the user is emailed that his password has been requested to be reset and has failed due to an incorrect credential. Then password resetting for that account is suspended for 24hrs or any desired period.
(if too many users contact the webadmin regarding this email he'll know someone is trying to maliciously attain information from your website/app)
What do you guys think?
Option 1. is not a good idea, as generally his becomes easily guessable by others. Sarah Palin's personal email (Yahoo I think) was hacked in this way by a third party.
The other options are better and previous posts have outlined the detail.
The idea I was thinking about was to sign the data in the link that is sent to the user. Then, when the user clicks the link and the server receives the call, the server also gets the encrypted part and can validate that the data was untouched.
I have implemented a JAVA project for this use case. It is on GitHub, open source. It answers your question perfectly... implemented in Java.
As for the link in the email - it generates the link, plus validates it upon usage.
There are explanation for everything (and if something is missing - let me know...)
Have a look: https://github.com/OhadR/Authentication-Flows
See a Demo here.
This is the client web-app that uses the auth-flows, with the README with all explanations. it directs you the implementation: https://github.com/OhadR/authentication-flows/tree/master/authentication-flows