22 ms·

“Invalid Username or Password”: a useless security measure (2014)

313 points by prmph 4y ago

ericalexander0 4y ago
I've worked in infosec for over 15 years. I've built security programs from the ground up at two companies. I've learned much of compliance/security is cargo culting and/or streetlight effect, if not radicalized. You can debate the standards, just like you can debate with your retired uncle who watches way too much fox news. The better solution is to find good enough solutions that let infosec teams check their boxes and move on to more important work.
t43562 4y ago
Does it matter given that browsers can remember the username/password anyhow? On the other hand it's probably more important for user experience to encourage secure (long) memorable passwords rather than the fashion of impossible-to-remember short random ones. i.e I understand that something like "Iamafunnysailorwithalittlereddog" is better than "4kbjk5rv!" simply because length makes any password much harder to crack than the variety of each character.
- geocar 4y ago
  > Does it matter given that browsers can remember the username/password anyhow? No. The only thing that matters is having two public APIs: one that creates an account (failing if the account already exists), and another that checks if the password matches the username for an existing account. If you have those two APIs then there's no benefit to the second refusing to elaborate on whether the login is wrong or the password is wrong, and it might be useful to users. However I'm not convinced. For many applications I think a better solution is to merge password-recovery with sign-up: Ask for the email/phone number, then send them an email to confirm which logs them in at the same time. That link, then creates the account if it doesn't exist. This way, no information is leaked, and you don't waste resources creating accounts that never get used. If you want a fully knowledge-based authentication system, you won't have password recovery, but you might not need usernames at all: I have an app like that, it uses webauthn/client certs/a couple other tricks to authenticate devices, and has one UI function to "log in on another machine" (by taking or displaying a QR code), a separate UI function to "share this view with another user" which creates the user (or selects an existing one that this user created), and a third function to add an existing user (using a meetme code). It only matters what users call each other, not that there are two (or more) geocar's in the system, and so the login API in this system doesn't need to differentiate between an invalid or expired code, nor can it reveal the existence of any internal account IDs because the client never actually sees them anyway. HN is a social space though, and in this case the username represents some kind of land reservation, so it is important to know if land is taken before claiming it, and it's in this scenario I think I can agree that the login API should tell you if the username is wrong or if it's the password. But I don't think Amazon or Shoprunner more should be like HN even if I usually like it here.
- mod 4y ago
  Length doesn't make it harder to crack, entropy does. Length is a good way to add entropy if the characters are not predictable. "Ava234ncqli3h23rn2f" is a lot stronger than "Ava234ncqli3" "DonaldTrump" is barely stronger than "Donald" Hopefully that makes sense.
  - Sohcahtoa82 4y ago
    > "DonaldTrump" is barely stronger than "Donald" I mean, this is only true if you know your target is a raging Trump supporter. Obviously, that's a very cherry-picked example, but generally, length IS entropy, even if the characters are somewhat predictable when seen by a human, as long as you have no reason to predict the password based on the things the person likes. To give another example, "Inmyyoungerandmorevulnerableyears" is going to be an insecure password despite its length if your entire personality revolves around how much you like The Great Gatsy. On the other hand, something based on random words like "defaultsocksillegalinstalledconnections" is going to be VERY secure, despite how readable it is, because it's still gibberish and is long.
fefe23 4y ago
Oh boy. This is actually a good point. I guess having the nondescript error message has always been "best practices" or maybe it has crossed the road and has become cargo cult now.
- BeefWellington 4y ago
  Not really. The points the author makes are only valid if you presuppose they are correct in that "account e-mails for a site are already public elsewhere", and that isn't a problem on its own. Many best practices are already what the author suggests: If a user signs up and doesn't already exist, send them an e-mail to confirm they own the e-mail. If that user already has an account, send their e-mail a message to the effect of "Someone tried to sign up to our service as you, is this you? If not, it's safe to ignore this message. Here's how to reset your password in case you lost that: ..." The thing the author is missing here is the same failure I see at a lot of companies: they take the approach that they're only there to protect their application, rather than doing what they can to protect the users of the application. Something as simple as knowing a user uses a service can become an easy spearphishing attack, for example, which the author doesn't mention. The general recommendations are good but defense in depth is key.
- croes 4y ago
  How do you know the user typed the wrong password and didn't mistype his user name that happens to be someone else's user name?
