We are building a CRM type app although this would apply to any application where there are "members" and "staff" e.g. a shopping site, dating site, facebook etc.
In our app, users can change their password the usual way, by resetting it with email confirmation. Users can also have more than one email address associated with their account.
What we are trying to work out is how to prevent staff using the system taking over the accounts. We want staff to be able to edit the email address (because someone may phone in and request a change); the issue then is they can simply change the email to one they control - and request a password re-set as a user.
Are there any recommended best practices for this?
You could require the user to also authenticate the action by other means, such as when the email address is changed the user is sent a confirmation code via text message that they must input somewhere.
Another means would be to only allow access to the account if certain information is inputted correctly. This could be address information or DOB. It is unlikely that this information could be guessed from something like a name or account number.
1) Add one of those silly security questions like "What is your favorite color?" and store the answer, encrypted, in the database. Staff could edit the email to their heart's content, but if they didn't know the answer to the secret question the system wouldn't let them change the password. If you have concerns about staff trustworthiness, then you need to introduce something outside their control that serves as a final gateway before you can change the user account.
I imagine a simple implementation would simply check to see if the user reset their password. If so, on login, it challenges them with the security question to "authenticate" them before allowing them to proceed.
2) Logging, monitoring, and auditing. Record which staff accounts accessed the email address change form, what address(es) they changed, what they changed them too, and when they changed them. Also record the connection information of the people accessing the accounts. If your logs show one IP address accessing 4-5 completely disparate accounts, you might need to look into that. (Yes, I know you can use proxies etc. to mask this. Not perfect but it'd weed out the chaff pretty fast).
3) Hire trustworthy people! #2 should really only need to be used as a "check" against abuse instead of the end all be all to stop it.
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 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/
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
I'm trying to decide what to put in a dialog box that tells the user their login doesn't work, there is probably a duplicate. The system uses email addresses as user names, then requires a password.
Right now, I'm using "Email Login" but that just sounds stupid.
For instance:
1) Application Starts, recognizes that it has never been run.
2) Prompts user to create a new account.
3) User puts in an email address and password to use as their new credentials.
4) Well, looks like they've already got an account probably. (This is the most likely case the account creation would fail but I'm using an API and I can't be 100% this is why it failed)
5) I ask them to try again with a different "email login".
Could not create account - try a different email login !
After I check with the API provider, I'll probably try to detect that it is in fact a duplicate account and ask them to try to authenticate that account with a password.
Tell them explicitly that their email address is already in use.
Call it an email address, thats what the user thinks of it as. The fact that you are using it as an id or a database primary key or a hash key is irrelevant to them.
Perhaps: An account already exists for this email address. If you already have an account but forgot your password, please click [here], otherwise please choose a different email address.
I agree with mgb that the best choice is to explain the problem and how the user should proceed.
I would just call it what it is: an email address. I wouldn't suggest that they try a different one, though. Just ask them if they already have an account and, if so, to try logging in with the address/password. If they continue to have problems, give them a contact that they can use to get help.
There is a distinction between the process of authenticating ie logging-on/login and the options a user can use ie. username, userid or email address.
As more websites are having allowing users to login with email address it doesn't pay to be ambiguous, do your users a favour and label the field 'Email Address:'. This way your users are clear on what is expected in the field. If you label it "login:" or something else vague they'll be subtly fooled into thinking they might have created a username when creating their account and try all the usernames they usually use before trying email addresses.