5

Is there a reason for sites to ask for another CAPTCHA verification when some other part of the registration form, e.g. the username, was invalid?

  • what you mean with "another CAPTCHA"? it did ask once and then after an failed login attempt, it show one another CAPTCHA? – VP. Apr 26 '11 at 14:37
  • @VP01: Yes (after a failed _registration_ attempt). –  Apr 26 '11 at 14:41

5 Answers5

6

If the site has a means of knowing it's the same user in the same session, then no. So for example given a cookie or an ssl session then it seems OK to assume it's still a human user (within the limits of captcha).

If it's just a cookie that establishes the session (i.e. this is over http without SSL) then make sure to time it out tho. And you should be using SSL anyhow :-)

frankodwyer
  • 1,907
  • 12
  • 13
  • So this wide-spread practice is just the result of lazy programmers? –  Apr 25 '11 at 08:13
  • no if the site, without CAPTCHA is vulnerable to CSRF. The browser being authenticated don't means that the user is authenticated to do this action. Example: http://www.h-online.com/security/Symantec-reports-first-active-attack-on-a-DSL-router--/news/102352 – VP. Apr 26 '11 at 14:33
  • @VP01 - but that is true for every single request. Are you saying that every single request made to the site should have a CAPTCHA? – João Portela May 02 '11 at 14:06
  • @João Portela, i don't know where in my comment i stated that. Do I? – VP. May 02 '11 at 16:01
  • 1
    maybe this was a wrong use of words on my part. What I meant was: You said that the CAPTCHA avoids CSRF and that it should be kept even after the first CAPTCHA was successfully filled, to avoid CSRF. I also assumed that if the registration page is vulnerable to CSRF so should all of the other site pages be (there no reason to make the registration page less secure for the user). From that I inferred that if he wanted to prevent CSRF he would have to use a CAPTCHA on every request. Summing up: **CAPTCHA is not the right tool to avoid CSRF.** – João Portela May 02 '11 at 17:31
  • @João Portela ooh I *so* agree. I'd change that though: **CAPTCHA is not the right tool. Period. for *anything*.** – AviD May 03 '11 at 10:37
6

No. But then, was there a reason to ask for a CAPTCHA in the first place?

Let's take a random example of a platform that implements CAPTCHA; say, Stack Exchange. What Stack Exchange sites want is a collection of high-quality questions and answers on a particular topic. There's nothing there that intrinsically requires humans to supply the questions and answers: they just need to be good. This quality of goodness is determined and filtered for after the content has been published, by the community of voters and moderators.

There's also no guarantee that once you've determined the layer 8 hardware is a human, they're predestined to provide good content either. Indeed that's the easiest way to circumvent website CAPTCHAs: find some poor people and give them not very much money to fill in CAPTCHAs for you.

So implementing a CAPTCHA makes it harder for people (much harder, in some cases, as many CAPTCHA mechanisms are inaccessible to people with sight difficulties) to use the platform, while only making it a little bit harder for people to abuse the platform. In return, you get no useful information related to your goal.

  • 2
    Whether CAPTCHAs are useful or not is a subject of discussion. It definitely raises the barrier of entry to spamming, though. Here, I can't see any advantage at all, and was wondering if I had been missing something. –  Apr 25 '11 at 09:35
  • @Tim, it is only a very slight barrier. Like trying to stop an automobile using marshmallows. It goes back to the point, using CAPTCHA is misplaced in the first place. – AviD May 03 '11 at 10:39
  • @Tim see also this question where the (f)utility of CAPTCHA is discussed. http://security.stackexchange.com/questions/778/anyone-using-asirra-in-production-are-there-similar-alternatives/786#786 –  May 03 '11 at 12:47
  • I hope I could downvote this answer since only its first 3 chars actually adress que question, you should have made it a comment at most. feel free to start a new question to discuss the effectiveness of using captchas to stop spam. :) – João Portela May 03 '11 at 13:34
  • @João: my answer addresses the general question "Why verify with CAPTCHA at all?" of which @Tim's question is a specific case. –  May 03 '11 at 14:27
  • @Graham Lee - if you read the question again you'll see that @Tim implicitly assumes that CAPTCHAS are useful to prevent unwanted registrations, and is just trying to figure why they are requested multiple times when some other part of the registration form is wrong. – João Portela May 05 '11 at 10:24