joosters 4y ago
But the error message can be true. If you mistype your username, you might have entered another, existing username. Just telling the user 'wrong password' will mean they are less likely to check that the username was correct. The website doesn't always know which one you got wrong, and assuming one way or the other just makes things worse.
- comprev 4y ago
  - kuschku 4y ago
    Again, how is that leakage, if you can just try registering a new account and see if that username or email already exists?
    - duxup 4y ago
      Do most people who are throwing usernames and passwords at websites ... do that?
      - michaelt 4y ago
        If they could benefit from the 'information leakage' of knowing a username exists, they would do. If they don't - then maybe this 'information leakage' worry is obsolete security advice. There's loads of obsolete security advice around. (of course there might be other, non-account-security-related reasons to make it impossible to know if an account exists. It's one thing if HN's login form reveals that user duxup exists, it's another if find-an-affair-partner.com reveals the same thing)
        duxup 4y ago
        >There's loads of obsolete security advice around. Yeah that's kinda what I'm wondering about. It's possible that most of your security issues are just folks credential stuffing in the simplest way, if that's the case then the whole registration thing isn't really a realistic concern. Hell when I was in networking and if you did your best to just block traffic to / from specific regions / nations ... you eliminated a huge % of malicious traffic. For the guy thinking deeply about security that seems odd / not specific enough, but in the real world it works...
martius 4y ago
There is also the question of leaking whether a given user has an account on a website or not. Maybe I don't want my employer to know that I have an account on competitor-service.com, or my partner to know that I have an account on kinky-thing.website. It might not be a security issue, but it could be a privacy issue.
- sabellito 4y ago
  The author explains in the article that you're not protected from that case either, as the attacker can try to sign up with your email and find out anyway if that email is already registered.
  - bombcar 4y ago
    He gives a solution for that and says it is "too cumbersome".
  - dschooh 4y ago
    Not necessarily. You can design the sign up process by way of always ending with a message that says you will be notified.
  - Xylakant 4y ago
    Many services let you sign up with an existing email and just send a “you tried to sign up, but you seem to have an address already.” to the account owner. In that case it’s indistinguishable for the attacker. Many services already require email confirmation to finalize the signup process so the extra effort is low.
    - wongarsu 4y ago
      And those services also plug the forgotten-password information leak by just informing you "if you have an account, you got an email" instead of giving you an explicit success or error message. I guess the better point for the article would be "many websites cargo-cult the login error message without understanding why it's there and how that should impact the rest of the service"
dubbel 4y ago
This is assuming that the service allows new users to sign up themselves. Also, testing it via signup sends a lot of emails to the victim (if the attacker tries a number of services), so the victim at least knows that something is up.
- allknowingfrog 4y ago
  That was my first thought as well. The application that I maintain is invitation-only, so I think the rest of the argument is irrelevant to me.
  - ohbtvz 4y ago
    I'm not sure what this brings to the conversation. I don't develop any web application, so the rest of the argument is also irrelevant for me. Should I broadcast that everywhere?
    - mjochim 4y ago
      It brings to our attention that there is a whole class of applications - "invite only" ones - where the main argument of the article does not apply. And therefore the conclusion ("The login user interface should distinguish bad user handle vs bad password") does not apply either. The article just mentions "99.9% of all websites" somewhere near the beginning, and that number may be way too high. I would in fact be interested in an analysis of how many web sites do and don't follow recommendations like "do NOT distinguish bad user handle vs bad password", which are widely considered best practices. I wouldnt take a guess, could be anywhere between 10 and 90 percent.
switch007 4y ago
Another reason to use unique email addresses for each service is that it’s almost impossible for someone to discover if you’ve already signed up
sgjohnson 4y ago
I'd say it's wrong to assume it's even a security measure. I'm fairly sure it goes like this if (db->query("SELECT * FROM `users` WHERE `email` = 'yesthisisdog@gmail.com' AND `password` = MD5('hunter2')") { login(username); } else { error('invalid username or password'); } with nobody giving it a second thought.
- MHard 4y ago
  Which in itself would be a bad security practice because that would mean that the passwords aren't individually salted.
  - sgjohnson 4y ago
    And they would be hashed using MD5! But on a serious note, it's possible to individually salt passwords, and still match username & password in one query.
- capableweb 4y ago
  As someone who written countless of this authentication mechanisms or led teams that have, there has been 0 times the vague message have been by accident like you described and 100% on purpose to prevent information leakage. But that's just one (20+) anecdote(s).
- datalopers 4y ago
  > MD5(‘****’) That’s cool HN censors passwords like this
- Sohcahtoa82 4y ago
  Everything about that query makes me cry.
  - sgjohnson 4y ago
    Thanks, I tried
justsomehnguy 4y ago
> Check submitted passwords against a dictionary of common passwords (123456, monkey, etc) and ban that traffic extra hard. > Give guidance to users about creating strong passwords Yeah, if I just want to talk about a propane with some folks I would eagerly wait to be lectured about IT security, scolded at my passwords of choice, go out of my way to appease site administrator's password policy...
- scarface74 4y ago
  Or with any modern password manager - including the one built into Apple devices - you could just click on “choose strong password” and have one generated for you and stored.
  - justsomehnguy 4y ago
    That works fine till you have the access to your password manager. If you ever find yourself without it... imagine your Apple device got broken/stolen. You would be fine wihtout an ability to talk on some forum, but what about critical banking, e-gov sites?
    - scarface74 4y ago
      My passwords are synced between all of my devices - iPad, iPhone, and Mac. Even if I lost all of my devices, I could walk into a store, buy a new device and log in and all of my passwords with be in sync.
      - boredemployee 4y ago
        In 3rd world countries that would be a whole different story...
        scarface74 4y ago
        Doesn’t Android also have a built in password manager that gets synced to Google servers?
tumetab1 4y ago
This might need (2014) in the title
- TheMaskedCoder 4y ago
  Agreed. OWASP now advises developers on how to avoid account enumeration, so this take no longer makes sense.
JoeAltmaier 4y ago
True but aren't username/password passe? Username should be 'account details' like mother's maiden name or zipcode, not a security feature. And short passwords you change a lot - what a weak system! How about provide a cryptographic key and that's it. It's right or it's wrong. Or heck, if it's not recognized then just create a new empty account.
bluenotebo0k 4y 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." Yes, but signing up is a more cumbersome process and usually has a CAPTCHA attached to it, unlike logging in.
- capableweb 4y ago
  > Yes, but signing up is a more cumbersome process and usually has a CAPTCHA attached to it, unlike logging in. My guess of what is most common is that the actual trying to create a user in the backend/database is protected by a captcha, but checking if the email/username already exists is a separate endpoint that the frontend hits while filling out the signup form, before trying to create the actual user. But it's just a guess, and I can already think of many examples where that doesn't happen, which is for good reasons.
  - Tainnor 4y ago
    > but checking if the email/username already exists is a separate endpoint that the frontend hits I'm sure this happens in some cases, but it's definitely not a good practice, would hopefully get flagged by any pentesting or security audit, and also, most people use some sort of framework for auth (devise for Rails, Spring Security for JVM, or similar) - and those usually don't work in that way.
- justsomehnguy 4y ago
  Yep. One site I infrequently visit moved from their own account system to the "check your email for a pass code". This just made me to visit and login even more infrequently.
- mod 4y ago
  Half the web has a CAPTCHA just to view content. Thanks, Cloudfare.
  - Sohcahtoa82 4y ago
baxtr 4y ago
> Here is an actual UX/security tradeoff: you can make the signup process email based. Great. Now I can’t share passwords any more with significant others. Instead I have to send them login credentials every time they want to login.
- capableweb 4y ago
  Automatic forwarding solves this problem for you :) Personally I have my email setup so everything mentioning Netflix/HBO/Disney/$streaming-service/$shared-service gets automatically forwarded to our family inbox that everyone in the household has access to, in case they need to reset the password or do something related to those services Edit: added "automatic" to "forwarding" as that's the vital piece here
  - baxtr 4y ago
    Forwarding assumes I am checking email every time they want to login. The auto-setup is a cool idea though.
    - capableweb 4y ago
      Of course I meant "automatic forwarding" rather than manually forwarding everything, missed to add that word there someone, corrected :)
- progval 4y ago
  The author only recommends doing this on signup, ie. registration. Not on login.
  - baxtr 4y ago
    Thanks. You’re right. Didn’t read carefully enough.
- yegle 4y ago
  Exactly! McDonald's (US app) is using a login system like this. Worse, they automatically log out all other logins once someone logs in on one device. Eventually I became the designated pickup person of my house.
tromp 4y ago
I'd prefer the error to be "invalid username" if the typed username is not registered, and "wrong username or password" if it is. The system only knows if the username is valid or not; it doesn't know whether it's wrong (i.e. mistyped).
- kahrl 4y ago
  I'd prefer to not create brute force vulnerability that leaks the site's list of user email addresses to an attacker.
  - tromp 4y ago
    As the article points out, this leaks it no more than trying to register an email address.
    - croes 4y ago
      Which can be prevented by sending an confirmation email at a signup, no matter if a new account or an existing one.
throwawaaarrgh 4y ago
If we can't manage to make password managers standard, we should try to make them required.
hairofadog 4y ago
On this topic, I've noticed a lot of sites have split their sign-in forms into a two step process (submit username, then submit password). Does anyone know what this achieves? It seems like it would be trivial for an automated script to submit the form twice, but as a human I often have to open 1Password multiple times to navigate the process. For example: https://myaccount.nytimes.com/auth/login https://myaccount.nytimes.com/auth/login
- d8c6c050cb0a4d7 4y ago
  This is useful when you have multiple methods to authenticate. Maybe this user should be redirected to an oauth2 identity provider or maybe they should enter a password. Good implementations of this will have a hidden password field for password managers to fill along with the username. You'll still need to press enter twice though.
- tpetry 4y ago
  This is for SSO reasons. When you enter your email address they check whether SSO is activated for your email address (or whole company domain) and will redirect you. It is better for usability than requiring your users to enter some random password or keep the password input empty.
- swhitf 4y ago
  Usually it is to detect the user is registered to (or their domain is mapped to) an account with SSO or Social Auth and prompt them for that login mechanism. If the user is being required to go via the SSO provider, it makes sense to ask for the email first before they input their password so that they can be redirected it neccesary.
- dexterdog 4y ago
  2-step signins are so annoying for those of us who don't use it. I imagine they are also annoying for people who use it because they still have to first type in their email address instead of just going to the google/fb/apple/etc page where they click on their identity.
codingdave 4y 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. Security is never perfect, it is always about making it annoying enough that people don't bother. So yes, there are other ways to see if someone has an account. But odds are the person attacking your site is not singling out one account to hack, they are trying bulk attacks with many accounts. So you avoid leaking info to not give the script any more ammo on what else to try. And hopefully the attacker will move on to some site that did give it more ammo.
- SamBam 4y ago
  > it is always about making it annoying enough that people don't bother. > But odds are the person attacking your site is not singling out one account to hack, they are trying bulk attacks with many accounts. I feel like these two statements are at odds with each other. A regular user is going to get annoyed. An attacker using a script and multiple attempts is simply going to include the other way of verifying if an address is real in the script.
- kgwxd 4y ago
  Maybe instead of saying the email address is already in use on the site, just let the "sign up" happen and tell them to check the email for a confirmation link, and in the confirmation email say "someone is attempting to sign up with this email that is already signed up, if this was you, use the Forgot Password link to reset the password for the existing account. If it was not, click here to report this incident."
