
“Invalid username or password” is a useless security measure - kevinburke
https://kev.inburke.com/kevin/invalid-username-or-password-useless/
======
andrewstuart2
I think the real lesson here is that _if emails should remain secret_ you
should not indicate upon signup whether or not a user exists with that email.

Always send an email.

If that user already exists, make sure the email says "We noticed you're
trying to sign up again. If you didn't do this, someone else is trying to sign
up for you." If that user doesn't exist, send them the typical signup message.

The author has some great security tips in the "what should I do instead" but
I don't think the _instead_ portion is accurate. Keep private information
private, and make access to public information as easy as it should be.

If emails are public, shoot, use a websocket connection to style the login
field in real time and show the user whether or not the email they typed is
valid.

~~~
crumpled
Forcing the user to interact with an email client during the signup process
before they've confirmed the availability of a username might be good for
security, but it's a horrible way to gain users. That's a very high friction
process. I generally agree with this comment, however.

~~~
MiddleEndian
This is why I like federated login with the options of Google and Facebook.
Why go through the hassle of creating a new password and sending a
verification email, when the user can just click a couple buttons to sign in
with a service indefinitely? The username can be chosen afterwards and never
has to be re-typed.

~~~
smt88
Many people are paranoid about connecting Google/Facebook to anything. You
_will_ lose users if you don't give them a plain username/password option.

~~~
MiddleEndian
I know, but it's so much easier. It's not like I can't look up someones email
account manually without federated login, plus then I no longer have to store
passwords.

Of course, aside from my own projects, the only service I've seen that
exclusively does this is Fancy Hands.

~~~
smt88
I agree that it's easier, and if you're only getting a unique identifier from
that service (as well as a token), then it's really not unsafe. For the
purposes of login, data sharing is unidirectional.

The problem is that Facebook totally mismanaged their apps when they first
launched, and a lot of people were permanently turned off to "Connect to
Facebook" functionality by random apps posting under the user's name.

My account was recently abused by Glassdoor, which fervently promised not to
post anything to my friends, and then immediately did so.

------
tacostakohashi
Leaving security aside, "incorrect username/password" is still the more
correct and useful statement.

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

~~~
drzaiusapelord
I've worked with a CRM product that allowed non-unique usernames. That's right
the usernames could be duplicated, so we had like 10 jsmith's. It would parse
the username/password combo, and if one matched, that's who you logged in as.
I never got to test what happened when jsmith had the same password as another
jsmith. I'm sure the results would have been terrifying and hilarious.
Apparently, the history here is that it used to log people in using their
email as their only username, but someone here didn't like that and the vendor
tacked on this half-assed solution. So you email is your unique identifier but
its not used during login.

I suspect there's a lot of poorly written software that still does stuff like
this. The message is still valid in these cases as well.

~~~
bluehex
I'm going to guess when a new jsmith comes along and tries to sign up with the
same password as another jsmith, you get a helpful 'Sorry, that user name and
password combination are already in use.'

:P

~~~
ObligatoryRef
If they're stupid enough to allow non-unique usernames I wouldn't bet on
getting a helpful answer like that :)

~~~
dbpatterson
You do realize the helpful answer reveals another users username and
password...

~~~
deciplex
Anything other than allowing the user to register with the same username and
password as someone else will already give it away, so I don't see the harm in
spelling it out.

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

------
tetrep
>99.9% of websites on the Internet will only let you create one account for
each email address. So if you want to see if an email address has an account,
try signing up for a new account with the same email address.

While this is true, it's perfectly reasonable to require a captcha before
allowing a new account to be created; greatly limiting the speed at which an
attacker could enumerate emails. While it's not going to stop targeted
attacks, it will mitigate mass brute forcing of weak passwords.

Regardless of the ease of username enumeration, all of the author's points
about what to do are great for most sites. Rate limiting with exponential
backoff and 2fa are some of the cheapest and most effective means of
increasing the security of your app's authentication process.

~~~
baddox
But requiring a captcha before validating the uniqueness of each username
would be pretty annoying for large websites where many of the usernames I
would choose are already taken.

