Hacker News Reader

Comment by jsnell | Hacker News Reader

There's a good reason for what you're identifying as misuse.

If you show a captcha after a failed password, you need to show a one after a correct password as well. Otherwise you leak information. You can have other solutions, e.g. in a login flow that splits the username and password entry, it's advantageous to put the captcha between those two steps. But even in those solutions the display of the captcha must be independent of password correctness.

View on HN

There's a lot of arguments against captchas, but I do not agree with this one. You will always leak whether or not a password is correct based on how your app behaves - a correct password will grant entry to the application. If you only ask for a captcha when a user account exists but fail to ask if they use a made up username, that's an information leak.

The trick is to ask for captcha before validation.

> If you show a captcha after a failed password, you need to show a one after a correct password as well. Otherwise you leak information.

Presumably, if the person has entered the right username and password they're going to get access to the service at which point they'll know they entered the right one. What information exactly is leaked here?

The reason you'd want a captcha on a login page is to protect against brute-forcing of some sort. For example credential stuffing or a dictionary attack.

The information the attacker is looking for is the validity of the password. If you want to use a captcha to protect against this, the outcome must be the same whether the password is valid or not. Because if you only show the captcha for failed logins, the attacker can find out that the password was incorrect without solving a captctha, which by symmetry means they can also find out if it's correct without solving one.

Usually when you Captcha on a failed attempt, you captcha every request from that IP (or other session identifier) for a period of time. Try Google Accounts for instance. They behave this way.

You don't captcha the success path because you don't need it. You captcha the pre-login flow once you have a failed attempt. It's a trip switch that is a prelude to the flow.

But this entire thread is about a case where the captcha happens after password entry!

The point is that it is an entirely legit design, and kind of is the way you have to go when the username and password are entered together. As long as the captcha is shown regardless of the password validity, both the security properties and the amount of user annoyance due to having to solve unnecessary captchas is the same as if you had had to pass a captcha up front.

The example of Google Accounts is interesting, because they use split username and password entries. So there is indeed a natural point in the flow to show the captcha between the username and the password, which is what they do. But at least up to a year ago they were doing it after the password. So enter username + submit, enter password + submit, and if the login attempt was sufficiently dodgy get shown a captcha regardless of the validity of the password.

Sorry, because of how common the method I described is and how absurd the idea of showing a captcha only to give you a login failed message is, I "corrected" it before responding.