kklisura 4y 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. So why not just send an email upon signup with existing email and just show success on signup? I'm guessing email would state that you already have an account there, maybe you need to reset password and email would provide instructions. Using this approach there would be no leakage of information and you can inform the user someone tried signing up with their email. Edit: This would work only if only email is required for signup, but it would not work with usernames.
- SamBam 4y ago
  The article suggests this. But also says you're going to make sign-up a lot more lossy because the context-switching may make some people give up.
- nerf3000 4y ago
  Or just allow multiple accounts to use the same email (with an upper limit) Already people can chuck a + in the user part and register with the same email like joe+2@gmail.com so really there's not much point trying to maintain a 1:1 user to email ratio.
  - mod 4y ago
    That's what I've always done, with an upper limit of 1. More seriously, this just kicks the can a little bit. "Already people can chuck a + in the user part...so really there's not much point trying to maintain a 25:1 user to email ratio"
drewcoo 4y 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. The assertion is incorrect. Closing a means to account name guessing does not presuppose that there are no other means available. Locking my front door does not assume I have no other doors.
est 4y ago
The best measure? Let any login pass, just generate a fake account if the credentials were wrong.
- TheMaskedCoder 4y ago
  That would make things waaaay more difficult for users. "Okay, I'm logged in, let me do something.... Now it says I don't have permission?? Did my account get deactivated??? What am I doing wrong????"
- mrmattyboy 4y ago
  Hah, I did this ages ago in notebook application that I wrote for myself.. Though the amount of times I went a long time between logging in, got the wrong credentials and got scared very quickly when all of my notes had vanished :P
- patrakov 4y ago
  The best measure? Ditch the password. It can be reset anyway, it can be stolen, it's just unnecessary complexity, it doesn't provide any security. You can prove ownership of the email? You can log in - worst case, after a password reset. So why have a password? email: ______________ [Log in] The "Log in" button results in a "Check your inbox and click the link in the email that we just sent you" page. Source: https://appear.in/ https://appear.in/ used this flow from the very beginning, before it was destroyed in a trademark dispute. EDIT: now it is https://whereby.com/user/login https://whereby.com/user/login
nerf3000 4y ago
I don't think saying "but these popular sites let you enumerate registered email addresses via this other form" is justification to be lax about protecting against user enumeration attacks on your own site. The actual take away should be more like "I found a security issue in the registration form of these popular sites, they should fix it" Enumerating valid emails, even if rate limited, lets an attacker build a contact book for targeted phishing attacks, connecting leaked passwords, brute forcing and is also useful in recon to determine what sites a person may have an account with, and more. It's worth protecting against as much as possible.
darrinmn 4y 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. This is not true if the signup flow is implemented correctly. Signing up for an account should always respond with the same message "we sent an email for you to confirm your account signup". The owner of that email address then receives an email - either 1) normal signup process, or 2) "did you just try to sign up? You already have a valid account for this email address." This way you cannot tell via the signup web form alone whether an account exists or not. You need to have access to the email address.
- emodendroket 4y ago
  That exact strategy is described in the second paragraph but the author argues (and I agree) that it is so arduous it will cause you to lose many users for questionable benefit.
  - darrinmn 4y ago
    Yes but the exact quote is confusing as he specifically mentions email addresses (in bold text). I know the author mentions usernames elsewhere in the article and I agree with the author this isn't applicable to websites that allow username signup since anyone can pick any random string... But for email address signup, as the exact quote mentions, there is no additional context switching since you already need to confirm the email address regardless.
    - emodendroket 4y ago
      Often you don’t need to confirm the e-mail address to complete whatever workflow you’re doing.
      - darrinmn 4y ago
        Sure, companies are free to make their own choices based on their business incentives. But if you can create an account and be logged in without verifying an email address, then arguably the email address wasn't needed in the first place and you should just allow any type of username string. If the goal of your website is for email address to be the username, the you should confirm the user actually owns the email address they claim first - since anyone could lie and put a random email they don't own.
andrelaszlo 4y ago
I don't get it. It's fine to leak/allow user enumeration on the login page because it's leaked elsewhere anyway? That's a pretty big assumption. One way to allow users to register using their email address without leaking any information is to just say "user created, please check your inbox to confirm your email address" or something like that. If the user already exists, swap the confirmation email for a warning email if they already have an account. Or am I missing something?
- deleted 4y ago
  [deleted]
- physicles 4y ago
  In a sense, yes. If you’re revealing an account’s existence on one page, your system isn’t made more secure if you hide its existence on another page. If you think it does, you’re fooling yourself. Better to use other tools (like rate limiting) to improve security. And yes, you’re missing the second part of the article where the author mentions the registration flow you describe and then points out that it’s not a great user experience.
jbj 4y 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 may explain why my gmail keeps getting signed up for obscure cypto services :(
rippercushions 4y ago
(2014)
yalogin 4y ago
A tangentially related question. I have, embarrassingly, not kept up with fido. What does it provide? I am guessing it provides a spec for a iOS keychain equivalent where passwords are stored in a dongle (or software) and “let out” based on user approval. I remember reading it also provides a new password-less auth mechanism. Is it out yet? If so is it adopted?
ad404b8a372f2b9 4y ago
I agree with the premise but the solution has UX issues of its own. Some users, like me, have learned to use the registration form as an account checker for their own email. I don't remember if I have an account on some websites, and if I do I don't remember with which email+password combo, and the password reset page doesn't tell whether the email is correct, and it often takes 10 minutes for them to send a reset email so I still don't know whether I'm registered with the email I entered and should just wait or not registered at all and no email was sent. So instead I just try to register and bam, instant answer. In addition to that, the context switch to emails increases friction significantly during registration. It's much easier for the user to be logged-in immediately and not have to check their email. That's not even taking into account the wasted time of having to re-enter all your info. Disclaimer: I know the first issue is solved with a password manager and a faster email service, that's not the point.
- thomastjeffery 4y ago
  You might not know if you have an account, and you might not remember your password. The solution to either problem is the same: send an email. So why not merge the two processes? Actually, any "forgot username/password" link effectively does this already. The only thing we need to do is make that more obvious. I think the easiest way would be to separate username creation from password creation. Just have a single sign-up prompt asking for an email address, and put the link to the password creation page into the sent email. Set the title/content of the email to clearly show whether an account exists already (with a password reset link) or doesn't (with a password/account creation link). If the user stops there (the account creation email answered their question: they don't have an account with this email), then you can simply expire the password-set link without ever creating the account.
  - ad404b8a372f2b9 4y ago
    It's not a solution to the problem I described, if it were the forgot password page would already solve it.
    - 4y ago
gumby 4y ago
Related question: what's the deal with having a login form that only takes a username, and then only shows a password field after you've pressed enter? I find this very annoying and can't come up with a benefit.
- kozziollek 4y ago
  If username is an e-mail then an app probably checks if e-mail domain has configured single sign on (SSO) and, if it has, it redirect you to your company authentication server instead of asking for password.
  - gumby 4y ago
    thanks
- danjc 4y ago
  SSO handoff as a sibling points out but also once email is known, a determination is made about trust level for the sign in attempt. Cookies, IP and other fingerprinting are used to determine whether single or double factor auth is required.
  - gumby 4y ago
    thanks.
