23 ms·

“Invalid username or password” is a useless security measure

413 points by kevinburke 12y ago

hobarrera 12y ago
Indeed, the assumption that usernames should be secret is stupid and senseless. Passwords are meant to be secret. Emails and usernames are not. Heck, emails would be public, were it not for spam issues.
- NoPiece 12y ago
  There are privacy issues though. Take a known email address, run it through 100 sites, and find to find out what kind of sites the person uses.
  - btilly 12y ago
    The point of the article is that you already can do this very easily - just try to sign up to each site.
    - Dylan16807 12y ago
      Which is an easily fixed flaw, when it comes to emails. Usernames, yeah, you're not going to keep those private. But sometimes account names are not the same as display names, and display names can be duplicates, while account names should be reasonably protected.
    - NoPiece 12y ago
      That's sometimes true, but not always. Two examples: a signup may have a captcha, so the cost of filling out the form to check for an email address is high, or something like a bank sign up, which requires additional info besides the email address (account number, SSN).
    - Akkuma 12y ago
      Gmail allows you to use email+whatever. A lot of sites actually support this and this means it becomes significantly harder to determine what sites you use as each email+whatever is considered unique.
- objectobject 12y ago
  Whether the username is sensitive depends a lot on context. If the service is a dating site, gambling, porn, etc. just disclosing someone is a user of the site breaches their privacy. What this really highlights is a lack of consistency. If adding a security measure involves some kind of trade-off (UX in this case), you should really understand what you are trying to prevent and consider the rest of the attack surface. I think it would be a fallacy to immediately give up just because a larger vulnerability exists though. I was curious to see whether there is a way round this and a quick search threw up https://security.stackexchange.com/questions/40694/disclose-to-user-if-account-exists https://security.stackexchange.com/questions/40694/disclose-... - the top answer is quite informative.
tacostakohashi 12y ago
Leaving security aside, "incorrect username/password" is still the more correct and useful statement. Consider the case where you mistype your username (email). For sites like amazon, gmail, hotmail, yahoo, twitter, etc, it is entirely likely that the mistyped username is somebody else's valid username, you typed the password correctly, and "incorrect password" would hide the problem.
- Houshalter 12y ago
  Well you can at least inform the user that the username is incorrect if there is no user by that name.
  - Coding_Cat 12y ago
    You would still have the issues described in the OP. If it says "username incorrect" only when that user does not exist, you can still figure out a username by just trying them with a random password. If you get told "password incorrect" you know the username you just tried already exists.
    - Houshalter 12y ago
      Why is that an issue? You can also do that by trying to create accounts.
- rrrx3 12y ago
  That statement doesn't help the user fix a problem. Either you tell the user that one of the items is incorrect - "This password does not match our records" or "This user name does not match our records". Simply stating "Incorrect username/password" isn't sufficient enough information to prevent the user from making the same error (or even a different one) again. Here's what I tell the developers I work with: Design for the users, not for development ease. This pattern has been successfully implemented by literally hundreds (thousands? hundreds of thousands?) of websites, so there's no excuse for trying to cut a corner and try to concatenate use cases. Either the user name is right and the password is wrong, or the user name is wrong and the password doesn't matter, or both are wrong and through some miracle of absolute unicorn user error they've managed to log in to someone else's account - at which point you have a different issue altogether.
0xffff2 12y ago
Even simpler than trying to sign up for a new account, many sites will tell you if you enter an unregistered email on their "forgot password" page.
- rcthompson 12y ago
  Yes, but that also alerts any valid account with an unexpected password reset.
- jdmichal 12y ago
  Except that entering a registered email will likely result in the legitimate user receiving a password reset email that they did not request, thus immediately raising suspicions that someone may be attempting to access their account. Using the signup form is a much better approach.
- fmx 12y ago
  Some sites don't. They instead say "if an account with that email address exists we've sent you an email with the reset link". That seems like a nice touch, but it's pointless if you can still find out that a given email address is a registered user in some other way (such as by trying to sign up with it). So it's just another variant of the "invalid username/password" message.
