Live data from Hacker News

“Invalid username or password” is a useless security measure

kev.inburke.com

111–120 of 188 posts

Re: “Invalid username or password” is a useless security measure

#111

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.

Well you can at least inform the user that the username is incorrect if there is no user by that name.

You would still have the issues described in the OP. If it says "username incorrect" only when that user does not exist, you can still figure out a username by just trying them with a random password. If you get told "password incorrect" you know the username you just tried already exists.

Re: “Invalid username or password” is a useless security measure

#112

> 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 accomplishi…

I have to agree with the parent here... There are other ways to add security, and having an obscure error message doesn't really improve things by as much as the error message can cause real users to go down the wrong path.

Who are you "agreeing" with? Neither me nor the article is arguing for inexact error messages. We both agree that registration pages leaking that information make hiding if a username is correct a pointless exercise.

On that point me and the article are in complete agreement.

Re: “Invalid username or password” is a useless security measure

#113

Earlier quoted context omitted.

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.

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.

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.

Re: “Invalid username or password” is a useless security measure

#114

Earlier quoted context omitted.

What I'm saying is that every "signup" event should appear as if it was a valid, brand-new signup as far as the web user is concerned. The email will be sent regardless. If it's a valid new signup, then the user gets a transparent experience. If the user has already signed up, send them a helpful "hey, you've already signed up" message in their inbox. In case it was an attacker, maybe check the IP against known IPs t…

You're ignoring that most modern apps will give you rudimentary account access even before you confirm your email address. Which would be difficult to do if that account already exists.

My answer to this problem would be to let them in anyway. Store all session data with a cookie or (brand new) UUID, perhaps persisted via localstorage for the long-term users.

The email should still indicate new or existing user, and provide them a link that they can use to associate said UUID with their login and pull all the data onto their account as if they'd been logged in the whole time.

They'd need to be informed that all account data is accessible only on that computer, at least until they've confirmed their email address. I kind of imagine this is the existing behavior for many applications, though.

Additionally, if the service doesn't require emails to be authenticated, then they shouldn't be using them for much more than account recovery or notifications (once authenticated). Otherwise, I can sign up for that service with somebody else's email as long as they haven't signed up before, and then if that person ever wants to sign up for this service, either they're out of luck or the original (perhaps misguided) customer is out of luck.

Re: “Invalid username or password” is a useless security measure

#115

> 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 accomplishi…

Exponential backoffs also have the problem that it makes it far easier to lock someone out of their account. Or rather, it makes it possible to lock someone out of their account for an arbitrary amount of time. > When a password is set check it isn't in a common password dictionary I agree with this with short passwords . But for passphrases? No. I find it rather frustrating that (ex) diceware passwords are often rej…

> I agree with this with short passwords. But for passphrases? No. I find it rather frustrating that (ex) diceware passwords are often rejected as too insecure or flagged with a nasty warning.

I too have ran into that issue. Instead sites doing:

     password.Trim().Equals();
They do:

     password.Trim().Contains();    
So if you do a pass-phase or full sentence they'll call your password insecure for being a common dictionary word (even if it is 20+ characters long).

That's why score systems are better overall than any one single check. All parts of the password should be considered (e.g. length, complexity, commonality, etc).

Re: “Invalid username or password” is a useless security measure

#116
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?

Re: “Invalid username or password” is a useless security measure

#117
post #92

> 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 accomplishi…

> 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/ ), your password will be effectively truncated at 72 characters.

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.

Re: “Invalid username or password” is a useless security measure

#118
post #110

Earlier quoted context omitted.

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.

Let them signup again. Then send them an email asking that they signed up for a second time and if they wish to update the existing information with the new information provided in the "fake" signup process.

The I, as new user, if I mistype my email, will just have filled whole form for nothing (and possibly just gave away my information to someone)

Re: “Invalid username or password” is a useless security measure

#119

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 m…

That will cost you dearly in terms of user retention.

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).

Re: “Invalid username or password” is a useless security measure

#120
post #63
post #58

Earlier quoted context omitted.

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.

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

But there's no good reason to have a username at all unless users interact with each other or the web-going public, in which case the username is a public part of the URL. Services like twitter or github need @usernames. Other services should just use email addresses.
Post reply on HN