whirlwin 4y ago
Not a UX'er. But speaking of UX - it is inherently very annoying to sign in with username/password in general. At least in 2022. 2014 was perhaps different.
danjc 4y ago
In 2022, building your own user signup/sign in flows is almost as bad as rolling your own crypto. Edit: a rebuttal is mightier than a downvote.
exabrial 4y ago
I used to think this as well. BUT, revealing _any_ information to attacker is a security problem. Take this scenario: Someone might not want their employer knowing they (legally) gamble online. The employer could simply browse to popular online gambling sites and probe the service with their email or username to see if an account exists.
deleted 4y ago
[deleted]
thomastjeffery 4y ago
Just reading the title, I expected OP to be talking about invalid passwords, i.e. when a password's text can't be used because it's too short/long or has/doesn't have specific characters. That's a discussion I would be much more interested in; mostly because I'm sick of seeing long passwords be completely broken. A better title for their post would be "incorrect", not "invalid".
dfxm12 4y ago
So what we've done by promoting "Invalid username or password" is made our login form UX much, much worse, without increasing the security of our product. Much, much worse? Not at all. It doesn't matter if you've forgotten your user name, email address or password; if you've forgotten your credentials, you reset your password, not keep guessing until you give up. The password reset will also clue you in as to if you've got the right email address.
mrmattyboy 4y ago
I'm not sure if someone has mentioned this already, but if someone has gone down the path to allow enumeration (username check during signup, which is immediately returned ton the user), I would say this is a strong argument where you could protect yourself against enumeration more easily.. The amount of times a user will likely type their username/password incorrectly is going to be a lot higher than those who attempt to re-signup for an account. Therefore adding additional protection to the signup page (hard rate limiting, bot-protection) then aids to stop this username/email enumeration without the need to be as strict on a login page. This is also compiled with ip-based rate limiting/bot protection that can get very frustrating for users within a corporation that have single public IPs for all their users.
MostlyInnocent 4y ago
The article makes a good point, were it not for security auditors (SAs). SA: You leak information and therefore violate policy by disclosing on the login form whether an account exists or not! Me: Yeah, but figuring out if an account exists is really simple anyway: just a query to a different endpoint... SA: NEVERMIND, MY LAD: disclosing account existence upon login violates BEST PRACTICES! Me: OK, yeah, whatever, we'll just change the error message to "something you may or not have entered may or may not be valid information, try again, or not" SA: cool beans! WE ARE NOW INDUSTRY LEADERS
- Terretta 4y ago
  Every well known credit card / credit data breach has been of a PCI-DSS compliant party. To any SAs reading this: you're not secure because you're compliant.
  - mcv 4y ago
    The big issue there is that they store credit card data at all. And of course that some simple public number is enough to authorise payment.
throwaway09223 4y ago
This is an extremely silly observation for HN, given that the usernames are published openly with every comment. My username is quite obviously "throwaway09223." There's no need to enumerate anything. Avoiding username enumeration is a reasonable goal for some sites in terms of hiding PII, but it is very obviously not a necessary security measure.
- crazygringo 4y ago
  The article is about usernames as email addresses. Not about handles. HN doesn't reveal people's e-mail addresses, unless they choose to put it in their bio.
zajio1am 4y ago
> 99.9% of websites on the Internet will only let you create one account for each email address. Is it common? That seems like useless and impractical limit. E.g. for e-shops, one would like to have separate accounts for personal purchases and for business/corporate purchases.
- wccrawford 4y ago
  Yes, it really is like 99.9% of websites. If you need multiple accounts, use multiple emails addresses, 1 each. You should keep your personal and corporate email separate anyhow.
- toast0 4y ago
  It's kind of weird when you can login to different accounts with the same username, which is typically the email address. I mean, amazon lets you do it, and I've had two accounts with the same email address and password there; but it's still pretty weird. IIRC, I had two accounts with different addresses and changed them into the same address. A lot of accounts don't let you change your email address at all, so they solve the problem that way.
emodendroket 4y ago
This is a bit like the “don’t write your passwords” stuff. It doesn’t matter how obvious the arguments against it are — the author of this piece is not the first to note the absurdity of this setup — it is engrained as “best practice” and you will be fighting an uphill battle as a heretic trying to do anything else. I’ve lost similar arguments for similar reasons.
deleted 4y ago
[deleted]
dang 4y ago
Discussed at the time: “Invalid username or password” is a useless security measure - https://news.ycombinator.com/item?id=8683003 https://news.ycombinator.com/item?id=8683003 - Dec 2014 (182 comments)
nibbleshifter 4y ago
If the signup or reset process enables user enumeration, we tend to ding you on that in audits the same way we ding you for enumeration via the login form. Captchas, timeouts and rate limits are all well and good, but given the attack tools (eg: SentryMBA, OpenBullet) used by the lowest common denominator solve for those (by using captcha API's and residential proxy networks)... Breaking user enumeration vectors becomes super useful.
hkopp 4y ago
The argumentation is faulty. Users cannot be enumerated using the login, but using the signup. The author then argues that they should add the user enumeration function to the login. This is similar to: The door is locked, but the window is open. And then consequently it makes no sense to close the door at all, as an attacker can sneak through the window. Instead, the window should be locked as well, i.e., it should be impossible to enumerate users with the signup function.
upofadown 4y ago
Usability always seems to lose to security. Then we complain that the users can't use the system. I have come to think that every decision of this sort should first be an attempt to increase usability. Security is ultimately about usability. They are not actually at odds. Too often there is no analysis done after a potential security issue is identified past directly resolving the issue. Rarely will there be an attempt to reevaluate the usability after the change.
AtNightWeCode 4y ago
Would not go as far as saying 99.9% does this. A third-party pentest company we use does not consider this a security issue. I am not sure. I think it is information leak. I think the idea is that at some scale Everybody has an account so it does not really matter.
janalsncm 4y ago
Is there a use case for passwords at all? Passwords have the downsides of being guessable and hackable, as well as forgotten. I’d like to avoid the “correct horse battery staple” malarkey if possible. In most cases, control of the account email is equivalent to control of the account because I can reset the password if I control the email. So it seems that magic links or OTPs are strictly better. Am I missing something?
- djaychela 4y ago
  I think you are, yes. These situations spring to mind, all of which make email OTP a worse solution imo: Shared account without both having access to email. Email OTP is more time and effort than entering a password. Email can be down. You may not have access to email for another reason (different device, etc).
bloomingeek 4y ago
What if Google won't let you have your gmail account back? I broke my cellphone, so I went to the same carrier and purchased another Samsung, same phone number, but different model. So when I go to log into my Google account with the new cell, Google sends me a two way code, But to the old cellphone! After days of trying to get into my account, I finally have to create a new account and email address. (yes, I know NOW there are ways to create a safety backup.) The phrase, "Invalid Username or Password" started showing up in my dreams.
deleted 4y ago
[deleted]
mcv 4y ago
One of the comments there says: > Heh, after an independent security review we are being forced to take this even further; We lock people out for five minutes after three invalid login attempts. We are no longer allowed to tell users they have been locked out. So, even if they do remember their password (or even does a reset) we just have to tell them their uid/pwd is wrong when they try to log in. And for “forgot password”? Just tell the user “we have sent you an email – IF we recognised the email you put in”. This sounds absolutely horrible, and now I'm wondering if I've been subject to this behaviour. Couldn't remember my password (for a trivial site where I use one of my reuse passwords and didn't put it in KeePass), started doubting if I had the correct email, eventually reset the whole thing, reset the password to the password that I thought it should have been, and got an error telling me the new password couldn't be the same as the old one.
- shantnutiwari 4y ago
  I felt this with LastPass. It put in some secret locked mode, and wouldnt let me login even wit h right password. 3-4 hours later, it just started working. I was a paying customer, didnt get any replies to my emails. It pissed me off so much I moved to 1Password AND Bitwarden -- 2 in parallel, so if anyone pulls this on me again I can immedietely move to the other
lakomen 4y ago
First of all, Fuck 2FA! 2FA = companies fishing for phone numbers to identify and track you. This post is from 2014. Meanwhile I suggested that an any login attempt you would receive an email, you don't have to know your password to the service. Effectively Microsoft is the only company doing it like this. You don't need a password, every time you log in you can opt to have a login link sent to your email address instead of using a password. That IMHO makes sense. And I'd go one step further. Anytime anyone tries to use your service, don't ask a password, just ask for their email address. The most detrimental or annoying part of a sign up process is picking a password and worse, some stupid services demand you repeat your email or password. Let the user sign up effortlessly. I won't even start about how awful captcha is. If you use a JS form and means of sign up or login you don't need captcha.
gamzer 4y ago
If the goal is to log in new users immediately after registration, is it possible to not leak whether a username is already registered? If hn@example.com is not registered and I register it, I will be logged in (even if it does not belong to me). If hn@example.com is already registered, the site can neither let me register it nor log me in.

