11 ms·
“Username or password is incorrect” is bullshit
- kyberias 9y agoI like the dramatic style this opinion is written.
- maephisto 9y agoI could totally feel this blog post, not just read it.
- travisjeffery 9y agoHaha, that's cool with me.
- jkire 9y agoIsn't the other reason so that adversaries can't tell if a particular username/email has signed up? This is not so useful for something like github, sure, but certainly is useful for the more embarrassing sites where users have an expectation the site won't leak their membership. So in some ways I've always thought of this as a privacy concern rather than a security one? Edit: I guess I'm thinking purely of emails where you don't get availability checkers during sign up.
- pgeorgi 9y agoAs the post demonstrates, you simply go to the login form to validate the presence of accounts. Few sites remember to anonymize that, which might be the real PSA: in such a case, if you require an email confirmation anyway, just send the "recover password" email internally, but let it look like the regular sign-up flow. If you don't requite email confirmation, anonymous membership isn't possible (just try to sign up with that account, what is the site supposed to do that looks legit without giving away information?)
- axman6 9y agoEven if this doesn’t increase security, you should still do it in the hope the user will check the username they’ve just typed as well as retyping the password.
- basdp 9y agoWhy? Why not just tell the user what is actually wrong?
- tome 9y agoBecause the application doesn't know what is actually wrong. The error message is actually correct as written. The user entered their username incorrectly or their password incorrectly, or both. The application doesn’t know which and shouldn’t guess!
- kalleboo 9y agoWhy wouldn't the application know?
- tuxxy 9y agoThe application doesn't know if the username you entered is actually yours or someone else's. You could provide the correct password to your account 'test', but not 'ttest'. The server just tells you to check both instead, it's more semantically correct and offers some security improvements with user enumeration.
- willvarfar 9y agoThe article explains how to do it properly at the end: > To prevent attackers from knowing whether an account exists or not your signup must only take an email address and provide no feedback in the UI if the sign up succeeded or not. Instead the user would receive an email saying they’re signed up. Is this not also part of the various 'best practices'? (I confess I don't read too many of them!)
- tuxxy 9y agoTypically, yes. This post didn't really offer any new insight to this. Maybe it's a PSA? Either way, it completely depends on the site's threat model. In the case of GitHub, it's quite useless because a user can just go to the targets's profile to see if it exists. Thus, it really isn't in GitHub's threat model, obviously. Where it gets really interesting is when you perform user enumeration attacks via timing. IE: it takes the server a few milliseconds longer to send a registration email than to not, or it takes the server longer to try to validate a password hash than to lookup a nonexistent user.
- aglionby 9y agoIs this possible to detect despite external factors (variable latency etc)?
- menacingly 9y agoIt's black magic to me, but I'm paranoid about timing attacks after seeing a few examples in the past of what's possible for a clever attacker to guess if they can gather data from a number of requests.
- aglionby 9y agoI've once tried to sign up for some site (I can't remember which) which went through with the usual successful signup, please check your email text. The email I received however was something along the lines of 'you already have an account with this email!', which seems like the best way of doing things.
- Kenji 9y ago100% agreed.
- rafaelbarbosa 9y agoIt's still good advice for software where there is no public signup, such as SaaS where accounts are created by administrators.
- sika_grr 9y ago> Even if reCAPTCHA was perfect, a hacker could manually validate their usernames of interest by trying to sign up, then automate an attack on the sign in page. Why is imperfect reCAPTCHA worthless? Do sign up pages even allow brute forcing of usernames (once validated)? Is he suggesting to fix sign up pages, or to allow brute forcing usernames on login? His writing style is dramatic, but the arguments are very weak.
- 1ba9115454 9y agoThe solution is relatively simple. 1. Email and password for login. Don't tell the attacker which is correct. 2. Email and password for registration. On registration send confirmation email. If user is already register attacker would need access to their email. Access to email is game over. So now an attacker can't see which users are registered with your service and you've protected your customers privacy. Extra points if your code is aware of timing attacks.
- IshKebab 9y agoSure but everyone does 1, and not 2, so it's bullshit. Also what is a bigger annoyance? People can slowly use emails to look up if you have an account on a website, or it being a pain in the arse to log in? Except on some sites, e.g. dating websites, this is a stupid theoretical security gain that just pisses everyone off. Like requiring numbers in passwords (basically everyone adds a 1 at the end) or making you change passwords frequently.
- tzs 9y ago> 2. Email and password for registration. On registration send confirmation email. This opens up a different problem. It should be: 2. Email only for tentative registration. On tentative registration, send confirmation email. 3. User clicks link in confirmation email, which takes to page for setting password. (Alternatively, confirmation email includes randomly generated initial password, user is required to change it on first login). After password is set, registration changes from tentative to confirmed. If email and password are both included on the initial registration form, an attacker can try to sign up people and some fraction of those people will accidentally click the link in the confirmation email, thereby resulting in some new accounts where the attacker knows the email and password, and the email owner does not know the password.
- icebraining 9y agoYou should definitively set the password after clicking the link. That said, what would an attacker do with that account?
- godzilla82 9y agoSo, as per the author, sites should first check if the user exists and then check the password? Why? What if the username belongs to someone else?
- cdancette 9y agoSignup and login should behave the same, and provide no information wether the email is registered or not. And username should be treated as public. So for login: always say "email or password is incorrect". And for register: as he said, always say "we sent you an email to verify your email".
- wyuenho 9y agoExcept that when you are signing up, unless the service is using some draconian password formatting rules, any "email or password is incorrect" error can be inferred as the email is incorrect, and if the email format is correct, it's must likely because the email was taken. "email or password is incorrect" is bullshit is right.
- ChrisMorrisOrg 9y agoCan you please give an example? I don't think I understand what you're saying.
- croon 9y agoEither you or I misunderstood GP. I understood it as if (as long as any email format validation allows the address) the service only outputs "sent you an email for confirmation", even if the email is registered. The attacker wouldn't know if it was the first time or the 50th time that message had been shown, as it's always the same.
- travisjeffery 9y agoCorrect. The UI message would always be the same, some variant of "email sent." Even if the account already existed and it wasn't actually a successful sign up of a new account.
- wyuenho 9y agoI understand him perfectly, what I'm saying is what he's proposing is useless, because you can mold your email and password into anything that you know for certain it will pass validation, that's your oracle right there. During sign up, if you know both the formatting rules of what you typed as the email and the password cannot have caused an error, then it follows any error message (500 errors notwithstanding) must be a duplicate email. Because that's typically the only constraint difference exists between an email and a password. Given that, who cares what error message you display, as an attacker I only need to be able to find out weather a system has an email or not, and the sign up screen is a perfect oracle.
- GlitchMr 9y agoI have an argument for "username or password is incorrect" messages: it's possible that the password is correct, username exists but isn't the intended one. Then "password is incorrect" message would be lying, as the issue is actually with a username.
- arrrg 9y agoOptimizing for the common case seems prudent here.
- jwilk 9y ago"password is incorrect" would be technically correct, perhaps not as helpful as it could be, but certainly not "lying".
- ajuc 9y agoYou mean you log onto John with password 12345 and the website says "Some other user uses this password, but not John"? Seems wrong, somehow.
- gregoriol 9y agoIf you, as a developer, are technically able to check that the password is used by another user, you have failed pretty big at best practices.
- ajuc 9y agoYeah, that too :)
- mnarayan01 9y agoDoing it every time a user login failed is probably infeasible if you have even a moderate number of users, but you can presumably do it on an ad hoc basis unless you have a ton of users. Or am I missing something?
- interfixus 9y ago
- deleted 9y ago[deleted]
- davrosthedalek 9y agoThe title is "bullshit". The real problem is that they leak the information they try not to leak anyway, on a different form. This is a common, but not universal, problem. It's not OK to leak information, even if that information is maybe leaked somewhere else already.
- zimbatm 9y agoIn the GitHub case the handles are public information. Anyone can go to https://github.com/<handle> https://github.com/<handle> to verify if it exists. So they trade off usability of a clear error message for no gain at all.
- tantanel 9y agoThis is true for the username but it's possible to make your email address private on GitHub in which case the message that your email is taken can still be considered an information leak.
- jwilk 9y agoYou can check if an e-mail is associated with a GitHub account easily. You forge a commit with this email as author email, push it to a foo/bar repo, then look at https://github.com/foo/bar/commits/master https://github.com/foo/bar/commits/master .
- _asummers 9y agoBut to you -- the user entering credentials -- that error message is still accurate. From GitHub's perspective, they don't know which one you entered correctly. It could be argued they should tell you that the username doesn't exist if it doesn't (reasonable with public profile), but in the case of an existing user, this is the only correct error message.
- u801e 9y agoNot quite on topic, but it would be nice if more websites would offer the option of using client side TLS certificate "login" with or without an additional prompt for a username and password. It would be next to impossible for an attacker to bypass that. For example, even if the attacker provided the correct credentials, they most likely would not have the associated client-side TLS certificate private key. Then the server could just reject the log on attempt outright (since the certificate wasn't provided or verified).
- mdahlstrand 9y agoSounds like a great solution - would browsers need to support it? Do you have any resources on implementing it?
- lmz 9y agoAlready supported by browsers. Massive PITA to use. The old Startcom SSL webapp was an example. Private keys and certs aren't as portable as passwords. Backing them up, copying them to another device, etc. lacks good UI.
- alephnil 9y agoBrowsers has supported it since the late nineties. The problem are on the practical side. If you ever log in from more than one machine, all must have your private key, and the mechanism for synchronising keys between machines are not there. You have to manually install your key each place. It has also been too hard for most people to make and handle public/private key pairs. Also, if you don't have the private key with you, there is no way you can log in to the site. All of these problem and many other usability problems would have to be solved for client side certificates to be a success.
- delinka 9y agoChrome already syncs data between platforms. Seems reasonably straightforward to include client certs in that data.
- 9y ago
- j_s 9y agoAsk HN: Why does Amazon allow multiple accounts with the same email address? (2014) | https://news.ycombinator.com/item?id=7075372 https://news.ycombinator.com/item?id=7075372
- nhumrich 9y agoInteresting. Just reading this now, but it makes me wonder, what happens if you set two accounts to the same password?
- falsedan 9y ago> you can create two accounts with the same e-mail address, but you will get into trouble if you try and give them the same password. I'm not sure what happens, so try it and see.
- stordoff 9y agoI've somehow ended up with three Amazon accounts under the same email address. Two on Amazon UK (which appear to be shared with Amazon US and Amazon DE), and then a third on Amazon JP (which only appears to work there). Very confusing at times (I've ended up putting a deliberate misspelling in my name -- Stpehen instead of Stephen -- so I can tell at a glance which account I'm on).
- JansjoFromIkea 9y agoThere's definitely a trend away from this to some degree lately, I feel. It's probably more influenced by Google not doing it with their accounts (enter username -> forwarded to password page with your avatar) more than anything else, mind.
- pornel 9y agoThe right answer isn't a blanket "sites should do this super-secret e-mail-only shuffle and not tell you anything". First, you should define your threat model: which information is considered secret and which isn't, and treat any violations as security vulnerabilities. If usernames are public by design, then don't hide them in one form, and expose in URLs elsewhere on the site. If exposing who's registered on your site really is a threat, then by all means have a weird registration (and password reminder) that doesn't tell whether it worked or not. But if your site is for cookie receipies and you don't consider exposing who's a fan of cookies a privacy violation, then just use most helpful messages you can.
- pqh 9y agodefault to privacy though, please
- ryanbrunner 9y agoNot really. "Default to privacy" is what gives you insane useless UXes like the one in the article, where you're making login (already a frustrating experience) more painful with absolutely zero gain in security. Default to knowing your threat model. Default to balancing security concerns with UX, and make an informed decision instead of blindly following best practices.
- perfmode 9y agoI don’t want others to know all of the places where I have accounts. That’s an easy way to be targeted.
- stordoff 9y agoThat's the point of the article though - for a large percentage of services, if you know the username/email address you are targeting, you can just try to register them and see if it works. Obfuscating the login process makes little difference.
- rmetzler 9y agoThis is actually a feature for users who have almost the same username and mistype this instead the password. E.g. this could probably happen through an unfamilar kayboard layout. I understand that a lot of people think this is a security feature, but once upon a time it was the lazy programmers answer when "SELECT * FROM users WHERE username=? AND password=?" didn't return a result. With proper salts for hashed passwords you now have to find the username, use the salt to hash the password and compare this. If your database allows to hash passwords with a dedicated function it's still the easiest to say username OR password must be wrong.
- z3t4 9y agoAfter reading this I went straight to change the login system I'm currently working on ... And discover that I would need to add some extra code paths / conditionals ... So for me it's not "best practice", it's more todo with laziness and not wanting to add complexity to critical functions.
- vatotemking 9y agoDoesnt “username or password is incorrect” falls into the Security through obscurity category?
- scotty79 9y ago... also, you can often do "Forgot my password" and if you give unregistered email it will tell you that.
- rawnlq 9y agoTry searching for your username on https://namechk.com/ https://namechk.com/ https://www.namecheckr.com/ https://www.namecheckr.com/ http://checkusernames.com/ http://checkusernames.com/ or https://pipl.com https://pipl.com. I am sure these name checkers can't be built if they have to spam the sign up forms just to check availability (at least not for free if they have to pay for manual recaptchas). The privacy is worth it.
- chicob 9y agoIn the article: "You gain no security, yet your customers lose clarity." Oh boohoo. Like it's not on the customers side to know which email it is and which password. And as many have said, one does gain privacy.
- kuceram 9y agoHere is a super useful article about how you should build login https://blog.codinghorror.com/the-god-login/ https://blog.codinghorror.com/the-god-login/ (if you don't want to rely on professionals from Auth0 or Okta :-). In the article, there is a very good statement "being user friendly is way more important than being secure" and this is exactly this case also...
- 27182818284 9y agoLately I've seen the catch-all "We could not verify the credentials you entered" and it has grown on me a lot.
- skywhopper 9y agoThis is a pointless argument because I doubt Github or anyone who uses this message seriously considers it to be a security measure. Github's usernames are absolutely public. But they also have so many users that I suspect the wrong username is typed all the time. So yes, sometimes maybe the username is wrong.
- samnwa 9y agoI suggest we just randomly say your username or password is incorrect. "Your username is incorrect" "Your password is incorrect" "You hit the wammy. Try logging in again." That way, you never know what's going on at all.
- exabrial 9y agoMy other favorite security theater advice is locking an account after x number of failures. How could this used for anything but DOS? Depending on the service that's being protected, rate-limiting to 5 minutes between attempts, alerting the owner, and assigning them a temporary username seems more reasonable countermeasures to me.
- dreamdu5t 9y agoWhat’s the point of having passwords at all? If there’s a password reset mechanism they provide no additional security. Just send a one time login token to the email. Having a password just increases the odds of a hack by the user accidentally exposing it.
- stordoff 9y agoAt the expense of convenience - I often need to access accounts on devices where I don't have access to my emails (e.g. if I'm using a semi-trusted PC [family devices etc.], I might login to Amazon, because anything there can be undone, but I wouldn't login to an email account [and if I haven't memorised my email password because it's in a password manager, I might not even be able to]).
- styfle 9y agoI asked this same question[0] on StackExchange earlier this year. It has been asked many times and it really comes down to considering a username a secret or not. In B2B applications where there is no registration form, then the username is probably a secret. In B2C applications where anyone can register, then the username likely isn't a secret. Many of those applications have the concept of "mentions" by username so clearly the username is not considered a secret in that case. [0]: https://security.stackexchange.com/q/158075/11536 https://security.stackexchange.com/q/158075/11536
- hbk1966 9y agoAlso if you are doing the username/password is incorrect you should also add an artificial delay if it's the username is wrong. Because you can tell which one is wrong my seeing how long it takes the server to respond.
- alexozer 9y agoIf you're just trying to find a set of accounts with a weak password, isn't it much more viable to use the sign-in page that shows "invalid password" instead of "invalid username or password" rather than dealing with captchas on the signup page? Assuming you can't just find usernames as public profiles like on GitHub.
- oliwarner 9y agoStripe does it wrong, so it's wrong everywhere? Nah. That's bullshit. For emails, you can very easily fake a second signup with the same email and ping out an enhanced verification email "Somebody just tried to register with this address but you already have an account". Building the username into that flow is harder. That's why I preference not having separate usernames but some people would argue this is itself a bad thing (removing a factor or somesuch). Either which way, Stripe's approach is broken. That doesn't make the whole idea nonsense.
- observation 9y agoGood point. I'm embarrassed it didn't occur to me before.
- zanedb 9y agoI have felt this same way for so long and I'm really glad someone finally wrote about it.