13

After an unsuccessful login attempt, should I inform the user about its reason? Or more generally, how much information about the reason for an unsuccessful login attempt should a web application give?

It's kinda obvious not to inform the user about an incorrect password alone, but to couple it with login - such as 'Email or password is wrong' (or isn't it?). But I started to wonder about informing the user that the account was suspended/banned. Is it too much information? If I give away this information, what I'm giving also is 'this account is registered with this service'. Consequently, if users' emails are used as the login, 'this email is valid'.

But all of this information an attacker could pull out of the registration form trying to register different emails/logins - unless the application would obfuscate the reason for unsuccessful account creation (just 'Couldn't create account with given data'), which is not the best idea from a UX point of view.

With that in mind, lets go step back to unsuccessful login - if an attacker can pull out information about registered email with certain service isn't it just plain stupid to say 'Email or password is wrong'? Malicious/power users will have this information either way, and an unskilled user has to check the login/email and password all over again.

In the end it looks like a Lose-Lose situation ('No security Win - UX Flaw').

UPDATE:
I rethought giving out information about a blocked account - of course this information should be given after providing correct credentials (and then it's not a problem to give even more info about reason for blocking the account, date due and so on...), so it's out of the question.

UPDATE2:
Please consider this question as a question about a design flaw in wepapps. I'm not asking about counter measures to take to prevent brute force attacks (CAPTACHS after a few attempts, blocking a certain IP for few minutes after another few attempts, and so on...)

yoozer8
  • 810
  • 2
  • 7
  • 17
vandalizmo
  • 511
  • 4
  • 11
  • 6
    +1. Insisting on "username or password is wrong" is often cargo-cult security. It can be of benefit, but only when the application is properly designed to obscure the username list through all interfaces (registration, user search, account lockout, rename, etc). Doing that has implications that clash with requirements for many kinds of application. Unless you can design from the ground up taking into account the idea that usernames are secret, there is no point in obscuring the login failure reason, and you are better off concentrating on the other defences against automated attack. – bobince Mar 11 '13 at 12:58

3 Answers3

12

Ok, let's walk through the several possible scenarios here.

1) Display exactly what is wrong with the login attempt

This is obviously a stupid thing to do. By displaying exactly what is wrong with the login attempt, you are helping an attacker narrow down his attack. This is the reason why people recommend displaying a more generic message like Invalid username/password.

See: "Username and/or Password Invalid" - Why do websites show this kind of message instead of informing the user which one was wrong?

2) Display a generic error message

You display a message like Invalid username/password. People correctly suggest that an attacker can simply pull username information from your registration form. A possible counter to this is simply having a CAPTCHA on your registration form. While CAPTCHA's can be broken, this is not trivial if an attacker is simply running an automated script against your website. A CAPTCHA on a registration form is also way less annoying than a CAPTCHA on a login form.

If your username is public information, such as Facebook, this is obviously invalid advice.

3) Display information about blocked accounts

I don't see a valid reason why this should be displayed to a user attempting to login. Send them an email informing them their account has been locked out if needed. Don't bother showing them that information on the login screen.

You can use that to your advantage against bots hammering against your site by blocking IP addresses that repeatedly attempt to login to blocked accounts.

Remember, nothing you do can prevent an attacker from attempting to attack your site. What such measures do is simply make it a lot more difficult for a successful attack to be carried out. If your users have ridiculously weak passwords, their accounts will be compromised by a determined attacker eventually.

Community
  • 1
  • This covers it pretty well – Lucas Kauffman Mar 11 '13 at 09:21
  • Not exactly, i didn't mention CAPTCHA as counter measure from obtaining users login/email because it's not. It's just slowing attacker down. – vandalizmo Mar 11 '13 at 09:27
  • And we can achieve same slowing down by enabling CAPCHA after few unsuccessful login attempts – vandalizmo Mar 11 '13 at 09:29
  • @TerryChia I read question and answers You gave link for and though it has accepted answer proving Your point, it has lots of comments to this answer proving my :] – vandalizmo Mar 11 '13 at 09:47
  • 2
    @vandalizmo What you must know is that *all* of such measures are merely a way to obscure/slow down an attacker. Nothing beats a high-entropy password. Are there ways to bypass such measures? Of course. Should you tell the attacker everything he needs to know? **Of course not!** It's about finding the right balance. –  Mar 11 '13 at 10:18
  • please reconsider my findings on this subject posted in my answer – vandalizmo Mar 11 '13 at 13:07
  • There's also third scenario -- not display anything to user. Wordpress (both .com and standalone, installable one) uses it. Enter either wrong password or e-mail or do anything, what prevent you from login, and all you'll get is a jQuery shaking login box, waiting for you to re-enter credentials. – trejder Jan 31 '14 at 10:54
1

Sorry guys but I cannot accept Your answers because they are just repeating what I believe is 'general knowledge' (or worse - "industry standard") without second thoughts. So, I made some research myself, read some topics about this subject and found how good websites work with this matter..

And it looks like site we're using to discuss this subject (and I believe it's one of best site about IT Security) is rather following what I was thinking :]

Trying to register already used email:
http://img831.imageshack.us/img831/6646/emailinuse.png

