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?
|
|
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 :-) |
|||||||||||||
|
|
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. |
|||||||||||||
|
|
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:
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. |
|||||||||
|
|
I think the main reasons are:
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. |
|||
|
|
|
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. |
|||||||||||||
|
