Here is the question I have been posed:
"What is the best way to handle in valid credentials when logging into a site. Do we tell the user if their username was invalid? Or likewise if their password is invalid?"
I did some searching, but I'm having trouble finding a site with some best practices for this, to refer them to.
My Question for the community here:
Does anyone here know a site that has some good guidelines/best practices for this?
Just say that their credentials were incorrect.
Telling them that one piece of information was correct means that you're helping hackers discover user names at the very least.
If I enter:
admin
Password1
for example and I get a response that the password was invalid I now know that there is a user called "admin" on you system. I can now just vary the password in an effort to gain access.
If the response was "invalid user name or password" then I'm no wiser about whether there is a user called "admin" or not.
The most authoritative discussion I can find on this issue is from the "Web Security Testing Cookbook," Recipe 12.8.
The book points out:
You should provide a generic message indicating either the username or password was incorrect; revealing that just the username is correct allows attackers to enumerate valid usernames.
Account lockout functionality, after X number of tries, also carries the same risk; attackers can lockout accounts to find out if the usernames were valid or not.
You can read the whole "recipe" via Google Books here:
http://books.google.com/books?id=VmrSJ3V-s_MC&lpg=PA249&ots=cU7V62FQOA&dq=web%20security%20reveal%20valid%20username&pg=PA248#v=onepage&q=web%20security%20reveal%20valid%20username&f=false
Related
I'm designing a web application as an university project, which involve a "forget password" feature. I have read many topic on this and realize that anything depend on email is not secure. Many articles that point out the weaknesses of email-based solutions prefer on-site solutions, such as asking secret question (What is your pet's name, etc.) or 2-step-authentication
For a school project, I can't really afford the 2-steps, or phone number - based implementation. But doing it via on-site solutions doesn't appeal to me, either.
The so-called "secret key", which are answers to these security question, although excellent for security, I think it is terrible for user experience, not only those question's answer can change with time (had a new pet, change favorite food, etc.). But because of the nature of these question, there cannot be constraint on the answer like an actual password. The user will not remember if he typed "cheeseburger", "Cheeseburger", "Cheese Burger" or "Cheese-Burger" for his favorite food.
so I thought of a mechanism that just partly depend on email:
User click forgot password
=> a form will show up, prompt the user to input both Username and Phone, if there are an account that contain both, an error will be
throw, and the user cannot know if "that inputted Username not exist"
or "it exist but the Phone doesnt match"
=> if the the username and the phone was right, I will generate a token AND an OTP code, then I will redirect to a reset password page with the token (?token=aks123hadsh) then send that
OTP code via email
=> On the backend, if both the token and the OTP code are right, the password change will be committed
By this implementation, a hacker who only had access to the victim's email doesnt know what the token is and if he attempt a request by himself to get the token he must know the phone as well
But this implementation still fail if the hacker had access to the victim's email and know both his phone and username
So my question is, is there anyway to improve this implementation, or is this the limit of a non-2-step solution?
If a user attempts to login to my site (username and password), but fails, should I display what field(s) were incorrect? Or, should I simply state that their credentials were invalid?
If I am dealing with a legitimate user, it would be more helpful to show them what fields were incorrect. But, if an illegitimate user is attempting to breach login, it would be more secure to only display that credentials were invalid.
So, I'm wondering if there is an established answer to this question. Are there any known best-practices for dealing with this issue? Or, is it a matter of taking the known pros and cons and deciding based upon the sensitivity of the site?
By default the best practice is to respond that the combination of username / password was not correct. This is considered best practice for public facing logins. If you are dealing with an intranet site you may be able to provide more information.
If you were to respond that the username was correct but the password was wrong you are allowing malicious users to know they have a valid username and from there go on to guess the password.
After having numerous "ethical hacks" performed on sites I've worked on the recommendation has always been display as little as possible. So, if either user name or password fails just display something like "Login failed".
I think that if a user got either wrong, that can mean he got the other wrong as well, and so you should tell him to "recheck everything".
Also, if you'll notify the user either username or password was wrong, meaning the other was right, if he's a malicious user, you're helping him.
I've noticed that on some sites, when you request a password reminder or sign in, they'll tell you if the user doesn't exist (I think Meetup does this). Other sites will simply say "the user/password combination is invalid" (Google, I believe, does this).
Is there a security reason for not revealing the existence of a user id?
Yes there is.
You want to give attackers as little information as possible
If an attacker knows a username, they can attempt to attack that users email account. for example, if I know your login is chris#gmail.com I can attempt to break into your gmail account. They can also see what other sites you might registered at, and attempt to break into those sites (perhaps a site author didn't properly secure their db), and steal a password and attempt to use this password against other sites that chris#gmail.com is registered at.
If the attacker doesn't know what a valid username is, they essentially have to crack a password that is essentialy: Username.Length + Password.Length long, which increases the time it takes to crack an account.
Yes: don't give any password generating bots a reason to try to crack that account.
Edit:
Also I imagine, you can't contact them and claim that your email account was hacked on that user account and give a new (fake) address.
Besides the other reasons given, apart from hacking attempts, there can be a privacy concern. Sometimes the userid can be related to the person: when the user has a standard nick that uses in many sites, or when he uses a full -and uncommon- name; or, more critically, when the userid corresponds to a document number -as some e-banking sites do. Giving freely that info (efectively telling everybody "this userid is in my database") could be an serious privacy issue.
No, there isn't a good security reason for it. There are security reasons for it - just not good ones.
The same answer has been given here and elsewhere over and over: it gives the attacker extra information and you want to give them as little as possible. This only works against stupid attackers and they are not the ones you have to worry about. There is a major flaw with this argument - both from a theoretical and a practical perspective.
The username can often be checked in other ways anyway (practical)
The example of email is particularly ironic, since the entire point of an email address is to give it to other people, so that they can email you. Email addresses are not secret. (Of course, you would not want to give a list of addresses that exist, but saying whether the given address exists or not is a different matter.)
In cases other than email you can often check for a username by attempting to register with it. If the username already exists the system has no choice but to tell you so! Even if it tried to be coy about it and gave you a generic error an attacker with half a brain would still figure it out, while normal users would be annoyed at not being able to register and leave.
The username is not a secret (theoretical)
In security it is important to define what is a secret and what isn't. If people believe the username is secret and it isn't that's a problem - they have the illusion of security, which is worse than no security. The user needs to be clear on this: the password is secret, the username is not. Even if you are not aware of any ways to obtain the username you cannot rely on the fact that maybe someone who has your password won't have your username. If your password is compromised it's all over.
Since the username typically cannot be truly secret (it identifies the user, after all) it can become a "half-secret": something that's not usually revealed, but is if you push hard enough. People will often think that two "half-secrets" make a secret - but they don't. Of course, they don't think of it in those terms. Instead they will think "it's not so bad if I have an easy PIN, because nobody can use it without my bank card anyway" and separately think "it's not so bad if I lose my bank card, because nobody can use it without the PIN anyway".
Even if the username was a secret it would not improve security. Why not? Because you now simply have two passwords. Two passwords is not "defence in depth" - it is simply one password that has been split into two parts (one of which is quite easy to compromise). It's less effective than just making the password twice as long (or twice as complex).
it gives an attacker one more thing it needs to find. it's an easy requirement, but it is something anyone with a good reason should know, but isn't necessarily known by someone who shouldn't be there.
As a general rule of thumb, don't give an attacker any more information that is absolutely necessary. Is someone enters an email address that's not in your system, you don't have to tell them whether that email exists or not, so don't.
There are certainly stronger forms of defence, but for "defence in depth" every little thing adds up.
In many applications when you make a mistake in either your user name or password you get a non-specific error indicating that either the user name entered does not exist or the password is incorrect for that user name.
I (naively) would expect the application to specify which one of the two errors happened. Is there any reason for not differentiating between them? I guess it would make it more difficult for an attacker to guess a correct user name/password combination, but is there any literature, research or similar that backs up this assumption?
The reason would be security: it prevents finding out which user names exist based on failed attempts.
This should be balanced with the user experience; if you're told that either your user name or password is incorrect, it can be perceived as very unhelpful or annoying.
Common sense dictates that an ambiguous message is better because an attacker would be unable to know if they had guesses a correct username.
It's an extra hoop the attacker needs to jump through. If he's cold-attacking an application he won't know any usernames or passwords. Why give him an extra bit of information to tell him that he has found a username? It's better to withhold the information.
What if the attacker is just looking to confirm that a particular username exists? Say, the name of a politician as a username for a fetish site, as an example. The username itself is sensitive information and you do not want to confirm which exist and which do not.
Yes, that’s exactly why many apps/sites do not specify which part of the login is bad. I used to have the same complaint, but then I read a bunch of computer security books including 19 Deadly Sins of Software Security. Among other things like overflows and SQL injection, Michael Howard does explain the reasoning of returning a unified error for logins.
HTH
it's all about giving an attacker as little information as possible.
Some sites go even further with this on password reminders. When you input your email address to receive a new password or a password reset link they don't tell you if your email address is registered in the database but give you a message like this: "if the email address you entered is in our database you will receive a message..." This prevents the attacker from finding out which email address was used by the victim and may also announce the victim that someone is trying to break into her account.
My company is developing an online HR and Payroll application where securing access is critical. I'm clear on how to lock down most of the authentication/authorization processes, except for the 'Forgotten Password' page.
My initial plan was to require the user to enter both an e-mail address and a response to a previously selected/entered challenge question, with a temporary password being mailed to the e-mail listed (assuming the e-mail is valid). But I've read here and here (both on SO) that the challenge-response approach is insecure.
If we're only e-mailing a temp password though, is it really that insecure? The only more secure option I can think of would be to require the user to call their Customer Service Rep, which would greatly burden our employees.
What am I missing ... is there a better approach? Thanks!
Don't email a temp password, email the user a URL+token to a reset-password page. That way no password is ever changing hands unencrypted. It's also immediately obvious to the end-user that their account has been compromised if they try to go to that page and the reset token has already been used.
Added from the comments:
I think challenge-response ("secret question") aspects actually make things less secure, because they are generally things that can be discovered by researching public info about the target. The fewer steps total, the fewer that can be broken without anyone knowing. Letting reset emails go early and often is a good way to let a human know the attempt is being made.
As explained in this article, Governor Palin e-mail account was recently hacked using answers to previously asked questions. From the article:
As detailed in the postings, the Palin hack didn't require any real skill. Instead, the hacker simply reset Palin's password using her birthdate, ZIP code and information about where she met her spouse -- the security question on her Yahoo account, which was answered (Wasilla High) by a simple Google search.
There are a few common ways to manage lost passwords:
The Secret Question: It is actually a weaker form of authentication, just like people above posted. User may choose something really simple and it is easy to guess. I advise against this, because it does not require any technical "hacking"
Mail a new password. To circumvent this control, access to the e-mail account is required or a Man-In-The-Middle (MITM) position is required: You either read the temporary password from user's inbox or intercept in the middle. This approach is ripe for misuse, because anybody can reset the password and force the user out of the system, if he can't read the e-mail with new password.
Mail a password reset hash, to circumvent this, you need access to inbox or MITM, just like in case before this, but no passwords are actually reset until confirmation is done. Thus, user can not be locked out of the system, even if he did not read the e-mail. Add a cooldown timer to one reset per 8 hours to prevent Your system from flooding user's inbox.
Consider some out of band communication, for example, in the printed contract, write down a PIN. Then have the user call Your helpdesk from a known phone number (check with Caller ID) and give his username and PIN.
Wouldn't it be easy/feasible to outsource the whole password management just like SO did and use OpenId or similar? Of course this would add another dependency, but you'd trade that against the need to save (and secure) passwords and deal with them as you described.
You said it is an on-line HR and payroll application. Do you have the option of a user indicating he/she has forgotten his/her password and that generating a message to an HR representative or some official in the organization who can confirm identity and then issue a password reset?
In short, challenge questions are often the weakest link. They're easier to guess than a password and effectively operate as a proxy for a password, so they actually reduce security rather than enhance it by providing another attack vector that's actually easier to break. The Web Application Hacker's Handbook has some great information on this area.