Trying to log in with valid email but wrong password:
http://img521.imageshack.us/img521/6545/incorrectpassword.png

Trying to log in with invalid email:
http://imageshack.us/photo/my-images/191/incorrectemail.png/

Watching how this site work and taking into account what were sad in other topics I believe that true answer to my question

How much information about reason of unsuccessful login should web application give?

is:

No more than one could obtain using different parts of the website as a guest

So if I have registration form on my website that would reveal information about registered accounts then it's no use to obfuscate this information in login form.

But if website doesn't have registration form (it's really, really closed site) I would go for maximum obfuscation and after entering invalid credentials replied just with - "Couldn't log in"

UPDATE:
Of course I didn't mean to just argue about this subject or something. I believed that common approach to just say 'Invalid email and/or password' is just giving sense of false security for both user and admin of such website.

Community
  • 1
vandalizmo
  • 511
  • 4
  • 11
  • 2
    First, I would like to say that the StackExchange network doesn't necessarily place a huge emphasis on security. It doesn't even use site-wide SSL. Next, I already mentioned that **all such measures are not a replacement for good strong passwords.** It is true that relying on security by obscurity isn't good. However, don't dismiss the benefits of security by obscurity in slowing down and discouraging attackers. I'd argue that since most users have been trained to accept an ambiguous error message, there isn't even a usability tradeoff in exchange for the slight increase in security. –  Mar 11 '13 at 13:31
  • 3
    @TerryChia As far as there not being a UX benefit... have you ever been to a site where you know you have an account but can't remember what e-mail you registered with? Certainly I'm not the only one. As vandalizmo mentions in his answer something like a bank obviously shouldn't confirm whether its the proper account or not but something like a forum should be fine. – Snuffleupagus Mar 11 '13 at 13:58
  • @Snuffleupagus Can't say I do... I only have 2 email accounts for clearly separate purposes. Moot point anyway since all my account details are stored in KeePass. –  Mar 11 '13 at 14:02
  • @Snuffleupagus An alternative solution to your problem would be to attempt a password reset to each email account (which should send a link to your email.) This would take as much effort as trying to sign in to each email, and chances are that you've forgotten the password anyways. If there is no password reset option, then you're already at the mercy of your memory. – Dani Mar 11 '13 at 17:29
  • @Dani but if you can check to see if the e-mail is registered via a password reset page why would it matter if the login page also indicates whether the e-mail is valid or not? – Snuffleupagus Mar 11 '13 at 18:00
  • @Snuffleupagus You couldn't check, unless you are the email owner. It would not tell you on the site if it is registered, it would just send the email. – Dani Mar 11 '13 at 18:12
  • @Dani So you're suggesting that a password reset form shouldn't indicate if an e-mail was sent or not? What if x user added an extra character on accident and waited 10 minutes for an e-mail that never shows? I'd be irritated, personally. IMO unless you have an explicit reason to have strict security (ie online banking or something similar) you shouldn't sacrifice usability for very minor security improvements. – Snuffleupagus Mar 11 '13 at 18:16
  • @Snuffleupagus Honestly, that problem still exists even if it told you it was sent. User123@example.com and User1234@example.com could both exist and be registered. You would just have send it to someone else. Primary troubleshooting should include validating you entered your email correctly. If you seriously have that much trouble typing your email address correctly, I would question your ability to check your email, type coherently, or use computers at all. – Dani Mar 11 '13 at 18:24
  • The image links are broken. – Flimm Aug 28 '19 at 11:08
0

I would never tell the user what went wrong, except that "something" went wrong. Try again.

Reason is that once you tell a potential hacker which part is wrong, they are half way. Either guessing a password or the e-mail address.

If the user fails, let them have eg. 3 tries. If failed, then ask them politely to check their account details again and if they give up, always provide them with means of how to get the password reset, not resend.

Just let them enter the e-mail and then send them a reset token that automatically expires after a defined periode like 4 or 8 hours + include in the mail WHY this mail was sent and perhaps add a link in the mail to report this as a "not requested token" so we can mark the login attemps client information such as IP for further investigation if needed. Ofcause its already in the logs, but now the users has told us to pay special attention to this failty attempt, perhaps there is a pattern from this IP or something.

Another thing that many login systems does, including windows, is that you raise the delay between allowed entries. So if you make a mistake 3 times or more, it suddently will take a few seconds to get the login prompt. This dealy alone will prevent most "bruteforce" attempts as it will make it hard to check eg. 1000 passwords within an hour.

So, conclusion is:

DONT TELL WHAT WENT WRONG in details, just say: "sorry, but the provided information didnt match any of our records, could you please check if you entered your details correct? if you have lost your account details, then click there to get your account password reset".

The link will then lead to a new prompt where you ask for the e-mail, or just use the entered e-mail if that is part of the login already.

BerggreenDK
  • 101
  • 1
  • please reconsider my findings on this subject posted in my answer – vandalizmo Mar 11 '13 at 13:07
  • I dont say that its not "possible" to do other ways, just as StackOverflow does it by default. But I'll still argue that this approach is less secure. I actually saw that when I tried to answer your question and had to login to my own account (which I couldnt get the password to work with). – BerggreenDK Mar 11 '13 at 15:20