313 points by prmph 4y ago

I've worked in infosec for over 15 years. I've built security programs from the ground up at two companies. I've learned much of compliance/security is cargo culting and/or streetlight effect, if not radicalized. You can debate the standards, just like you can debate with your retired uncle who watches way too much fox news. The better solution is to find good enough solutions that let infosec teams check their boxes and move on to more important work.

t43562 4y ago

Does it matter given that browsers can remember the username/password anyhow? On the other hand it's probably more important for user experience to encourage secure (long) memorable passwords rather than the fashion of impossible-to-remember short random ones. i.e I understand that something like "Iamafunnysailorwithalittlereddog" is better than "4kbjk5rv!" simply because length makes any password much harder to crack than the variety of each character.

geocar 4y ago
> Does it matter given that browsers can remember the username/password anyhow? No. The only thing that matters is having two public APIs: one that creates an account (failing if the account already exists), and another that checks if the password matches the username for an existing account. If you have those two APIs then there's no benefit to the second refusing to elaborate on whether the login is wrong or the password is wrong, and it might be useful to users. However I'm not convinced. For many applications I think a better solution is to merge password-recovery with sign-up: Ask for the email/phone number, then send them an email to confirm which logs them in at the same time. That link, then creates the account if it doesn't exist. This way, no information is leaked, and you don't waste resources creating accounts that never get used. If you want a fully knowledge-based authentication system, you won't have password recovery, but you might not need usernames at all: I have an app like that, it uses webauthn/client certs/a couple other tricks to authenticate devices, and has one UI function to "log in on another machine" (by taking or displaying a QR code), a separate UI function to "share this view with another user" which creates the user (or selects an existing one that this user created), and a third function to add an existing user (using a meetme code). It only matters what users call each other, not that there are two (or more) geocar's in the system, and so the login API in this system doesn't need to differentiate between an invalid or expired code, nor can it reveal the existence of any internal account IDs because the client never actually sees them anyway. HN is a social space though, and in this case the username represents some kind of land reservation, so it is important to know if land is taken before claiming it, and it's in this scenario I think I can agree that the login API should tell you if the username is wrong or if it's the password. But I don't think Amazon or Shoprunner more should be like HN even if I usually like it here.
mod 4y ago
Length doesn't make it harder to crack, entropy does. Length is a good way to add entropy if the characters are not predictable. "Ava234ncqli3h23rn2f" is a lot stronger than "Ava234ncqli3" "DonaldTrump" is barely stronger than "Donald" Hopefully that makes sense.
- Sohcahtoa82 4y ago
  > "DonaldTrump" is barely stronger than "Donald" I mean, this is only true if you know your target is a raging Trump supporter. Obviously, that's a very cherry-picked example, but generally, length IS entropy, even if the characters are somewhat predictable when seen by a human, as long as you have no reason to predict the password based on the things the person likes. To give another example, "Inmyyoungerandmorevulnerableyears" is going to be an insecure password despite its length if your entire personality revolves around how much you like The Great Gatsy. On the other hand, something based on random words like "defaultsocksillegalinstalledconnections" is going to be VERY secure, despite how readable it is, because it's still gibberish and is long.

fefe23 4y ago

Oh boy. This is actually a good point. I guess having the nondescript error message has always been "best practices" or maybe it has crossed the road and has become cargo cult now.

BeefWellington 4y ago
Not really. The points the author makes are only valid if you presuppose they are correct in that "account e-mails for a site are already public elsewhere", and that isn't a problem on its own. Many best practices are already what the author suggests: If a user signs up and doesn't already exist, send them an e-mail to confirm they own the e-mail. If that user already has an account, send their e-mail a message to the effect of "Someone tried to sign up to our service as you, is this you? If not, it's safe to ignore this message. Here's how to reset your password in case you lost that: ..." The thing the author is missing here is the same failure I see at a lot of companies: they take the approach that they're only there to protect their application, rather than doing what they can to protect the users of the application. Something as simple as knowing a user uses a service can become an easy spearphishing attack, for example, which the author doesn't mention. The general recommendations are good but defense in depth is key.
croes 4y ago
How do you know the user typed the wrong password and didn't mistype his user name that happens to be someone else's user name?

joosters 4y ago

But the error message can be true. If you mistype your username, you might have entered another, existing username. Just telling the user 'wrong password' will mean they are less likely to check that the username was correct. The website doesn't always know which one you got wrong, and assuming one way or the other just makes things worse.