~~~
csallen
Which doesn't matter, because there's no point in keeping usernames secret
(and thus no point providing a captcha) unless those usernames are email
addresses, in which case it's unlikely that the username you want will be
taken.

~~~
baddox
Strictly speaking, keeping the existence of usernames secret does make brute
forcing username/password combinations more difficult.

~~~
tracker1
Only if the returned error code timing for a bad username overalps bad
password most of the time. Displaying an obscured error only serves to harm
the real users and is of little benefit to the system.

Unless you delay all failed attempts to login by a random time of 500-2000 ms,
it's unlikely you'll see much improvement in response rates... having such a
random delay is probably helpful anyhow.

------
volkangurel
It's only useless if the website reveals the username elsewhere, but that
doesn't have to be the case.

Consider the case when the primary usernames are always emails (many sites do
this), and signing up for an account is simply done with entering an email and
a password. Then, when someone submits a signup form, the website can:

\- Check if an account with the email exists, and if it does, whether the
given password matches the existing one.

\- If both are valid, log the user in, optionally showing a message saying
“there was already an account with these credentials so we logged you in”

\- If an account with the email does not exist, or if it exists and the
password doesn’t match, return a message to the user saying “please check your
email and follow the validation link”. The user can’t tell if the email exists
or not.

In the backend:

\- If the account did exist, send an email to the user saying “someone tried
to sign up for an account with your email, please let us know if it was you.
and here’s a way to reset your password if you forgot it”.

\- If the account did not exist, send an email verification link, which then
redirects to a page to complete the user signup

Same with password resets, the success message can always say "check your
email".

There are ways around revealing the username. But I agree, only doing this in
the login page is useless.

~~~
TheLoneWolfling
That will cost you dearly in terms of user retention.

~~~
volkangurel
If you have to validate email addresses, which I believe you do, what I
suggested doesn't add any more steps so I doubt it would cost anything. To the
contrary, given that the initial user signup is so simple (just an email and
password), users will be much more likely to complete it compared to other
signup forms that require more data. Once they are logged in and on your site,
you can gamify whatever portions of the profile you need filled, that is, if
you need any more data (most sites like hackernews don't).

~~~
volkangurel
Actually I'm wrong about hackernews, you'd need a username, but still, you can
choose that after you sign up, and you shouldn't be able to log in with that
username, that should only be a public handle for your account on forums,
comments, etc.

------
Someone1234
> Consider throttling invalid login attempts by IP address or subnet.

Oh hell no.

First off that is completely ineffective. Botnets are common and inexpensive.
But worse still a lot of users often share a single IP (e.g. university dorms,
businesses, public wifi, etc).

I agree with the first part of this article (i.e. that it is trivial to
"prove" a username is valid, and that worse error responses aren't
accomplishing anything). But that advice is poor.

> Check submitted passwords against a dictionary of common passwords (123456,
> monkey, etc) and ban that traffic extra hard.

That seems like a lot of engineering work. Plus the workload of loading up a
dictionary and doing a lookup upon each login is resources that frankly could
be better used on a slower hashing algorithm (to slow logins and make stored
hashes stronger).

> Exponential backoff (forcing attackers to try again after 1, 2, 4, 8, 16..
> seconds) is useful as well.

Just open a spreadsheet and determine how long it would take to test 1500
passwords. 1500 is a "short" dictionary of common passwords. Even a 1 minute
delay after each 2 attempts (or 2 minutes after 4, or 4 minutes after 8, etc)
means 12.5 hours of attempts.

I like to set the attempts really high with an equally high lockout. So no
normal user will see it. Most users do a password reset after the fourth or
fifth attempt, so if you set it on 8 attempts with a 4-6 minute lockout then
the majority of users will never run into it.

Instead of focusing on these kind of hacks why not just:

\- Set no maximum password length (250+ characters)

\- Set the minimum to at least 6 or 7

\- Get a password score widget (e.g. "weak" "normal" "secure"), traffic light,
to encourage better behaviour

\- When a password is set check it isn't in a common password dictionary (a
lot of score widgets integrate this!)