cryptoz 12y ago
This doesn't address timing attacks, which are why this is done in the first place. If the code checks only for a username existing and returns the error message, this takes a measurably different amount of time compared to then also looking up if the password matches. The error shown isn't to dissuade people from using web pages to try to gain access to accounts - it's because the raw code itself doesn't know which is which, and writing code that does enables fast-paced timing attacks.
- Dylan16807 12y ago
  > This doesn't address timing attacks, which are why this is done in the first place. I don't follow. Surely the reason to hide usernames is not to prevent a timing attack that would reveal... usernames.
  - thisGuysAccount 12y ago
    I might be missing what you're not following, but here's a quick explanation (and a reason why it's not a concern) Correct username, correct password: takes 30ms to execute the code Correct username, incorrect password: takes 15 ms to execute the code Incorrect username: Takes 7 ms to execute the code. You fuzz usernames, you get one that takes 15 ms, you know that's a valid username. You then start working the password. Not necessary on most systems, because we're working at speeds that are measured in nanoseconds, and since we're using networks for many attacks, the delays are unpredictable and measured in (at least) milliseconds.
    - Dylan16807 12y ago
      I understand how the timing attack works. I don't understand how it's a justification for hiding usernames. "You need to try to hide A because if you're not careful they can find A." If anything the timing attacks weaken the argument against hiding usernames.
- westi 12y ago
  > This doesn't address timing attacks, which are why this is done in the first place. If the code checks only for a username existing and returns the error message, this takes a measurably different amount of time compared to then also looking up if the password matches. Timing attacks are solved by how you implement the backend checking code and not how you present the result to the end user in the most user friendly manner.
matthijs_ 12y ago
Excellent point. However, I think username / password will be (at least partially) replaced by this: https://passwordless.net/ https://passwordless.net/ - Token based authentication
- Benferhat 12y ago
  If I'm not logged into a site a that I regularly use, I'm probably not logged into my email, either. In order to log into my favorite site with Passwordless, I have to log into my email as well. With my password. One login for the price of two, and I'm still using a password.
why-el 12y ago
None of the author's recommendations conflict with the practice he is advocating against. I think websites say "Bad combination" not because usernames are treated equally with passwords, but because you don't have a choice but say that. If I tell you that your username is incorrect, am I telling you your password isn't? This would be silly, because if the website is new and I know a password is correct, then I can either find the username out there (if the website is social), or pretend I forgot my username and have them give it to me. Assuming that's not what I am saying, then the user is surely to have a bad experience anyway, since they will need to figure out a wrong username, and then in the worst case, a wrong password. When you say a "bad combination" you at least eliminate a possibility to mislead them into thinking only one of their credentials is wrong.
- tracker1 12y ago
  If the username is wrong, and you don't tell them, they will spend several tries on passwords that will never work.. because the user is invalid. I have a number of sites I don't use often, that I wind up having to do a password reset on to then find out I'm not even using the right username... there was literally no gain from this... Any hacking attempt can do the same to determine if a username was valid or not. It's making things easy for machines to do harder for people to do, which is the wrong approach to security.
- spion 12y ago
  "Sorry, we don't have a <name> in our database" isn't misleading. If the user enters an incorrect password too, the subsequent message "Invalid password for <name>" will let them correct it.
  - why-el 12y ago
    Perhaps misleading was the wrong word, but as you said it yourself, saying that would lead to a user experience that is much worse than a simple "Bad experience", which is exactly my point.
- masklinn 12y ago
  > I think websites say "Bad combination" not because usernames are treated equally with passwords, but because you don't have a choice but say that. Of course you do. > If I tell you that your username is incorrect, am I telling you your password isn't? This would be silly Of course it is, a password is checked against a username, not against the whole database. If the site is telling you the username is incorrect it's telling you just that: the username is incorrect. It wasn't able to go any further and check the password since it has no idea which password it should check for (or even, if you're correctly storing passwords, which salt it should use for the password check). Your criticism doesn't even make sense.
anigbrowl 12y ago
Unfortunately this assumes that there's no other way for an attacker to discover whether a username/email address is registered for a service. This assumption is incorrect. No it doesn't. It assumes, correctly, that that involves a bunch of extra work and that obfuscation raises the economic cost of an attack.
- tracker1 12y ago
  Really!?! An attacker can just as easily write a script to check the password recovery form before attacking the login form. You're taking something that is easy to automate and using it as a solution that makes it harder for people to use. How many times have you been to a site you haven't used in a while to try several different passwords, only to hit the password reset form and discover the username wasn't even correct? How many minutes of your time were wasted? How much security was actually added? The answers are... Yes. Too much. None.
  - raverbashing 12y ago
    A lot of places have a captcha in their sign up process. Also signing up usually involves more than a login/password (address, phone no., etc) Yeah, someone could do something like "you'll get an email if this email wasn't registered already" on sign up
    - masklinn 12y ago
      > Also signing up usually involves more than a login/password (address, phone no., etc) No. Using some features may involve more than a login/password, but even on most ecommerce site the signup itself is just a login and a password. Amazon needs a name (whatever), an email and a password. That's it.
    - tracker1 12y ago
      You could put a captcha on your login screen once a user from an IP has failed more than N logins on a given IP address. You could also check for the existance of a cookie, and not allow logins that don't have it set. There's lots of things you could do.. but displaying an obtuse error doesn't add to usability. I was talking about the password recovery screen, not the signing up. The "you'll get an email..." is a message I've seen.. and had to deal with it being broken (the email provider the site used was overloaded/down) .. no email.. more broken usability...
mlrtime 12y ago
It is very annoying that visiting a site that you know you have an account on but cannot remember your username. The rate limiting feature seems to solve most of the issues with giving the user a chance at some feedback.
- tokenizerrr 12y ago
  They should allow login by email instead of username
darrhiggs 12y ago
The article misses the point that on many sites this is not a security feature, more a privacy one. I have used the 403 http status rather than 401 in the past for this exact reason. RFC 7231[0] suggests something similar "An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found)." with RFC 7235[1] suggesting the use of 403. "A server that receives valid credentials that are not adequate to gain access ought to respond with the 403 (Forbidden) status code […]." [0] https://tools.ietf.org/html/rfc7231#section-6.5.3 https://tools.ietf.org/html/rfc7231#section-6.5.3 [1] https://tools.ietf.org/html/rfc7235 https://tools.ietf.org/html/rfc7235
- masklinn 12y ago
  As the article notes, you can trivially get around that "privacy feature" by trying to sign up with the email. If it lets you sign up there was nobody there, if it does not the email is being used by somebody else. Most sites will reject you immediately if the email is already in the system. > RFC 7231[0] suggests something similar Well no, RFC 7231 suggests that rather than telling an authenticated user he does not have access to a resource you can tell him the resource does not exist at all. It has nothing to do with the authentication itself, and certainly isn't suggested (let alone recommended) as a response to an invalid authentication attempt. > valid credentials that are not adequate to gain access How does a clear statement that the user's credentials are valid but don't give access to a resource have any relation with the rest of your comment?
  - Spooky23 12y ago
    If it matters, you can make it non-trivial. As with most privacy attacks, you can target an individual pretty easily. But, if you're trolling for lots of users, the "new account" feature will have a much lower operational tempo than the authentication workflow, and for a privacy conscious organization, you can do things to make it harder for attackers. Examples: Captcha, data input validation, risk scoring, don't provide immediate confirmation, etc. Revealing that the email address is a valid system account isn't a particularly useful piece of information to a user who isn't remembering a password. john.smith100000@gmail.com is probably taken by another John Smith. It just isn't a useful piece of information.
androidb 12y ago
I agree with the article, furthermore here's another interesting reading from Mailchimp, as they reduced their failed logins by 70% telling users if the username or password was wrong: https://blog.mailchimp.com/social-login-buttons-arent-worth-it/ https://blog.mailchimp.com/social-login-buttons-arent-worth-...
mbesto 12y ago
> 99.9% of websites on the Internet will only let you create one account for each email address. So if you want to see if an email address has an account, try signing up for a new account with the same email address. That's terrible UX. > But there's a tradeoff there between security and UX, I hear you say. I am trying to show you there is no tradeoff; you are choosing between a better user experience and a worse user experience. I didn't reach this conclusion at all. Am I missing something?
- andrewstuart2 12y ago
  > That's terrible UX. I think the goal when the User is a malicious attacker is for them to have a terrible UX.
  - mbesto 12y ago
    Huh? He's suggesting that as a Real User that if you don't whether you have an account at all is to just sign up again. People use multiple emails for different accounts all of the time. How is that not a frustrating experience for the Real User?
    - waxjar 12y ago
      That's not what is meant. An attacker who wants to find out of if the person with "example@example.com" has on account on your website, could try signing up with "example@example.com". If they get an error message, they know the person has an account on the website.
- saidajigumi 12y ago
  > That's terrible UX. Your complaint is extremely unclear. Could you elaborate? Are you suggesting that websites should allow multiple accounts per email address as a matter of course?
  - mbesto 12y ago
    No, my point is that signing up for a service (potentially) for a second time is a really frustrating experience. Why not push the user to reset their password?
tetrep 12y ago
>99.9% of websites on the Internet will only let you create one account for each email address. So if you want to see if an email address has an account, try signing up for a new account with the same email address. While this is true, it's perfectly reasonable to require a captcha before allowing a new account to be created; greatly limiting the speed at which an attacker could enumerate emails. While it's not going to stop targeted attacks, it will mitigate mass brute forcing of weak passwords. Regardless of the ease of username enumeration, all of the author's points about what to do are great for most sites. Rate limiting with exponential backoff and 2fa are some of the cheapest and most effective means of increasing the security of your app's authentication process.
- baddox 12y ago
  But requiring a captcha before validating the uniqueness of each username would be pretty annoying for large websites where many of the usernames I would choose are already taken.
  - csallen 12y ago
    Which doesn't matter, because there's no point in keeping usernames secret (and thus no point providing a captcha) unless those usernames are email addresses, in which case it's unlikely that the username you want will be taken.
    - baddox 12y ago
      Strictly speaking, keeping the existence of usernames secret does make brute forcing username/password combinations more difficult.
      - tracker1 12y ago
        Only if the returned error code timing for a bad username overalps bad password most of the time. Displaying an obscured error only serves to harm the real users and is of little benefit to the system. Unless you delay all failed attempts to login by a random time of 500-2000 ms, it's unlikely you'll see much improvement in response rates... having such a random delay is probably helpful anyhow.
Lamba 12y ago
I agree with Kevin Burke's post. And I had designed my POC this way well before I read his post. https://lamba-todos.herokuapp.com/ https://lamba-todos.herokuapp.com/
allendoerfer 12y ago
The article does not point out, that not teling visitors which of password and username were wrong on login pages is a useless measure, it shows that there is a second way to find out correct registered email addresses on most platforms (by trying to register them). This can be easily fixed by sending email conformation tokens prior to creating the user account and informing users in this email, in case they already have an account.
andrewstuart2 12y ago
I think the real lesson here is that if emails should remain secret you should not indicate upon signup whether or not a user exists with that email. Always send an email. If that user already exists, make sure the email says "We noticed you're trying to sign up again. If you didn't do this, someone else is trying to sign up for you." If that user doesn't exist, send them the typical signup message. The author has some great security tips in the "what should I do instead" but I don't think the instead portion is accurate. Keep private information private, and make access to public information as easy as it should be. If emails are public, shoot, use a websocket connection to style the login field in real time and show the user whether or not the email they typed is valid.
- slg 12y ago
  Security is all about trade-offs. Sending emails puts a bigger barrier between signup and first sign in. It is probably a better business move to slightly inconvenience some existing customers rather than slightly inconvenience all potential new customers.
  - andrewstuart2 12y ago
    What I'm saying is that every "signup" event should appear as if it was a valid, brand-new signup as far as the web user is concerned. The email will be sent regardless. If it's a valid new signup, then the user gets a transparent experience. If the user has already signed up, send them a helpful "hey, you've already signed up" message in their inbox. In case it was an attacker, maybe check the IP against known IPs that have had valid logins. If it's a new IP, add a section to the email message that a potential attacker may be trying to login and that no action is required, etc. Whatever fits your business case.
    - xanderjanz 12y ago
      You're ignoring that most modern apps will give you rudimentary account access even before you confirm your email address. Which would be difficult to do if that account already exists.
itsdrewmiller 12y ago
This is a good point for sites where the user can sign up on their own - doesn't necessarily apply to, say, banking sites, where you need to have an actual account to create an online one.
Someone1234 12y ago
> Consider throttling invalid login attempts by IP address or subnet. Oh hell no. First off that is completely ineffective. Botnets are common and inexpensive. But worse still a lot of users often share a single IP (e.g. university dorms, businesses, public wifi, etc). I agree with the first part of this article (i.e. that it is trivial to "prove" a username is valid, and that worse error responses aren't accomplishing anything). But that advice is poor. > Check submitted passwords against a dictionary of common passwords (123456, monkey, etc) and ban that traffic extra hard. That seems like a lot of engineering work. Plus the workload of loading up a dictionary and doing a lookup upon each login is resources that frankly could be better used on a slower hashing algorithm (to slow logins and make stored hashes stronger). > Exponential backoff (forcing attackers to try again after 1, 2, 4, 8, 16.. seconds) is useful as well. Just open a spreadsheet and determine how long it would take to test 1500 passwords. 1500 is a "short" dictionary of common passwords. Even a 1 minute delay after each 2 attempts (or 2 minutes after 4, or 4 minutes after 8, etc) means 12.5 hours of attempts. I like to set the attempts really high with an equally high lockout. So no normal user will see it. Most users do a password reset after the fourth or fifth attempt, so if you set it on 8 attempts with a 4-6 minute lockout then the majority of users will never run into it. Instead of focusing on these kind of hacks why not just: - Set no maximum password length (250+ characters) - Set the minimum to at least 6 or 7 - Get a password score widget (e.g. "weak" "normal" "secure"), traffic light, to encourage better behaviour - When a password is set check it isn't in a common password dictionary (a lot of score widgets integrate this!) - You can use Javascript to check a password dictionary as it isn't a site-security feature, and anyone who goes out of their way to bypass it only has themselves to blame. - Agreed on 2F, Google Authenticator is trivial to integrate. The only remotely "hard" bit is generating the QR code and a lot of libraries exist for that express purpose. - No clue how you'd integrate LastPass... - Account Alerts are extremely useful. As are admin alerts. Too many sites get no warning when a lockout occurs, it is pathetic.
- deleted 12y ago
  [deleted]
- TheLoneWolfling 12y ago
  Exponential backoffs also have the problem that it makes it far easier to lock someone out of their account. Or rather, it makes it possible to lock someone out of their account for an arbitrary amount of time. > When a password is set check it isn't in a common password dictionary I agree with this with short passwords. But for passphrases? No. I find it rather frustrating that (ex) diceware passwords are often rejected as too insecure or flagged with a nasty warning.
volkangurel 12y ago
It's only useless if the website reveals the username elsewhere, but that doesn't have to be the case. Consider the case when the primary usernames are always emails (many sites do this), and signing up for an account is simply done with entering an email and a password. Then, when someone submits a signup form, the website can: - Check if an account with the email exists, and if it does, whether the given password matches the existing one. - If both are valid, log the user in, optionally showing a message saying “there was already an account with these credentials so we logged you in” - If an account with the email does not exist, or if it exists and the password doesn’t match, return a message to the user saying “please check your email and follow the validation link”. The user can’t tell if the email exists or not. In the backend: - If the account did exist, send an email to the user saying “someone tried to sign up for an account with your email, please let us know if it was you. and here’s a way to reset your password if you forgot it”. - If the account did not exist, send an email verification link, which then redirects to a page to complete the user signup Same with password resets, the success message can always say "check your email". There are ways around revealing the username. But I agree, only doing this in the login page is useless.
- TheLoneWolfling 12y ago
  That will cost you dearly in terms of user retention.
  - volkangurel 12y ago
    If you have to validate email addresses, which I believe you do, what I suggested doesn't add any more steps so I doubt it would cost anything. To the contrary, given that the initial user signup is so simple (just an email and password), users will be much more likely to complete it compared to other signup forms that require more data. Once they are logged in and on your site, you can gamify whatever portions of the profile you need filled, that is, if you need any more data (most sites like hackernews don't).
    - volkangurel 12y ago
      Actually I'm wrong about hackernews, you'd need a username, but still, you can choose that after you sign up, and you shouldn't be able to log in with that username, that should only be a public handle for your account on forums, comments, etc.
kylequest 12y ago
Silly rant... It would be more useful to explore why a service/site would like to 'hide' user names... and how it should be done. If a site/service needs to hide user names then it needs to do a better job with signups. It's possible to hide user names / emails during signups too and say: "if you already have an account you'll get a reset password link otherwise welcome message from us".
wfunction 12y ago
I'd always wondered why no one seemed to notice this. I guess someone finally has.
thethrows 12y ago
It's adding a few extra letters to a printed string and makes it slightly more obscure for attackers. Hardly a security measure, but it would be dumb not to do it. Can we move on and not argue about what a stupid error string should be? This is fucking ridiculous.
Evolved 12y ago
I'd be concerned that if hackers found out their login attempts were increasingly rate-limited (2 seconds, 4 seconds, 8 seconds, etc.) then they would just use that instead as a DoS attack and run that rate limit up to weeks or months if possible. Send email to email address on file stating "someone has attempted to log in to your account multiple times..." only after multiple unsuccessful attempts. What about a flat rate-limit of something like 30 seconds (or something similar) which is low enough that a user likely wouldn't be that irritated by it, won't be a severe DoS and is likely sufficient enough to hinder illegitimate login attempts?
atakan_gurkan 12y ago
The concerns about the denial of service attack, if an exponentially rising delay or similar lockout after a certain amount of login attempts are made, can be simply addressed by emailing an "unlock" email to the registered email address if a lockout takes place. That is, lock the account for 1/2 hours if there are a number of failed logins, but at the same time send an email that will allow logging in, by passing the lockout. Would this be a big security gap?
jluxenberg 12y ago
I don't know if it's still the case, but for a long time at Amazon your account identifier was a combination of your email address and password. So you could have two accounts with the same email address and different passwords. Needless to say, this caused some confusion for users.
- wiml 12y ago
  Wouldn't that also make it impossible to change one's password?
MAGZine 12y ago
I don't agree with the author's premise wrt to usernames. Often, you will login with a username, but the password recovery form will only accept an email. You might be able to correlate these two if you have a lot of data from other, external attacks, but unless if I noticed correlation between recovered passwords and account break-ins, I wouldn't worry about this. There's a security tradeoff, but sometimes security must be risked in the name of functionality, or you'll have a lame product. Or, you can have both security and functionality, but to the detriment of UX. Take leaderboards for example. If you have a leaderboard for your app/game, you'll expose user's username (and thus, sign-in name, as is often the case). You could mitigate this by: having a separate login name (ala steam), or using an email (which exposes people to the recovery exploit), but it doesn't make the UX any better. In the end, I'd say trying to protect against username/email guessing attacks is probably unnecessary. There are better ways to approach security.
drinchev 12y ago
I think this idea might blow a lot of A/B testing and conversion rates. People would have to check their e-mail address for actually creating their accounts, although e-mails are already obsolete for even activating the account ( You can just sign-up and sign-in later with your password you entered ). May be behind this the author put some good deeds, but in the end I think it's overkill.
codazoda 12y ago
I was convinced until the main suggestion was to, "Consider throttling invalid login attempts by IP address or subnet." The rest sounded okay but that seems to indicate that the author probably hasn't tried to solve the security problem on a busy site.
userbinator 12y ago
How about just changing the signup process to "send us an email from your email address" and then you receive a reply with the further instructions/link? It would make it impossible to discover whether a user has signed up without gaining access to his/her email account. You could easily make this more abuse-resistant (and reduce the inevitable spam) by generating a temporary session ID and embedding it into the subject of the mailto: link, or even use temporary email addresses to receive registrtion requests.
ColinDabritz 12y ago
Interesting premise. I think the original behavior is partly correct. The combination of user name and password doesn't match. Either one could be incorrect. Say my usual login is steven@example.com, and I do know my password. If I try to log in as stevon@example.com with my correct password, it is conceptually NOT the password that is incorrect. The user could legitimately make such typos, and should probably check both fields. On the other hand, this is a reasonable argument for prompting on invalid user names, e.g. "This doesn't appear to be an existing account, make sure you typed it correctly, or try our [sign up page]".
largote 12y ago
What sites should really say, is what dumb "password restrictions" they forced you to use on signup. For example sites should have a message that says: "We are dumb enough to force your password to have at least one Uppercase/Lowercase/Number/Symbol and it must be at least 8 characters long, but you can't have consecutive numbers, this may make it different from your usual password pattern and force you to recover the password every goddam time you try to use our site".
rdl 12y ago
Thinking this is only about security is shortsighted, IMO. There are cases of typo-ing the email address, or entering a non-standard email address, which happens to match another. ryan@gmail.com -> ryan@gmaail.com probably would have some benefit to UX in saying "email address does not exist", but ryan@gmail.com vs. ryanl@gmail.com both exist. What I'd probably recommend instead, if you do decide confirming account creation status makes sense, is judging by cookie or IP. If 10.10.10.10 has previously logged in as ryanb@gmail.com, and I enter ryan@gmail.com instead, it might make sense to poke on the email; if I enter ryanb@gmail.com and have an incorrect password, maybe suggest bad password. (of course, if you have a cookie, you might as well pre-fill the login; if you have an IP match, probably not). The security tradeoff here exists but isn't huge. There are definitely cases where the user benefit (and thus reduced bounce rate) of suggesting error in username or password would make sense. The biggest security issue is confirming "does this account exist at all?", because email addresses tend to uniquely identify users, and you need some other mechanism to prevent this -- either automated (captcha would work) or targeted (in which case it's quite hard). I'm actually in favor of per-action security checking vs. "logged in or logged out, all or nothing".
xborns 12y ago
As many have said if you simply rate-limit with captcha and block it complicates checking against all emails via bots etc. This rule doesn't apply well to say the majority of b2b systems that don't have account creations public. Thus now I can phish for users and send them targeted oh reset your password here emails because I harvested them from some other hack. Remember it is not always the password that is the weak link it is the user as well. So calling it useless is shortsighted, yeah for many basic sites it is simple to say yeah tell them what is wrong. That is why they created the picture login to go with the email to ensure you are logging in on the right site. If anything you aren't sure try forgot password with your email. Source: Real experience building auth systems for large corps.
ademarre 12y ago
This problem is often referred to as user enumeration, which seems like a misnomer to me. Whatever you call it, it's good to keep in mind that Google, Apple, Facebook, and Twitter are vulnerable. The most interesting facet to user enumeration is privacy. If Alice knows Bob's e-mail address, is it right that she can easily check with Carol's web system to see if Bob has an account with Carol? This is like calling a hotel and asking if a certain person is staying there. It leaks information confirming that two parties have a relationship. What makes the privacy aspect especially interesting is that user enumeration is a bigger problem for small websites than for the Googles and Facebooks. This is because it's not much of a privacy breach to be able to test if a given e-mail address is on Facebook; big whoop, almost everyone is. But it's a much bigger breach to be able to test if a person is a customer of an illicit service. Most systems sit somewhere between those two extremes, and each needs to decide whether to prevent user enumeration. The main point the author tries to make is quite matter-of-fact: If you are going to try to prevent user enumeration, then you have to do it for real, which usually results in less friendly account creation and password recovery systems.
shittyanalogy 12y ago
It's not a security measure it's the truth. One or more of them is invalid, it's up to the user to decide what they meant to input.
Sami_Lehtinen 12y ago
Alternate view, I hate sites which require login & password, especially to only view content. I try to ignore every such site, because those are designed really badly. As well as I don't get it what's the correllation between email and registration. I don't want to give my email, nor I want to register. If I need to give email, I can give any random temporary email. Signup procedures on many sites are horrible. Best sites do allow at least accessing content without these hindrances. Logging in, especially on mobile, is painful anyway. Using some kind of federated login is privacy issue (in most cases), so it doesn't solve anything either. For lulz, how about just PGP signing nonce? They can verify it against my public key. PGP also allows me to easily create as many parallel identifies with strong authentication as I want to.
lazyant 12y ago
If I remember correctly, revealing if an email address is already in the system is considered information disclosure vulnerability in OWASP tests, presumably because then you can do spear phishing against that email using the information that is subscribed to the service.
cpfohl 12y ago
My applications can't be "signed up" for, you have to be manually added to get access because it protects sensitive information. In my case and all others like it, at least, this is not useless.

413 points by kevinburke 12y ago

Indeed, the assumption that usernames should be secret is stupid and senseless. Passwords are meant to be secret. Emails and usernames are not. Heck, emails would be public, were it not for spam issues.

NoPiece 12y ago
There are privacy issues though. Take a known email address, run it through 100 sites, and find to find out what kind of sites the person uses.
- btilly 12y ago
  The point of the article is that you already can do this very easily - just try to sign up to each site.
  - Dylan16807 12y ago
    Which is an easily fixed flaw, when it comes to emails. Usernames, yeah, you're not going to keep those private. But sometimes account names are not the same as display names, and display names can be duplicates, while account names should be reasonably protected.
  - NoPiece 12y ago
    That's sometimes true, but not always. Two examples: a signup may have a captcha, so the cost of filling out the form to check for an email address is high, or something like a bank sign up, which requires additional info besides the email address (account number, SSN).
  - Akkuma 12y ago
    Gmail allows you to use email+whatever. A lot of sites actually support this and this means it becomes significantly harder to determine what sites you use as each email+whatever is considered unique.
objectobject 12y ago
Whether the username is sensitive depends a lot on context. If the service is a dating site, gambling, porn, etc. just disclosing someone is a user of the site breaches their privacy. What this really highlights is a lack of consistency. If adding a security measure involves some kind of trade-off (UX in this case), you should really understand what you are trying to prevent and consider the rest of the attack surface. I think it would be a fallacy to immediately give up just because a larger vulnerability exists though. I was curious to see whether there is a way round this and a quick search threw up https://security.stackexchange.com/questions/40694/disclose-to-user-if-account-exists https://security.stackexchange.com/questions/40694/disclose-... - the top answer is quite informative.

tacostakohashi 12y ago

Leaving security aside, "incorrect username/password" is still the more correct and useful statement. Consider the case where you mistype your username (email). For sites like amazon, gmail, hotmail, yahoo, twitter, etc, it is entirely likely that the mistyped username is somebody else's valid username, you typed the password correctly, and "incorrect password" would hide the problem.

Houshalter 12y ago
Well you can at least inform the user that the username is incorrect if there is no user by that name.
- Coding_Cat 12y ago
  You would still have the issues described in the OP. If it says "username incorrect" only when that user does not exist, you can still figure out a username by just trying them with a random password. If you get told "password incorrect" you know the username you just tried already exists.
  - Houshalter 12y ago
    Why is that an issue? You can also do that by trying to create accounts.
rrrx3 12y ago
That statement doesn't help the user fix a problem. Either you tell the user that one of the items is incorrect - "This password does not match our records" or "This user name does not match our records". Simply stating "Incorrect username/password" isn't sufficient enough information to prevent the user from making the same error (or even a different one) again. Here's what I tell the developers I work with: Design for the users, not for development ease. This pattern has been successfully implemented by literally hundreds (thousands? hundreds of thousands?) of websites, so there's no excuse for trying to cut a corner and try to concatenate use cases. Either the user name is right and the password is wrong, or the user name is wrong and the password doesn't matter, or both are wrong and through some miracle of absolute unicorn user error they've managed to log in to someone else's account - at which point you have a different issue altogether.

0xffff2 12y ago

Even simpler than trying to sign up for a new account, many sites will tell you if you enter an unregistered email on their "forgot password" page.

rcthompson 12y ago
Yes, but that also alerts any valid account with an unexpected password reset.
jdmichal 12y ago
Except that entering a registered email will likely result in the legitimate user receiving a password reset email that they did not request, thus immediately raising suspicions that someone may be attempting to access their account. Using the signup form is a much better approach.
fmx 12y ago
Some sites don't. They instead say "if an account with that email address exists we've sent you an email with the reset link". That seems like a nice touch, but it's pointless if you can still find out that a given email address is a registered user in some other way (such as by trying to sign up with it). So it's just another variant of the "invalid username/password" message.

cryptoz 12y ago

This doesn't address timing attacks, which are why this is done in the first place. If the code checks only for a username existing and returns the error message, this takes a measurably different amount of time compared to then also looking up if the password matches. The error shown isn't to dissuade people from using web pages to try to gain access to accounts - it's because the raw code itself doesn't know which is which, and writing code that does enables fast-paced timing attacks.

Dylan16807 12y ago
> This doesn't address timing attacks, which are why this is done in the first place. I don't follow. Surely the reason to hide usernames is not to prevent a timing attack that would reveal... usernames.
- thisGuysAccount 12y ago
  I might be missing what you're not following, but here's a quick explanation (and a reason why it's not a concern) Correct username, correct password: takes 30ms to execute the code Correct username, incorrect password: takes 15 ms to execute the code Incorrect username: Takes 7 ms to execute the code. You fuzz usernames, you get one that takes 15 ms, you know that's a valid username. You then start working the password. Not necessary on most systems, because we're working at speeds that are measured in nanoseconds, and since we're using networks for many attacks, the delays are unpredictable and measured in (at least) milliseconds.
  - Dylan16807 12y ago
    I understand how the timing attack works. I don't understand how it's a justification for hiding usernames. "You need to try to hide A because if you're not careful they can find A." If anything the timing attacks weaken the argument against hiding usernames.
westi 12y ago
> This doesn't address timing attacks, which are why this is done in the first place. If the code checks only for a username existing and returns the error message, this takes a measurably different amount of time compared to then also looking up if the password matches. Timing attacks are solved by how you implement the backend checking code and not how you present the result to the end user in the most user friendly manner.

matthijs_ 12y ago

Excellent point. However, I think username / password will be (at least partially) replaced by this: https://passwordless.net/ https://passwordless.net/ - Token based authentication

Benferhat 12y ago
If I'm not logged into a site a that I regularly use, I'm probably not logged into my email, either. In order to log into my favorite site with Passwordless, I have to log into my email as well. With my password. One login for the price of two, and I'm still using a password.

why-el 12y ago

None of the author's recommendations conflict with the practice he is advocating against. I think websites say "Bad combination" not because usernames are treated equally with passwords, but because you don't have a choice but say that. If I tell you that your username is incorrect, am I telling you your password isn't? This would be silly, because if the website is new and I know a password is correct, then I can either find the username out there (if the website is social), or pretend I forgot my username and have them give it to me. Assuming that's not what I am saying, then the user is surely to have a bad experience anyway, since they will need to figure out a wrong username, and then in the worst case, a wrong password. When you say a "bad combination" you at least eliminate a possibility to mislead them into thinking only one of their credentials is wrong.

tracker1 12y ago
If the username is wrong, and you don't tell them, they will spend several tries on passwords that will never work.. because the user is invalid. I have a number of sites I don't use often, that I wind up having to do a password reset on to then find out I'm not even using the right username... there was literally no gain from this... Any hacking attempt can do the same to determine if a username was valid or not. It's making things easy for machines to do harder for people to do, which is the wrong approach to security.
spion 12y ago
"Sorry, we don't have a <name> in our database" isn't misleading. If the user enters an incorrect password too, the subsequent message "Invalid password for <name>" will let them correct it.
- why-el 12y ago
  Perhaps misleading was the wrong word, but as you said it yourself, saying that would lead to a user experience that is much worse than a simple "Bad experience", which is exactly my point.
masklinn 12y ago
> I think websites say "Bad combination" not because usernames are treated equally with passwords, but because you don't have a choice but say that. Of course you do. > If I tell you that your username is incorrect, am I telling you your password isn't? This would be silly Of course it is, a password is checked against a username, not against the whole database. If the site is telling you the username is incorrect it's telling you just that: the username is incorrect. It wasn't able to go any further and check the password since it has no idea which password it should check for (or even, if you're correctly storing passwords, which salt it should use for the password check). Your criticism doesn't even make sense.

anigbrowl 12y ago

Unfortunately this assumes that there's no other way for an attacker to discover whether a username/email address is registered for a service. This assumption is incorrect. No it doesn't. It assumes, correctly, that that involves a bunch of extra work and that obfuscation raises the economic cost of an attack.

tracker1 12y ago
Really!?! An attacker can just as easily write a script to check the password recovery form before attacking the login form. You're taking something that is easy to automate and using it as a solution that makes it harder for people to use. How many times have you been to a site you haven't used in a while to try several different passwords, only to hit the password reset form and discover the username wasn't even correct? How many minutes of your time were wasted? How much security was actually added? The answers are... Yes. Too much. None.
- raverbashing 12y ago
  A lot of places have a captcha in their sign up process. Also signing up usually involves more than a login/password (address, phone no., etc) Yeah, someone could do something like "you'll get an email if this email wasn't registered already" on sign up
  - masklinn 12y ago
    > Also signing up usually involves more than a login/password (address, phone no., etc) No. Using some features may involve more than a login/password, but even on most ecommerce site the signup itself is just a login and a password. Amazon needs a name (whatever), an email and a password. That's it.
  - tracker1 12y ago
    You could put a captcha on your login screen once a user from an IP has failed more than N logins on a given IP address. You could also check for the existance of a cookie, and not allow logins that don't have it set. There's lots of things you could do.. but displaying an obtuse error doesn't add to usability. I was talking about the password recovery screen, not the signing up. The "you'll get an email..." is a message I've seen.. and had to deal with it being broken (the email provider the site used was overloaded/down) .. no email.. more broken usability...

mlrtime 12y ago

It is very annoying that visiting a site that you know you have an account on but cannot remember your username. The rate limiting feature seems to solve most of the issues with giving the user a chance at some feedback.

tokenizerrr 12y ago
They should allow login by email instead of username

darrhiggs 12y ago

The article misses the point that on many sites this is not a security feature, more a privacy one. I have used the 403 http status rather than 401 in the past for this exact reason. RFC 7231[0] suggests something similar "An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found)." with RFC 7235[1] suggesting the use of 403. "A server that receives valid credentials that are not adequate to gain access ought to respond with the 403 (Forbidden) status code […]." [0] https://tools.ietf.org/html/rfc7231#section-6.5.3 https://tools.ietf.org/html/rfc7231#section-6.5.3 [1] https://tools.ietf.org/html/rfc7235 https://tools.ietf.org/html/rfc7235

masklinn 12y ago
As the article notes, you can trivially get around that "privacy feature" by trying to sign up with the email. If it lets you sign up there was nobody there, if it does not the email is being used by somebody else. Most sites will reject you immediately if the email is already in the system. > RFC 7231[0] suggests something similar Well no, RFC 7231 suggests that rather than telling an authenticated user he does not have access to a resource you can tell him the resource does not exist at all. It has nothing to do with the authentication itself, and certainly isn't suggested (let alone recommended) as a response to an invalid authentication attempt. > valid credentials that are not adequate to gain access How does a clear statement that the user's credentials are valid but don't give access to a resource have any relation with the rest of your comment?
- Spooky23 12y ago
  If it matters, you can make it non-trivial. As with most privacy attacks, you can target an individual pretty easily. But, if you're trolling for lots of users, the "new account" feature will have a much lower operational tempo than the authentication workflow, and for a privacy conscious organization, you can do things to make it harder for attackers. Examples: Captcha, data input validation, risk scoring, don't provide immediate confirmation, etc. Revealing that the email address is a valid system account isn't a particularly useful piece of information to a user who isn't remembering a password. john.smith100000@gmail.com is probably taken by another John Smith. It just isn't a useful piece of information.

androidb 12y ago

I agree with the article, furthermore here's another interesting reading from Mailchimp, as they reduced their failed logins by 70% telling users if the username or password was wrong: https://blog.mailchimp.com/social-login-buttons-arent-worth-it/ https://blog.mailchimp.com/social-login-buttons-arent-worth-...

mbesto 12y ago

> 99.9% of websites on the Internet will only let you create one account for each email address. So if you want to see if an email address has an account, try signing up for a new account with the same email address. That's terrible UX. > But there's a tradeoff there between security and UX, I hear you say. I am trying to show you there is no tradeoff; you are choosing between a better user experience and a worse user experience. I didn't reach this conclusion at all. Am I missing something?

andrewstuart2 12y ago
> That's terrible UX. I think the goal when the User is a malicious attacker is for them to have a terrible UX.
- mbesto 12y ago
  Huh? He's suggesting that as a Real User that if you don't whether you have an account at all is to just sign up again. People use multiple emails for different accounts all of the time. How is that not a frustrating experience for the Real User?
  - waxjar 12y ago
    That's not what is meant. An attacker who wants to find out of if the person with "example@example.com" has on account on your website, could try signing up with "example@example.com". If they get an error message, they know the person has an account on the website.
saidajigumi 12y ago
> That's terrible UX. Your complaint is extremely unclear. Could you elaborate? Are you suggesting that websites should allow multiple accounts per email address as a matter of course?
- mbesto 12y ago
  No, my point is that signing up for a service (potentially) for a second time is a really frustrating experience. Why not push the user to reset their password?

tetrep 12y ago

>99.9% of websites on the Internet will only let you create one account for each email address. So if you want to see if an email address has an account, try signing up for a new account with the same email address. While this is true, it's perfectly reasonable to require a captcha before allowing a new account to be created; greatly limiting the speed at which an attacker could enumerate emails. While it's not going to stop targeted attacks, it will mitigate mass brute forcing of weak passwords. Regardless of the ease of username enumeration, all of the author's points about what to do are great for most sites. Rate limiting with exponential backoff and 2fa are some of the cheapest and most effective means of increasing the security of your app's authentication process.

baddox 12y ago
But requiring a captcha before validating the uniqueness of each username would be pretty annoying for large websites where many of the usernames I would choose are already taken.
- csallen 12y ago
  Which doesn't matter, because there's no point in keeping usernames secret (and thus no point providing a captcha) unless those usernames are email addresses, in which case it's unlikely that the username you want will be taken.
  - baddox 12y ago
    Strictly speaking, keeping the existence of usernames secret does make brute forcing username/password combinations more difficult.
    - tracker1 12y ago
      Only if the returned error code timing for a bad username overalps bad password most of the time. Displaying an obscured error only serves to harm the real users and is of little benefit to the system. Unless you delay all failed attempts to login by a random time of 500-2000 ms, it's unlikely you'll see much improvement in response rates... having such a random delay is probably helpful anyhow.

Lamba 12y ago

I agree with Kevin Burke's post. And I had designed my POC this way well before I read his post. https://lamba-todos.herokuapp.com/ https://lamba-todos.herokuapp.com/

allendoerfer 12y ago

The article does not point out, that not teling visitors which of password and username were wrong on login pages is a useless measure, it shows that there is a second way to find out correct registered email addresses on most platforms (by trying to register them). This can be easily fixed by sending email conformation tokens prior to creating the user account and informing users in this email, in case they already have an account.

andrewstuart2 12y ago

I think the real lesson here is that if emails should remain secret you should not indicate upon signup whether or not a user exists with that email. Always send an email. If that user already exists, make sure the email says "We noticed you're trying to sign up again. If you didn't do this, someone else is trying to sign up for you." If that user doesn't exist, send them the typical signup message. The author has some great security tips in the "what should I do instead" but I don't think the instead portion is accurate. Keep private information private, and make access to public information as easy as it should be. If emails are public, shoot, use a websocket connection to style the login field in real time and show the user whether or not the email they typed is valid.

slg 12y ago
Security is all about trade-offs. Sending emails puts a bigger barrier between signup and first sign in. It is probably a better business move to slightly inconvenience some existing customers rather than slightly inconvenience all potential new customers.
- andrewstuart2 12y ago
  What I'm saying is that every "signup" event should appear as if it was a valid, brand-new signup as far as the web user is concerned. The email will be sent regardless. If it's a valid new signup, then the user gets a transparent experience. If the user has already signed up, send them a helpful "hey, you've already signed up" message in their inbox. In case it was an attacker, maybe check the IP against known IPs that have had valid logins. If it's a new IP, add a section to the email message that a potential attacker may be trying to login and that no action is required, etc. Whatever fits your business case.
  - xanderjanz 12y ago
    You're ignoring that most modern apps will give you rudimentary account access even before you confirm your email address. Which would be difficult to do if that account already exists.

itsdrewmiller 12y ago

This is a good point for sites where the user can sign up on their own - doesn't necessarily apply to, say, banking sites, where you need to have an actual account to create an online one.

Someone1234 12y ago

> Consider throttling invalid login attempts by IP address or subnet. Oh hell no. First off that is completely ineffective. Botnets are common and inexpensive. But worse still a lot of users often share a single IP (e.g. university dorms, businesses, public wifi, etc). I agree with the first part of this article (i.e. that it is trivial to "prove" a username is valid, and that worse error responses aren't accomplishing anything). But that advice is poor. > Check submitted passwords against a dictionary of common passwords (123456, monkey, etc) and ban that traffic extra hard. That seems like a lot of engineering work. Plus the workload of loading up a dictionary and doing a lookup upon each login is resources that frankly could be better used on a slower hashing algorithm (to slow logins and make stored hashes stronger). > Exponential backoff (forcing attackers to try again after 1, 2, 4, 8, 16.. seconds) is useful as well. Just open a spreadsheet and determine how long it would take to test 1500 passwords. 1500 is a "short" dictionary of common passwords. Even a 1 minute delay after each 2 attempts (or 2 minutes after 4, or 4 minutes after 8, etc) means 12.5 hours of attempts. I like to set the attempts really high with an equally high lockout. So no normal user will see it. Most users do a password reset after the fourth or fifth attempt, so if you set it on 8 attempts with a 4-6 minute lockout then the majority of users will never run into it. Instead of focusing on these kind of hacks why not just: - Set no maximum password length (250+ characters) - Set the minimum to at least 6 or 7 - Get a password score widget (e.g. "weak" "normal" "secure"), traffic light, to encourage better behaviour - When a password is set check it isn't in a common password dictionary (a lot of score widgets integrate this!) - You can use Javascript to check a password dictionary as it isn't a site-security feature, and anyone who goes out of their way to bypass it only has themselves to blame. - Agreed on 2F, Google Authenticator is trivial to integrate. The only remotely "hard" bit is generating the QR code and a lot of libraries exist for that express purpose. - No clue how you'd integrate LastPass... - Account Alerts are extremely useful. As are admin alerts. Too many sites get no warning when a lockout occurs, it is pathetic.

deleted 12y ago
[deleted]
TheLoneWolfling 12y ago
Exponential backoffs also have the problem that it makes it far easier to lock someone out of their account. Or rather, it makes it possible to lock someone out of their account for an arbitrary amount of time. > When a password is set check it isn't in a common password dictionary I agree with this with short passwords. But for passphrases? No. I find it rather frustrating that (ex) diceware passwords are often rejected as too insecure or flagged with a nasty warning.

volkangurel 12y ago

It's only useless if the website reveals the username elsewhere, but that doesn't have to be the case. Consider the case when the primary usernames are always emails (many sites do this), and signing up for an account is simply done with entering an email and a password. Then, when someone submits a signup form, the website can: - Check if an account with the email exists, and if it does, whether the given password matches the existing one. - If both are valid, log the user in, optionally showing a message saying “there was already an account with these credentials so we logged you in” - If an account with the email does not exist, or if it exists and the password doesn’t match, return a message to the user saying “please check your email and follow the validation link”. The user can’t tell if the email exists or not. In the backend: - If the account did exist, send an email to the user saying “someone tried to sign up for an account with your email, please let us know if it was you. and here’s a way to reset your password if you forgot it”. - If the account did not exist, send an email verification link, which then redirects to a page to complete the user signup Same with password resets, the success message can always say "check your email". There are ways around revealing the username. But I agree, only doing this in the login page is useless.

TheLoneWolfling 12y ago
That will cost you dearly in terms of user retention.
- volkangurel 12y ago
  If you have to validate email addresses, which I believe you do, what I suggested doesn't add any more steps so I doubt it would cost anything. To the contrary, given that the initial user signup is so simple (just an email and password), users will be much more likely to complete it compared to other signup forms that require more data. Once they are logged in and on your site, you can gamify whatever portions of the profile you need filled, that is, if you need any more data (most sites like hackernews don't).
  - volkangurel 12y ago
    Actually I'm wrong about hackernews, you'd need a username, but still, you can choose that after you sign up, and you shouldn't be able to log in with that username, that should only be a public handle for your account on forums, comments, etc.

kylequest 12y ago

Silly rant... It would be more useful to explore why a service/site would like to 'hide' user names... and how it should be done. If a site/service needs to hide user names then it needs to do a better job with signups. It's possible to hide user names / emails during signups too and say: "if you already have an account you'll get a reset password link otherwise welcome message from us".

wfunction 12y ago

I'd always wondered why no one seemed to notice this. I guess someone finally has.

thethrows 12y ago

It's adding a few extra letters to a printed string and makes it slightly more obscure for attackers. Hardly a security measure, but it would be dumb not to do it. Can we move on and not argue about what a stupid error string should be? This is fucking ridiculous.

Evolved 12y ago

I'd be concerned that if hackers found out their login attempts were increasingly rate-limited (2 seconds, 4 seconds, 8 seconds, etc.) then they would just use that instead as a DoS attack and run that rate limit up to weeks or months if possible. Send email to email address on file stating "someone has attempted to log in to your account multiple times..." only after multiple unsuccessful attempts. What about a flat rate-limit of something like 30 seconds (or something similar) which is low enough that a user likely wouldn't be that irritated by it, won't be a severe DoS and is likely sufficient enough to hinder illegitimate login attempts?

atakan_gurkan 12y ago

The concerns about the denial of service attack, if an exponentially rising delay or similar lockout after a certain amount of login attempts are made, can be simply addressed by emailing an "unlock" email to the registered email address if a lockout takes place. That is, lock the account for 1/2 hours if there are a number of failed logins, but at the same time send an email that will allow logging in, by passing the lockout. Would this be a big security gap?

jluxenberg 12y ago

I don't know if it's still the case, but for a long time at Amazon your account identifier was a combination of your email address and password. So you could have two accounts with the same email address and different passwords. Needless to say, this caused some confusion for users.

wiml 12y ago
Wouldn't that also make it impossible to change one's password?

MAGZine 12y ago

I don't agree with the author's premise wrt to usernames. Often, you will login with a username, but the password recovery form will only accept an email. You might be able to correlate these two if you have a lot of data from other, external attacks, but unless if I noticed correlation between recovered passwords and account break-ins, I wouldn't worry about this. There's a security tradeoff, but sometimes security must be risked in the name of functionality, or you'll have a lame product. Or, you can have both security and functionality, but to the detriment of UX. Take leaderboards for example. If you have a leaderboard for your app/game, you'll expose user's username (and thus, sign-in name, as is often the case). You could mitigate this by: having a separate login name (ala steam), or using an email (which exposes people to the recovery exploit), but it doesn't make the UX any better. In the end, I'd say trying to protect against username/email guessing attacks is probably unnecessary. There are better ways to approach security.

drinchev 12y ago

I think this idea might blow a lot of A/B testing and conversion rates. People would have to check their e-mail address for actually creating their accounts, although e-mails are already obsolete for even activating the account ( You can just sign-up and sign-in later with your password you entered ). May be behind this the author put some good deeds, but in the end I think it's overkill.

codazoda 12y ago

I was convinced until the main suggestion was to, "Consider throttling invalid login attempts by IP address or subnet." The rest sounded okay but that seems to indicate that the author probably hasn't tried to solve the security problem on a busy site.

userbinator 12y ago

How about just changing the signup process to "send us an email from your email address" and then you receive a reply with the further instructions/link? It would make it impossible to discover whether a user has signed up without gaining access to his/her email account. You could easily make this more abuse-resistant (and reduce the inevitable spam) by generating a temporary session ID and embedding it into the subject of the mailto: link, or even use temporary email addresses to receive registrtion requests.

ColinDabritz 12y ago

Interesting premise. I think the original behavior is partly correct. The combination of user name and password doesn't match. Either one could be incorrect. Say my usual login is steven@example.com, and I do know my password. If I try to log in as stevon@example.com with my correct password, it is conceptually NOT the password that is incorrect. The user could legitimately make such typos, and should probably check both fields. On the other hand, this is a reasonable argument for prompting on invalid user names, e.g. "This doesn't appear to be an existing account, make sure you typed it correctly, or try our [sign up page]".

largote 12y ago

What sites should really say, is what dumb "password restrictions" they forced you to use on signup. For example sites should have a message that says: "We are dumb enough to force your password to have at least one Uppercase/Lowercase/Number/Symbol and it must be at least 8 characters long, but you can't have consecutive numbers, this may make it different from your usual password pattern and force you to recover the password every goddam time you try to use our site".

rdl 12y ago

Thinking this is only about security is shortsighted, IMO. There are cases of typo-ing the email address, or entering a non-standard email address, which happens to match another. ryan@gmail.com -> ryan@gmaail.com probably would have some benefit to UX in saying "email address does not exist", but ryan@gmail.com vs. ryanl@gmail.com both exist. What I'd probably recommend instead, if you do decide confirming account creation status makes sense, is judging by cookie or IP. If 10.10.10.10 has previously logged in as ryanb@gmail.com, and I enter ryan@gmail.com instead, it might make sense to poke on the email; if I enter ryanb@gmail.com and have an incorrect password, maybe suggest bad password. (of course, if you have a cookie, you might as well pre-fill the login; if you have an IP match, probably not). The security tradeoff here exists but isn't huge. There are definitely cases where the user benefit (and thus reduced bounce rate) of suggesting error in username or password would make sense. The biggest security issue is confirming "does this account exist at all?", because email addresses tend to uniquely identify users, and you need some other mechanism to prevent this -- either automated (captcha would work) or targeted (in which case it's quite hard). I'm actually in favor of per-action security checking vs. "logged in or logged out, all or nothing".

xborns 12y ago

As many have said if you simply rate-limit with captcha and block it complicates checking against all emails via bots etc. This rule doesn't apply well to say the majority of b2b systems that don't have account creations public. Thus now I can phish for users and send them targeted oh reset your password here emails because I harvested them from some other hack. Remember it is not always the password that is the weak link it is the user as well. So calling it useless is shortsighted, yeah for many basic sites it is simple to say yeah tell them what is wrong. That is why they created the picture login to go with the email to ensure you are logging in on the right site. If anything you aren't sure try forgot password with your email. Source: Real experience building auth systems for large corps.

ademarre 12y ago

This problem is often referred to as user enumeration, which seems like a misnomer to me. Whatever you call it, it's good to keep in mind that Google, Apple, Facebook, and Twitter are vulnerable. The most interesting facet to user enumeration is privacy. If Alice knows Bob's e-mail address, is it right that she can easily check with Carol's web system to see if Bob has an account with Carol? This is like calling a hotel and asking if a certain person is staying there. It leaks information confirming that two parties have a relationship. What makes the privacy aspect especially interesting is that user enumeration is a bigger problem for small websites than for the Googles and Facebooks. This is because it's not much of a privacy breach to be able to test if a given e-mail address is on Facebook; big whoop, almost everyone is. But it's a much bigger breach to be able to test if a person is a customer of an illicit service. Most systems sit somewhere between those two extremes, and each needs to decide whether to prevent user enumeration. The main point the author tries to make is quite matter-of-fact: If you are going to try to prevent user enumeration, then you have to do it for real, which usually results in less friendly account creation and password recovery systems.

shittyanalogy 12y ago

It's not a security measure it's the truth. One or more of them is invalid, it's up to the user to decide what they meant to input.

Sami_Lehtinen 12y ago

Alternate view, I hate sites which require login & password, especially to only view content. I try to ignore every such site, because those are designed really badly. As well as I don't get it what's the correllation between email and registration. I don't want to give my email, nor I want to register. If I need to give email, I can give any random temporary email. Signup procedures on many sites are horrible. Best sites do allow at least accessing content without these hindrances. Logging in, especially on mobile, is painful anyway. Using some kind of federated login is privacy issue (in most cases), so it doesn't solve anything either. For lulz, how about just PGP signing nonce? They can verify it against my public key. PGP also allows me to easily create as many parallel identifies with strong authentication as I want to.

lazyant 12y ago

If I remember correctly, revealing if an email address is already in the system is considered information disclosure vulnerability in OWASP tests, presumably because then you can do spear phishing against that email using the information that is subscribed to the service.

cpfohl 12y ago

My applications can't be "signed up" for, you have to be manually added to get access because it protects sensitive information. In my case and all others like it, at least, this is not useless.