comprev 4y ago
- kuschku 4y ago
  Again, how is that leakage, if you can just try registering a new account and see if that username or email already exists?
  - duxup 4y ago
    Do most people who are throwing usernames and passwords at websites ... do that?
    - michaelt 4y ago
      If they could benefit from the 'information leakage' of knowing a username exists, they would do. If they don't - then maybe this 'information leakage' worry is obsolete security advice. There's loads of obsolete security advice around. (of course there might be other, non-account-security-related reasons to make it impossible to know if an account exists. It's one thing if HN's login form reveals that user duxup exists, it's another if find-an-affair-partner.com reveals the same thing)
      - duxup 4y ago
        >There's loads of obsolete security advice around. Yeah that's kinda what I'm wondering about. It's possible that most of your security issues are just folks credential stuffing in the simplest way, if that's the case then the whole registration thing isn't really a realistic concern. Hell when I was in networking and if you did your best to just block traffic to / from specific regions / nations ... you eliminated a huge % of malicious traffic. For the guy thinking deeply about security that seems odd / not specific enough, but in the real world it works...

martius 4y ago

There is also the question of leaking whether a given user has an account on a website or not. Maybe I don't want my employer to know that I have an account on competitor-service.com, or my partner to know that I have an account on kinky-thing.website. It might not be a security issue, but it could be a privacy issue.

sabellito 4y ago
The author explains in the article that you're not protected from that case either, as the attacker can try to sign up with your email and find out anyway if that email is already registered.
- bombcar 4y ago
  He gives a solution for that and says it is "too cumbersome".
- dschooh 4y ago
  Not necessarily. You can design the sign up process by way of always ending with a message that says you will be notified.
- Xylakant 4y ago
  Many services let you sign up with an existing email and just send a “you tried to sign up, but you seem to have an address already.” to the account owner. In that case it’s indistinguishable for the attacker. Many services already require email confirmation to finalize the signup process so the extra effort is low.
  - wongarsu 4y ago
    And those services also plug the forgotten-password information leak by just informing you "if you have an account, you got an email" instead of giving you an explicit success or error message. I guess the better point for the article would be "many websites cargo-cult the login error message without understanding why it's there and how that should impact the rest of the service"

dubbel 4y ago

This is assuming that the service allows new users to sign up themselves. Also, testing it via signup sends a lot of emails to the victim (if the attacker tries a number of services), so the victim at least knows that something is up.

allknowingfrog 4y ago
That was my first thought as well. The application that I maintain is invitation-only, so I think the rest of the argument is irrelevant to me.
- ohbtvz 4y ago
  I'm not sure what this brings to the conversation. I don't develop any web application, so the rest of the argument is also irrelevant for me. Should I broadcast that everywhere?
  - mjochim 4y ago
    It brings to our attention that there is a whole class of applications - "invite only" ones - where the main argument of the article does not apply. And therefore the conclusion ("The login user interface should distinguish bad user handle vs bad password") does not apply either. The article just mentions "99.9% of all websites" somewhere near the beginning, and that number may be way too high. I would in fact be interested in an analysis of how many web sites do and don't follow recommendations like "do NOT distinguish bad user handle vs bad password", which are widely considered best practices. I wouldnt take a guess, could be anywhere between 10 and 90 percent.

switch007 4y ago

Another reason to use unique email addresses for each service is that it’s almost impossible for someone to discover if you’ve already signed up

sgjohnson 4y ago

I'd say it's wrong to assume it's even a security measure. I'm fairly sure it goes like this if (db->query("SELECT * FROM `users` WHERE `email` = 'yesthisisdog@gmail.com' AND `password` = MD5('hunter2')") { login(username); } else { error('invalid username or password'); } with nobody giving it a second thought.

MHard 4y ago
Which in itself would be a bad security practice because that would mean that the passwords aren't individually salted.
- sgjohnson 4y ago
  And they would be hashed using MD5! But on a serious note, it's possible to individually salt passwords, and still match username & password in one query.
capableweb 4y ago
As someone who written countless of this authentication mechanisms or led teams that have, there has been 0 times the vague message have been by accident like you described and 100% on purpose to prevent information leakage. But that's just one (20+) anecdote(s).
datalopers 4y ago
> MD5(‘****’) That’s cool HN censors passwords like this
Sohcahtoa82 4y ago
Everything about that query makes me cry.
- sgjohnson 4y ago
  Thanks, I tried

justsomehnguy 4y ago

> Check submitted passwords against a dictionary of common passwords (123456, monkey, etc) and ban that traffic extra hard. > Give guidance to users about creating strong passwords Yeah, if I just want to talk about a propane with some folks I would eagerly wait to be lectured about IT security, scolded at my passwords of choice, go out of my way to appease site administrator's password policy...

scarface74 4y ago
Or with any modern password manager - including the one built into Apple devices - you could just click on “choose strong password” and have one generated for you and stored.
- justsomehnguy 4y ago
  That works fine till you have the access to your password manager. If you ever find yourself without it... imagine your Apple device got broken/stolen. You would be fine wihtout an ability to talk on some forum, but what about critical banking, e-gov sites?
  - scarface74 4y ago
    My passwords are synced between all of my devices - iPad, iPhone, and Mac. Even if I lost all of my devices, I could walk into a store, buy a new device and log in and all of my passwords with be in sync.
    - boredemployee 4y ago
      In 3rd world countries that would be a whole different story...
      - scarface74 4y ago
        Doesn’t Android also have a built in password manager that gets synced to Google servers?

tumetab1 4y ago

This might need (2014) in the title

TheMaskedCoder 4y ago
Agreed. OWASP now advises developers on how to avoid account enumeration, so this take no longer makes sense.

JoeAltmaier 4y ago

True but aren't username/password passe? Username should be 'account details' like mother's maiden name or zipcode, not a security feature. And short passwords you change a lot - what a weak system! How about provide a cryptographic key and that's it. It's right or it's wrong. Or heck, if it's not recognized then just create a new empty account.

bluenotebo0k 4y 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." Yes, but signing up is a more cumbersome process and usually has a CAPTCHA attached to it, unlike logging in.

capableweb 4y ago
> Yes, but signing up is a more cumbersome process and usually has a CAPTCHA attached to it, unlike logging in. My guess of what is most common is that the actual trying to create a user in the backend/database is protected by a captcha, but checking if the email/username already exists is a separate endpoint that the frontend hits while filling out the signup form, before trying to create the actual user. But it's just a guess, and I can already think of many examples where that doesn't happen, which is for good reasons.
- Tainnor 4y ago
  > but checking if the email/username already exists is a separate endpoint that the frontend hits I'm sure this happens in some cases, but it's definitely not a good practice, would hopefully get flagged by any pentesting or security audit, and also, most people use some sort of framework for auth (devise for Rails, Spring Security for JVM, or similar) - and those usually don't work in that way.
justsomehnguy 4y ago
Yep. One site I infrequently visit moved from their own account system to the "check your email for a pass code". This just made me to visit and login even more infrequently.
mod 4y ago
Half the web has a CAPTCHA just to view content. Thanks, Cloudfare.
- Sohcahtoa82 4y ago

baxtr 4y ago

> Here is an actual UX/security tradeoff: you can make the signup process email based. Great. Now I can’t share passwords any more with significant others. Instead I have to send them login credentials every time they want to login.

capableweb 4y ago
Automatic forwarding solves this problem for you :) Personally I have my email setup so everything mentioning Netflix/HBO/Disney/$streaming-service/$shared-service gets automatically forwarded to our family inbox that everyone in the household has access to, in case they need to reset the password or do something related to those services Edit: added "automatic" to "forwarding" as that's the vital piece here
- baxtr 4y ago
  Forwarding assumes I am checking email every time they want to login. The auto-setup is a cool idea though.
  - capableweb 4y ago
    Of course I meant "automatic forwarding" rather than manually forwarding everything, missed to add that word there someone, corrected :)
progval 4y ago
The author only recommends doing this on signup, ie. registration. Not on login.
- baxtr 4y ago
  Thanks. You’re right. Didn’t read carefully enough.
yegle 4y ago
Exactly! McDonald's (US app) is using a login system like this. Worse, they automatically log out all other logins once someone logs in on one device. Eventually I became the designated pickup person of my house.

tromp 4y ago

I'd prefer the error to be "invalid username" if the typed username is not registered, and "wrong username or password" if it is. The system only knows if the username is valid or not; it doesn't know whether it's wrong (i.e. mistyped).

kahrl 4y ago
I'd prefer to not create brute force vulnerability that leaks the site's list of user email addresses to an attacker.
- tromp 4y ago
  As the article points out, this leaks it no more than trying to register an email address.
  - croes 4y ago
    Which can be prevented by sending an confirmation email at a signup, no matter if a new account or an existing one.

throwawaaarrgh 4y ago

If we can't manage to make password managers standard, we should try to make them required.

hairofadog 4y ago

On this topic, I've noticed a lot of sites have split their sign-in forms into a two step process (submit username, then submit password). Does anyone know what this achieves? It seems like it would be trivial for an automated script to submit the form twice, but as a human I often have to open 1Password multiple times to navigate the process. For example: https://myaccount.nytimes.com/auth/login https://myaccount.nytimes.com/auth/login

d8c6c050cb0a4d7 4y ago
This is useful when you have multiple methods to authenticate. Maybe this user should be redirected to an oauth2 identity provider or maybe they should enter a password. Good implementations of this will have a hidden password field for password managers to fill along with the username. You'll still need to press enter twice though.
tpetry 4y ago
This is for SSO reasons. When you enter your email address they check whether SSO is activated for your email address (or whole company domain) and will redirect you. It is better for usability than requiring your users to enter some random password or keep the password input empty.
swhitf 4y ago
Usually it is to detect the user is registered to (or their domain is mapped to) an account with SSO or Social Auth and prompt them for that login mechanism. If the user is being required to go via the SSO provider, it makes sense to ask for the email first before they input their password so that they can be redirected it neccesary.
dexterdog 4y ago
2-step signins are so annoying for those of us who don't use it. I imagine they are also annoying for people who use it because they still have to first type in their email address instead of just going to the google/fb/apple/etc page where they click on their identity.

codingdave 4y 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. Security is never perfect, it is always about making it annoying enough that people don't bother. So yes, there are other ways to see if someone has an account. But odds are the person attacking your site is not singling out one account to hack, they are trying bulk attacks with many accounts. So you avoid leaking info to not give the script any more ammo on what else to try. And hopefully the attacker will move on to some site that did give it more ammo.

SamBam 4y ago
> it is always about making it annoying enough that people don't bother. > But odds are the person attacking your site is not singling out one account to hack, they are trying bulk attacks with many accounts. I feel like these two statements are at odds with each other. A regular user is going to get annoyed. An attacker using a script and multiple attempts is simply going to include the other way of verifying if an address is real in the script.
kgwxd 4y ago
Maybe instead of saying the email address is already in use on the site, just let the "sign up" happen and tell them to check the email for a confirmation link, and in the confirmation email say "someone is attempting to sign up with this email that is already signed up, if this was you, use the Forgot Password link to reset the password for the existing account. If it was not, click here to report this incident."