\- You can use Javascript to check a password dictionary as it isn't a site-
security feature, and anyone who goes out of their way to bypass it only has
themselves to blame.

\- Agreed on 2F, Google Authenticator is trivial to integrate. The only
remotely "hard" bit is generating the QR code and a lot of libraries exist for
that express purpose.

\- No clue how you'd integrate LastPass...

\- Account Alerts are extremely useful. As are admin alerts. Too many sites
get no warning when a lockout occurs, it is pathetic.

~~~
spb
> Set no maximum password length (250+ characters)

It's important to note that if you take the classical advice to "use bcrypt"
([http://codahale.com/how-to-safely-store-a-
password/](http://codahale.com/how-to-safely-store-a-password/)), your
password will be effectively truncated at 72 characters.

~~~
Someone1234
Fair point. I'd still happily take 72 characters compared to what many sites
currently offer. Anything over 30 is the exception not the rule.

~~~
sscotth
If someone can guess the first 72 characters of your password, they probably
know the rest. e.g. They have access to your password manager or you are using
a common phrase.

I still wouldn't limit a user from entering in a longer password. I'd display
a warning if they attempt to enter in a 73+ character password to inform them
that passwords longer than 72 characters offer no additional protection.

------
why-el
None of the author's recommendations conflict with the practice he is
advocating against.

I think websites say "Bad combination" not because usernames are treated
equally with passwords, but because you don't have a choice but say that.

If I tell you that your username is incorrect, am I telling you your password
isn't? This would be silly, because if the website is new and I know a
password is correct, then I can either find the username out there (if the
website is social), or pretend I forgot my username and have them give it to
me.

Assuming that's not what I am saying, then the user is surely to have a bad
experience anyway, since they will need to figure out a wrong username, and
then in the worst case, a wrong password. When you say a "bad combination" you
at least eliminate a possibility to mislead them into thinking __only one of
their credentials is wrong __.

~~~
masklinn
> I think websites say "Bad combination" not because usernames are treated
> equally with passwords, but because you don't have a choice but say that.

Of course you do.

> If I tell you that your username is incorrect, am I telling you your
> password isn't? This would be silly

Of course it is, a password is checked against a username, not against the
whole database. If the site is telling you the username is incorrect it's
telling you just that: the username is incorrect. It wasn't able to go any
further and check the password since it has no idea which password it should
check for (or even, if you're correctly storing passwords, which salt it
should use for the password check). Your criticism doesn't even make sense.

~~~
kemayo
His point is that it's not uncommon to be unsure which piece of data the user
got wrong.

Consider that on any decently sized website, you're going to have a lot of
cases where someone's trying to log in and they typo their username into
someone else's username (e.g. if you tried to log in as "masklin" and that was
taken). This looks to your server exactly like a wrong-password, but it's not.

If there's genuinely no user by that name, sure, tell them.

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

~~~
jdmichal
Except that entering a registered email will likely result in the legitimate
user receiving a password reset email that they did not request, thus
immediately raising suspicions that someone may be attempting to access their
account. Using the signup form is a much better approach.

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

~~~
tokenizerrr
They should allow login by email instead of username

------
rdl
Thinking this is only about security is shortsighted, IMO. There are cases of
typo-ing the email address, or entering a non-standard email address, which
happens to match another.

ryan@gmail.com -> ryan@gmaail.com probably would have some benefit to UX in
saying "email address does not exist", but ryan@gmail.com vs. ryanl@gmail.com
both exist.

What I'd probably recommend instead, if you do decide confirming account
creation status makes sense, is judging by cookie or IP. If 10.10.10.10 has
previously logged in as ryanb@gmail.com, and I enter ryan@gmail.com instead,
it might make sense to poke on the email; if I enter ryanb@gmail.com and have
an incorrect password, maybe suggest bad password. (of course, if you have a
cookie, you might as well pre-fill the login; if you have an IP match,
probably not).

The security tradeoff here exists but isn't huge. There are definitely cases
where the user benefit (and thus reduced bounce rate) of suggesting error in
username or password would make sense. The biggest security issue is
confirming "does this account exist at all?", because email addresses tend to
uniquely identify users, and you need some other mechanism to prevent this --
either automated (captcha would work) or targeted (in which case it's quite
hard).

I'm actually in favor of per-action security checking vs. "logged in or logged
out, all or nothing".

------
ademarre
This problem is often referred to as _user enumeration_ , which seems like a
misnomer to me.

Whatever you call it, it's good to keep in mind that Google, Apple, Facebook,
and Twitter are vulnerable.

The most interesting facet to user enumeration is privacy. If Alice knows
Bob's e-mail address, is it right that she can easily check with Carol's web
system to see if Bob has an account with Carol? This is like calling a hotel
and asking if a certain person is staying there. It leaks information
confirming that two parties have a relationship.

What makes the privacy aspect especially interesting is that user enumeration
is a bigger problem for small websites than for the Googles and Facebooks.
This is because it's not much of a privacy breach to be able to test if a
given e-mail address is on Facebook; big whoop, almost everyone is. But it's a
much bigger breach to be able to test if a person is a customer of an illicit
service. Most systems sit somewhere between those two extremes, and each needs
to decide whether to prevent user enumeration.

The main point the author tries to make is quite matter-of-fact: _If_ you are
going to try to prevent user enumeration, then you have to do it for real,
which usually results in less friendly account creation and password recovery
systems.

------
allendoerfer
The article does not point out, that not teling visitors which of password and
username were wrong on login pages is a useless measure, it shows that there
is a second way to find out correct registered email addresses on most
platforms (by trying to register them).

This can be easily fixed by sending email conformation tokens prior to
creating the user account and informing users in this email, in case they
already have an account.

------
MAGZine
I don't agree with the author's premise wrt to usernames.

Often, you will login with a _username_ , but the password recovery form will
only accept an _email_. You might be able to correlate these two if you have a
lot of data from other, external attacks, but unless if I noticed correlation
between recovered passwords and account break-ins, I wouldn't worry about
this.

There's a security tradeoff, but sometimes security must be risked in the name
of functionality, or you'll have a lame product. Or, you can have both
security and functionality, but to the detriment of UX.

Take leaderboards for example. If you have a leaderboard for your app/game,
you'll expose user's username (and thus, sign-in name, as is often the case).
You could mitigate this by: having a separate login name (ala steam), or using
an email (which exposes people to the recovery exploit), but it doesn't make
the UX any better.

In the end, I'd say trying to protect against username/email guessing attacks
is probably unnecessary. There are better ways to approach security.

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

------
darrhiggs
The article misses the point that on many sites this is not a security
feature, more a privacy one. I have used the 403 http status rather than 401
in the past for this exact reason.

RFC 7231[0] suggests something similar

 _" An origin server that wishes to "hide" the current existence of a
forbidden target resource MAY instead respond with a status code of 404 (Not
Found)."_

with RFC 7235[1] suggesting the use of 403.

 _" A server that receives valid credentials that are not adequate to gain
access ought to respond with the 403 (Forbidden) status code […]."_

[0]
[https://tools.ietf.org/html/rfc7231#section-6.5.3](https://tools.ietf.org/html/rfc7231#section-6.5.3)
[1] [https://tools.ietf.org/html/rfc7235](https://tools.ietf.org/html/rfc7235)

~~~
darrhiggs
Given that I have received downvotes I'll try more concrete example. Imagine
that you start dating a someone and they discover your email, maybe you email
them. Now they then take that information and try and log into a site that you
do not wish that others know you use, this may be a porn site, it may be a
group that you associate yourself with, say even a feminist forum. Now if you
respond that it's the wrong password people are able to deduce (given that
there is also a wrong username error) that you are a user of that service.

Imagine you put your email on your cv and this is done to see if you a member
of a democrat or republican website, and you are not offered a job based on
your political views.

Imagine that you use your email to sign up for a government service and they
take that email, do as described above, and use the information in the future
to discredit you in some way.

Maybe I have missed the point, but I personally think that this is a also
privacy issue and only looking at it from the perspective of UX may have
undesired consequences for people.

~~~
dllthomas
It is certainly the case that there is a privacy issue here. However, that
doesn't substantially undermine the strongest point presented in the article -
that the email is already exposed, usually by refusing to create a new account
if one exists with that email and it's sometimes also reported when you ask
for a password reset email.

I agree with you that the thing to do is fix those issues, though, rather than
abandon it here as well.

~~~
darrhiggs
I think that could also be solved relatively easily. Just flash that you are
sending an account activation email to the person trying to create an account
and email the already registered user with a notification that someone tried
to sign up with their email address.

~~~
dllthomas
I agree, neither issue is intractable.

------
xborns
As many have said if you simply rate-limit with captcha and block it
complicates checking against all emails via bots etc.

This rule doesn't apply well to say the majority of b2b systems that don't
have account creations public. Thus now I can phish for users and send them
targeted oh reset your password here emails because I harvested them from some
other hack. Remember it is not always the password that is the weak link it is
the user as well.

So calling it useless is shortsighted, yeah for many basic sites it is simple
to say yeah tell them what is wrong. That is why they created the picture
login to go with the email to ensure you are logging in on the right site. If
anything you aren't sure try forgot password with your email.

Source: Real experience building auth systems for large corps.

------
Evolved
I'd be concerned that if hackers found out their login attempts were
increasingly rate-limited (2 seconds, 4 seconds, 8 seconds, etc.) then they
would just use that instead as a DoS attack and run that rate limit up to
weeks or months if possible.

Send email to email address on file stating "someone has attempted to log in
to your account multiple times..." only after multiple unsuccessful attempts.

What about a flat rate-limit of something like 30 seconds (or something
similar) which is low enough that a user likely wouldn't be that irritated by
it, won't be a severe DoS and is likely sufficient enough to hinder
illegitimate login attempts?

------
ColinDabritz
Interesting premise. I think the original behavior is partly correct. The
combination of user name and password doesn't match. Either one could be
incorrect. Say my usual login is steven@example.com, and I do know my
password. If I try to log in as stevon@example.com with my correct password,
it is conceptually NOT the password that is incorrect. The user could
legitimately make such typos, and should probably check both fields.

On the other hand, this is a reasonable argument for prompting on invalid user
names, e.g. "This doesn't appear to be an existing account, make sure you
typed it correctly, or try our [sign up page]".

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

~~~
NoPiece
There are privacy issues though. Take a known email address, run it through
100 sites, and find to find out what kind of sites the person uses.

~~~
btilly
The point of the article is that you already _can_ do this very easily - just
try to sign up to each site.

~~~
NoPiece
That's sometimes true, but not always. Two examples: a signup may have a
captcha, so the cost of filling out the form to check for an email address is
high, or something like a bank sign up, which requires additional info besides
the email address (account number, SSN).

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

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

------
mbesto
> _99.9% of websites on the Internet will only let you create one account for
> each email address. So if you want to see if an email address has an
> account, try signing up for a new account with the same email address._

That's terrible UX.

> _But there 's a tradeoff there between security and UX, I hear you say. I am
> trying to show you there is no tradeoff; you are choosing between a better
> user experience and a worse user experience._

I didn't reach this conclusion at all. Am I missing something?

~~~
andrewstuart2
> That's terrible UX.

I think the goal when the User is a malicious attacker is for them to have a
terrible UX.

~~~
mbesto
Huh? He's suggesting that as a Real User that if you don't whether you have an
account at all is to just sign up again. People use multiple emails for
different accounts all of the time. How is that not a frustrating experience
for the Real User?

~~~
waxjar
That's not what is meant.

An attacker who wants to find out of if the person with "example@example.com"
has on account on your website, could try signing up with
"example@example.com". If they get an error message, they know the person has
an account on the website.

------
kylequest
Silly rant... It would be more useful to explore why a service/site would like
to 'hide' user names... and how it should be done.

If a site/service needs to hide user names then it needs to do a better job
with signups. It's possible to hide user names / emails during signups too and
say: "if you already have an account you'll get a reset password link
otherwise welcome message from us".

------
drinchev
I think this idea might blow a lot of A/B testing and conversion rates. People
would have to check their e-mail address for actually creating their accounts,
although e-mails are already obsolete for even activating the account ( You
can just sign-up and sign-in later with your password you entered ).

May be behind this the author put some good deeds, but in the end I think it's
overkill.

------
anigbrowl
_Unfortunately this assumes that there 's no other way for an attacker to
discover whether a username/email address is registered for a service. This
assumption is incorrect._

No it doesn't. It assumes, correctly, that that involves a bunch of extra work
and that obfuscation raises the economic cost of an attack.

~~~
tracker1
Really!?! An attacker can just as easily write a script to check the password
recovery form before attacking the login form.

You're taking something that is easy to automate and using it as a solution
that makes it harder for people to use.

How many times have you been to a site you haven't used in a while to try
several different passwords, only to hit the password reset form and discover
the username wasn't even correct? How many minutes of your time were wasted?
How much security was actually added?

The answers are... Yes. Too much. None.

~~~
raverbashing
A lot of places have a captcha in their sign up process.

Also signing up usually involves more than a login/password (address, phone
no., etc)

Yeah, someone could do something like "you'll get an email if this email
wasn't registered already" on sign up

~~~
tracker1
You could put a captcha on your login screen once a user from an IP has failed
more than N logins on a given IP address. You could also check for the
existance of a cookie, and not allow logins that don't have it set.

There's lots of things you _could_ do.. but displaying an obtuse error doesn't
add to usability. I was talking about the password recovery screen, not the
signing up.

The "you'll get an email..." is a message I've seen.. and had to deal with it
being broken (the email provider the site used was overloaded/down) .. no
email.. more broken usability...

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

Needless to say, this caused some confusion for users.

~~~
wiml
Wouldn't that also make it impossible to change one's password?

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

------
codazoda
I was convinced until the main suggestion was to, "Consider throttling invalid
login attempts by IP address or subnet."

The rest sounded okay but that seems to indicate that the author probably
hasn't tried to solve the security problem on a busy site.

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

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

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

------
largote
What sites should really say, is what dumb "password restrictions" they forced
you to use on signup. For example sites should have a message that says:

"We are dumb enough to force your password to have at least one
Uppercase/Lowercase/Number/Symbol and it must be at least 8 characters long,
but you can't have consecutive numbers, this may make it different from your
usual password pattern and force you to recover the password every goddam time
you try to use our site".

------
cryptoz
This doesn't address timing attacks, which are why this is done in the first
place. If the code checks only for a username existing and returns the error
message, this takes a measurably different amount of time compared to then
also looking up if the password matches.

The error shown isn't to dissuade people from using web pages to try to gain
access to accounts - it's because the raw code itself doesn't know which is
which, and writing code that does enables fast-paced timing attacks.

~~~
tracker1
I don't see how what you say is really true in a system with properly
hashed/salted passwords.

    
    
        SELECT "Id", "Hash", "Salt" FROM USERS WHERE "Email" = $input
    
        if (results.length == 0) return -1; //No record, bad user, return early...
        if (results["Hash"] != Hash(pwd.trim(), results["Salt"]) return -2; //invalid password

~~~
shabble
If you have an index on your "Email" field in the database, there may be
discernible difference between the time taken to check the index and return '0
rows', vs getting a match and actually reading the appropriate data to build
the result row.

I don't know if there's a solution to that in the general scheme of things,
other than making the variance of query times between no user and some user as
small as possible.

~~~
tracker1
And, if you're returning the correct error message, it doesn't matter.. the
whole point of a timing attack is to determine the difference.

IMHO usability is more important. There are other ways to improve security.
Rate limiting with < N failed attempts via an IP in under < X minutes.

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

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

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

------
matthijs_
Excellent point. However, I think username / password will be (at least
partially) replaced by this:

[https://passwordless.net/](https://passwordless.net/) \- Token based
authentication

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