4

I think the main reasons are:

  • It is the default behaviour that works out of the box. If the programmer has to rememer that the captcha was solved, he will have to write extra code. And it has to be remembered in a way that cannot be manipulated by the user (e. g. the session), so a <input type="hidden"> field with a flag is no good.
  • After validation of personal information has failed once or twice and the users have to reenter the captcha every time, it gets really annoying. So people are more likely to provide real personal data instead of fake data. (This item only applies to company that ask about a lot of personal information that is not strictly required to offer the service the user is looking for.)

As far as usibility for picking usernames is concerned, I suggest to check them right away using Ajax before the form is submitted. Alternativly you can use email addresses which are (mostly) unique.

Knowing the username may make it easier for an attacker to crack passwords: A smart attacker, who is not interested in one particular account, will pick a password and then brute forces through usernames. So that is something to keep in mind, unless you have a public user directory anyway. Even without a user directory, there is a set of usernames that are likely picked by people. So a rate limit for failed login attempts is required anyway in order to prevent this kind of attack.

Hendrik Brummermann
  • 27,118
  • 6
  • 79
  • 121
3

That will completely depend on what the purpose of the form is, i.e. what kind of information is being collected.

One very common case is a login re-try after a failed login on a website. In this case the CAPTCHA serves a dual purpose:

  1. It's making it harder to automate login attemps with a bot, thus making it harder to automate a password guessing attack, and
  2. It is slowing down login attempts; making an online brute force attack harder to mount. (Note, this shouldn't be left to the CAPTCHA alone, the backend authentication system should have rate limiting and/or max failed login attemps handling.)

It's also common that the entire form has to be re-submitted if just a single field was wrong. There is really no good technological reason for that, it comes from not prioritizing usability. Using SSL, sessions and CSRF protection tokens the webapp can reliably know that the end user solved the CAPTCHA in his first attempt, and then not require CAPTCHA again -- but it's more work to implement this correctly.

Community
  • 1
  • Sorry, I forgot to mention that I was thinking about registration forms. –  Apr 25 '11 at 08:12
  • 1
    Disagree strongly with that - the purpose of a captcha system is to verify the user isn't a bot, and that's it (and obviously these systems have limited effectiveness too). But concerns should be separated. Avoiding password guessing is better done via a measure specific to that issue, e.g. back off delays. – frankodwyer Apr 25 '11 at 08:14
  • @frankodwyer: I didn't say that a CAPTCHA should be the *only* rate limiting mechanism, that's your reading. :-) But I will make it more clear. –  Apr 25 '11 at 08:17
2

The reason to change always the challenge is to make harder for bruteforce attacks. Imagine that the CAPTCHA don't change after the first failed try. So a hacker could first try manually to fill in the form, introduce the right challenge and then start a bruteforce tool, that fills the input box form the captchas always with the same value making the CAPTCHA useless. It is useful to create, for example user mass creation in services like for example, gmail.

VP.
  • 1,043
  • 1
  • 11
  • 12
  • Why would you brute-force a registration form? –  May 02 '11 at 06:19
  • i fixed my answer :-) – VP. May 02 '11 at 10:29
  • I understand that the CAPTCHA should change after a successful registration, but what about failed ones? –  May 02 '11 at 11:19
  • 1
    for example, forms that allows the hacker to do user enumeration. e.g: if in the error message you can identify if the user that you are trying to create already exist. You can use it to find valid users and then do a more precise bruteforce :-) – VP. May 02 '11 at 13:51
  • usernames are not supposed to be private, being worried that people could now your username is like being worried about people knowing your public key: from a security point of view they are not supposed to be a secret. – João Portela May 03 '11 at 13:37
  • maybe in YOUR application it shouldn't be secret. But in other applications, where the user name a social security number is the user, maybe for privacy the stakeholders want that as well private. – VP. May 03 '11 at 20:41