kklisura 4y 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. So why not just send an email upon signup with existing email and just show success on signup? I'm guessing email would state that you already have an account there, maybe you need to reset password and email would provide instructions. Using this approach there would be no leakage of information and you can inform the user someone tried signing up with their email. Edit: This would work only if only email is required for signup, but it would not work with usernames.

SamBam 4y ago
The article suggests this. But also says you're going to make sign-up a lot more lossy because the context-switching may make some people give up.
nerf3000 4y ago
Or just allow multiple accounts to use the same email (with an upper limit) Already people can chuck a + in the user part and register with the same email like joe+2@gmail.com so really there's not much point trying to maintain a 1:1 user to email ratio.
- mod 4y ago
  That's what I've always done, with an upper limit of 1. More seriously, this just kicks the can a little bit. "Already people can chuck a + in the user part...so really there's not much point trying to maintain a 25:1 user to email ratio"

drewcoo 4y 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. The assertion is incorrect. Closing a means to account name guessing does not presuppose that there are no other means available. Locking my front door does not assume I have no other doors.

est 4y ago

The best measure? Let any login pass, just generate a fake account if the credentials were wrong.

TheMaskedCoder 4y ago
That would make things waaaay more difficult for users. "Okay, I'm logged in, let me do something.... Now it says I don't have permission?? Did my account get deactivated??? What am I doing wrong????"
mrmattyboy 4y ago
Hah, I did this ages ago in notebook application that I wrote for myself.. Though the amount of times I went a long time between logging in, got the wrong credentials and got scared very quickly when all of my notes had vanished :P
patrakov 4y ago
The best measure? Ditch the password. It can be reset anyway, it can be stolen, it's just unnecessary complexity, it doesn't provide any security. You can prove ownership of the email? You can log in - worst case, after a password reset. So why have a password? email: ______________ [Log in] The "Log in" button results in a "Check your inbox and click the link in the email that we just sent you" page. Source: https://appear.in/ https://appear.in/ used this flow from the very beginning, before it was destroyed in a trademark dispute. EDIT: now it is https://whereby.com/user/login https://whereby.com/user/login

nerf3000 4y ago

I don't think saying "but these popular sites let you enumerate registered email addresses via this other form" is justification to be lax about protecting against user enumeration attacks on your own site. The actual take away should be more like "I found a security issue in the registration form of these popular sites, they should fix it" Enumerating valid emails, even if rate limited, lets an attacker build a contact book for targeted phishing attacks, connecting leaked passwords, brute forcing and is also useful in recon to determine what sites a person may have an account with, and more. It's worth protecting against as much as possible.

darrinmn 4y 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. This is not true if the signup flow is implemented correctly. Signing up for an account should always respond with the same message "we sent an email for you to confirm your account signup". The owner of that email address then receives an email - either 1) normal signup process, or 2) "did you just try to sign up? You already have a valid account for this email address." This way you cannot tell via the signup web form alone whether an account exists or not. You need to have access to the email address.

emodendroket 4y ago
That exact strategy is described in the second paragraph but the author argues (and I agree) that it is so arduous it will cause you to lose many users for questionable benefit.
- darrinmn 4y ago
  Yes but the exact quote is confusing as he specifically mentions email addresses (in bold text). I know the author mentions usernames elsewhere in the article and I agree with the author this isn't applicable to websites that allow username signup since anyone can pick any random string... But for email address signup, as the exact quote mentions, there is no additional context switching since you already need to confirm the email address regardless.
  - emodendroket 4y ago
    Often you don’t need to confirm the e-mail address to complete whatever workflow you’re doing.
    - darrinmn 4y ago
      Sure, companies are free to make their own choices based on their business incentives. But if you can create an account and be logged in without verifying an email address, then arguably the email address wasn't needed in the first place and you should just allow any type of username string. If the goal of your website is for email address to be the username, the you should confirm the user actually owns the email address they claim first - since anyone could lie and put a random email they don't own.

andrelaszlo 4y ago

I don't get it. It's fine to leak/allow user enumeration on the login page because it's leaked elsewhere anyway? That's a pretty big assumption. One way to allow users to register using their email address without leaking any information is to just say "user created, please check your inbox to confirm your email address" or something like that. If the user already exists, swap the confirmation email for a warning email if they already have an account. Or am I missing something?

deleted 4y ago
[deleted]
physicles 4y ago
In a sense, yes. If you’re revealing an account’s existence on one page, your system isn’t made more secure if you hide its existence on another page. If you think it does, you’re fooling yourself. Better to use other tools (like rate limiting) to improve security. And yes, you’re missing the second part of the article where the author mentions the registration flow you describe and then points out that it’s not a great user experience.

jbj 4y ago

rippercushions 4y ago

(2014)

yalogin 4y ago

A tangentially related question. I have, embarrassingly, not kept up with fido. What does it provide? I am guessing it provides a spec for a iOS keychain equivalent where passwords are stored in a dongle (or software) and “let out” based on user approval. I remember reading it also provides a new password-less auth mechanism. Is it out yet? If so is it adopted?

ad404b8a372f2b9 4y ago

I agree with the premise but the solution has UX issues of its own. Some users, like me, have learned to use the registration form as an account checker for their own email. I don't remember if I have an account on some websites, and if I do I don't remember with which email+password combo, and the password reset page doesn't tell whether the email is correct, and it often takes 10 minutes for them to send a reset email so I still don't know whether I'm registered with the email I entered and should just wait or not registered at all and no email was sent. So instead I just try to register and bam, instant answer. In addition to that, the context switch to emails increases friction significantly during registration. It's much easier for the user to be logged-in immediately and not have to check their email. That's not even taking into account the wasted time of having to re-enter all your info. Disclaimer: I know the first issue is solved with a password manager and a faster email service, that's not the point.

thomastjeffery 4y ago
You might not know if you have an account, and you might not remember your password. The solution to either problem is the same: send an email. So why not merge the two processes? Actually, any "forgot username/password" link effectively does this already. The only thing we need to do is make that more obvious. I think the easiest way would be to separate username creation from password creation. Just have a single sign-up prompt asking for an email address, and put the link to the password creation page into the sent email. Set the title/content of the email to clearly show whether an account exists already (with a password reset link) or doesn't (with a password/account creation link). If the user stops there (the account creation email answered their question: they don't have an account with this email), then you can simply expire the password-set link without ever creating the account.
- ad404b8a372f2b9 4y ago
  It's not a solution to the problem I described, if it were the forgot password page would already solve it.
  - 4y ago

gumby 4y ago

Related question: what's the deal with having a login form that only takes a username, and then only shows a password field after you've pressed enter? I find this very annoying and can't come up with a benefit.

kozziollek 4y ago
If username is an e-mail then an app probably checks if e-mail domain has configured single sign on (SSO) and, if it has, it redirect you to your company authentication server instead of asking for password.
- gumby 4y ago
  thanks
danjc 4y ago
SSO handoff as a sibling points out but also once email is known, a determination is made about trust level for the sign in attempt. Cookies, IP and other fingerprinting are used to determine whether single or double factor auth is required.
- gumby 4y ago
  thanks.

whirlwin 4y ago

Not a UX'er. But speaking of UX - it is inherently very annoying to sign in with username/password in general. At least in 2022. 2014 was perhaps different.

danjc 4y ago

In 2022, building your own user signup/sign in flows is almost as bad as rolling your own crypto. Edit: a rebuttal is mightier than a downvote.

exabrial 4y ago

I used to think this as well. BUT, revealing _any_ information to attacker is a security problem. Take this scenario: Someone might not want their employer knowing they (legally) gamble online. The employer could simply browse to popular online gambling sites and probe the service with their email or username to see if an account exists.

deleted 4y ago

[deleted]

thomastjeffery 4y ago

Just reading the title, I expected OP to be talking about invalid passwords, i.e. when a password's text can't be used because it's too short/long or has/doesn't have specific characters. That's a discussion I would be much more interested in; mostly because I'm sick of seeing long passwords be completely broken. A better title for their post would be "incorrect", not "invalid".

dfxm12 4y ago

So what we've done by promoting "Invalid username or password" is made our login form UX much, much worse, without increasing the security of our product. Much, much worse? Not at all. It doesn't matter if you've forgotten your user name, email address or password; if you've forgotten your credentials, you reset your password, not keep guessing until you give up. The password reset will also clue you in as to if you've got the right email address.

mrmattyboy 4y ago

I'm not sure if someone has mentioned this already, but if someone has gone down the path to allow enumeration (username check during signup, which is immediately returned ton the user), I would say this is a strong argument where you could protect yourself against enumeration more easily.. The amount of times a user will likely type their username/password incorrectly is going to be a lot higher than those who attempt to re-signup for an account. Therefore adding additional protection to the signup page (hard rate limiting, bot-protection) then aids to stop this username/email enumeration without the need to be as strict on a login page. This is also compiled with ip-based rate limiting/bot protection that can get very frustrating for users within a corporation that have single public IPs for all their users.

MostlyInnocent 4y ago

The article makes a good point, were it not for security auditors (SAs). SA: You leak information and therefore violate policy by disclosing on the login form whether an account exists or not! Me: Yeah, but figuring out if an account exists is really simple anyway: just a query to a different endpoint... SA: NEVERMIND, MY LAD: disclosing account existence upon login violates BEST PRACTICES! Me: OK, yeah, whatever, we'll just change the error message to "something you may or not have entered may or may not be valid information, try again, or not" SA: cool beans! WE ARE NOW INDUSTRY LEADERS

Terretta 4y ago
Every well known credit card / credit data breach has been of a PCI-DSS compliant party. To any SAs reading this: you're not secure because you're compliant.
- mcv 4y ago
  The big issue there is that they store credit card data at all. And of course that some simple public number is enough to authorise payment.

throwaway09223 4y ago

This is an extremely silly observation for HN, given that the usernames are published openly with every comment. My username is quite obviously "throwaway09223." There's no need to enumerate anything. Avoiding username enumeration is a reasonable goal for some sites in terms of hiding PII, but it is very obviously not a necessary security measure.

crazygringo 4y ago
The article is about usernames as email addresses. Not about handles. HN doesn't reveal people's e-mail addresses, unless they choose to put it in their bio.

zajio1am 4y ago

> 99.9% of websites on the Internet will only let you create one account for each email address. Is it common? That seems like useless and impractical limit. E.g. for e-shops, one would like to have separate accounts for personal purchases and for business/corporate purchases.

wccrawford 4y ago
Yes, it really is like 99.9% of websites. If you need multiple accounts, use multiple emails addresses, 1 each. You should keep your personal and corporate email separate anyhow.
toast0 4y ago
It's kind of weird when you can login to different accounts with the same username, which is typically the email address. I mean, amazon lets you do it, and I've had two accounts with the same email address and password there; but it's still pretty weird. IIRC, I had two accounts with different addresses and changed them into the same address. A lot of accounts don't let you change your email address at all, so they solve the problem that way.

emodendroket 4y ago

This is a bit like the “don’t write your passwords” stuff. It doesn’t matter how obvious the arguments against it are — the author of this piece is not the first to note the absurdity of this setup — it is engrained as “best practice” and you will be fighting an uphill battle as a heretic trying to do anything else. I’ve lost similar arguments for similar reasons.

deleted 4y ago

[deleted]

dang 4y ago

Discussed at the time: “Invalid username or password” is a useless security measure - https://news.ycombinator.com/item?id=8683003 https://news.ycombinator.com/item?id=8683003 - Dec 2014 (182 comments)

nibbleshifter 4y ago

If the signup or reset process enables user enumeration, we tend to ding you on that in audits the same way we ding you for enumeration via the login form. Captchas, timeouts and rate limits are all well and good, but given the attack tools (eg: SentryMBA, OpenBullet) used by the lowest common denominator solve for those (by using captcha API's and residential proxy networks)... Breaking user enumeration vectors becomes super useful.

hkopp 4y ago

The argumentation is faulty. Users cannot be enumerated using the login, but using the signup. The author then argues that they should add the user enumeration function to the login. This is similar to: The door is locked, but the window is open. And then consequently it makes no sense to close the door at all, as an attacker can sneak through the window. Instead, the window should be locked as well, i.e., it should be impossible to enumerate users with the signup function.

upofadown 4y ago

Usability always seems to lose to security. Then we complain that the users can't use the system. I have come to think that every decision of this sort should first be an attempt to increase usability. Security is ultimately about usability. They are not actually at odds. Too often there is no analysis done after a potential security issue is identified past directly resolving the issue. Rarely will there be an attempt to reevaluate the usability after the change.

AtNightWeCode 4y ago

Would not go as far as saying 99.9% does this. A third-party pentest company we use does not consider this a security issue. I am not sure. I think it is information leak. I think the idea is that at some scale Everybody has an account so it does not really matter.

janalsncm 4y ago

Is there a use case for passwords at all? Passwords have the downsides of being guessable and hackable, as well as forgotten. I’d like to avoid the “correct horse battery staple” malarkey if possible. In most cases, control of the account email is equivalent to control of the account because I can reset the password if I control the email. So it seems that magic links or OTPs are strictly better. Am I missing something?

djaychela 4y ago
I think you are, yes. These situations spring to mind, all of which make email OTP a worse solution imo: Shared account without both having access to email. Email OTP is more time and effort than entering a password. Email can be down. You may not have access to email for another reason (different device, etc).

bloomingeek 4y ago

What if Google won't let you have your gmail account back? I broke my cellphone, so I went to the same carrier and purchased another Samsung, same phone number, but different model. So when I go to log into my Google account with the new cell, Google sends me a two way code, But to the old cellphone! After days of trying to get into my account, I finally have to create a new account and email address. (yes, I know NOW there are ways to create a safety backup.) The phrase, "Invalid Username or Password" started showing up in my dreams.

deleted 4y ago

[deleted]

mcv 4y ago

One of the comments there says: > Heh, after an independent security review we are being forced to take this even further; We lock people out for five minutes after three invalid login attempts. We are no longer allowed to tell users they have been locked out. So, even if they do remember their password (or even does a reset) we just have to tell them their uid/pwd is wrong when they try to log in. And for “forgot password”? Just tell the user “we have sent you an email – IF we recognised the email you put in”. This sounds absolutely horrible, and now I'm wondering if I've been subject to this behaviour. Couldn't remember my password (for a trivial site where I use one of my reuse passwords and didn't put it in KeePass), started doubting if I had the correct email, eventually reset the whole thing, reset the password to the password that I thought it should have been, and got an error telling me the new password couldn't be the same as the old one.

shantnutiwari 4y ago
I felt this with LastPass. It put in some secret locked mode, and wouldnt let me login even wit h right password. 3-4 hours later, it just started working. I was a paying customer, didnt get any replies to my emails. It pissed me off so much I moved to 1Password AND Bitwarden -- 2 in parallel, so if anyone pulls this on me again I can immedietely move to the other

lakomen 4y ago

First of all, Fuck 2FA! 2FA = companies fishing for phone numbers to identify and track you. This post is from 2014. Meanwhile I suggested that an any login attempt you would receive an email, you don't have to know your password to the service. Effectively Microsoft is the only company doing it like this. You don't need a password, every time you log in you can opt to have a login link sent to your email address instead of using a password. That IMHO makes sense. And I'd go one step further. Anytime anyone tries to use your service, don't ask a password, just ask for their email address. The most detrimental or annoying part of a sign up process is picking a password and worse, some stupid services demand you repeat your email or password. Let the user sign up effortlessly. I won't even start about how awful captcha is. If you use a JS form and means of sign up or login you don't need captcha.

gamzer 4y ago

If the goal is to log in new users immediately after registration, is it possible to not leak whether a username is already registered? If hn@example.com is not registered and I register it, I will be logged in (even if it does not belong to me). If hn@example.com is already registered, the site can neither let me register it nor log me in.