8

I am working on a site and I would like to add CAPTCHA to the user registration page to prevent user name enumeration.

I am working with a front end developer who feels pretty strongly that we should not add CAPTCHA to the registration page because it's a pain for users and will reduce our conversion rate.

I know that there is sometimes an inverse relationship between the security of a site and the usability of the site and that some security vulnerabilities are worse than others.

If there was something like a SQL Injection vulnerability I would insist that we fix it, but I'm not sure if a user enumeration vulnerability is serious enough to justify me fighting for this particular fix.

How important is it to have CAPTCHA on a registration page and how seriously should user enumeration attacks be taken?

Abe Miessler
  • 8,155
  • 10
  • 44
  • 72

3 Answers3

6

My personal experience with ReCAPTCHA (widely regarded as being one of the best) is that it took about a week after we added it before the spammers we were trying to prevent figured out how to solve them.

They don't solve 100% of the presented images correctly but they don't have to. Even getting one in every ten correct would be fine for them and they are doing better than that. They are probably doing better than our customers.

There are some alternative styles of CAPTCHA that involve playing games or selecting the picture of a kitten out of several images. These types of CAPTCHA have not yet seen any serious attention from dedicated spammers.

User enumeration may not be a solvable problem, depending on the design of your site. In the case of a forum, an attacker simply needs to visit the forum and note down the usernames he sees attached to every post.

If anyone can register to the site, the registration process will have to notify the potential user that the name they have chosen is already taken. A CAPTCHA will probably change the equation for an attacker here because the cost of solving it and the failure rate compared to the potential value of the enumerated credential would probably mean that it's not worth the effort.

Since usernames are generally the non-secret part of the credential pair, even figuring them out usually doesn't have much value for an attacker.

Ladadadada
  • 5,163
  • 1
  • 24
  • 41
  • With the format of the site, adding CAPTCHA to the registration page would be an effective way of preventing enumeration. – Abe Miessler Sep 12 '13 at 16:04
  • A subtle correction: the CAPTCHA adds a cost to credential enumeration. If the value of the username goes up, the equation changes and it may be worth the effort to solve the CAPTCHA. – Ladadadada Sep 12 '13 at 16:12
  • Good point. Regarding your comment that user name's don't provide much value to an attacker: since discovering users names could be the first step in attempting to brute force attack their passwords, would you say that brute force attacks on passwords are not a huge threat? – Abe Miessler Sep 12 '13 at 17:11
  • Against a live website, no. Unless your website is quite large (I'm talking about hundreds of servers) the traffic and excess load caused by a dictionary attack will be setting off alarms all over the place. I once caught an in progress dictionary attack targeting a single user precisely because it showed up so heavily in the logs. It was only up to 'b'. – Ladadadada Sep 12 '13 at 18:47
  • Harvesting usernames is a very, very, serious issue. Not only does it represent a very good way of decreasing the search space for brute force username/password attacks, but many people use their username as a basis for their password (maybe foolish, but very common). It's also the source of many successful phishing attacks (usernames are often email addresses or email addresses can be easily inferred from them), and they also represent a privacy issue (they can give you information about a user and which sites they visit and register for etc.) In all harvesting usernames is a VERY BAD THING. – David Scholefield Sep 12 '13 at 19:14
1

Regarding user enumeration, you can mitigate this particular threat without human verification by:

  1. Decouple the login username from any other user detail (email address, pseudonymous identifier, any public "about me" attribute). Banks do this by giving the customer a login number completely detached from any other number or detail of their account. For example:

    • Provide random login usernames that the user can not change. The key point is that the system provides the username or the user can only chose long random usernames; otherwise account creation is an opportunity to guess existing names.
    • Warn users when they are including their login user name in posts (assuming the usernames weren't salted and hashed).

  2. Lie on any public query or form that can infer information about users in the system:

    • Always say access denied. Never say why.
    • Always say "password reset sent to nominated address". Never say that this is impossible because the user doesn't exist.
    • Never have a View User Profile feature that uses their login name as the query ID. Use a surrogate key such as their presumably unique pseudonymous forum handle.

Every field used in authentication has much the same limitations as the password itself.

An alternate unorthodox approach would be to not have login usernames.

Accounts are created and accessed using only a password. Hence people are encouraged to have as long and random a password as possible if they don't want someone else logging into their account. A user's name in the system is used for member interaction, not authentication.

It is no less secure than someone brute-forcing both a login username and a password, since most usernames add only few extra bits of entropy; which would be more intuitively recognised by the members if they only had a password. People who record a username/password pair on a monitor sticky note are revealing the essential truth that these data attribute pairs are merely an atomic authentication unit arbitrarily sliced into two or more pieces. A login form that had 5 input boxes labeled "Number A; Number B; Number C; Number D; and Number E" would no more or less secure than 2 input boxes labelled "Username; and Password".

This also makes the simple point that password recovery in this day and age can and perhaps should be the responsibility of the user, not the website. Using an email address as a de-facto post-hoc password manager collapses all site security down to whatever entropy is in the "secret question/answer response" for recovering or resetting that email account's password. It also makes email accounts much more tempting targets to hackers than they otherwise would be - email addresses were never designed to be secret, especially over the wire.

LateralFractal
  • 5,143
  • 18
  • 41
  • +0. You wrote: "Always say 'password reset sent to nominated address'. Never say that this is impossible because the user doesn't exist." Such a tactic is ultra-confusing for users who forgot which email address they registered with. Instead, may I suggest that you [edit] your answer and replace your idea with a better idea. Perhaps this might work: "Always say 'email sent to nominated address'. If the nominated address exists, send it a password-reset email. If not, send it an error message saying that no such account exists." Once you've done so, please flag my comment as "obsolete". – unforgettableidSupportsMonica Aug 22 '16 at 21:03
  • @unforgettableid this would allow me to spam you freely, even if you never signed up on OP's site! I would phrase the mesage in conditional: We have sent an email to this email if they have an account on this site". – Ángel Jan 22 '19 at 00:31
-2

Captcha are used for preventing any script or bots for requesting your server, They ensure that the request is from the human only.

If you do not want captcha in your forms, you can use token mechanism and provide token at form load in hidden feilds whose value is sent along with form data and you can process the token for authenticity before processing the form data.

Vishal Chawla
  • 27
  • 3
  • 1
    The second part of your answer is wrong in this context. A token in a hidden form field can easily be read by an automated script and does not protect against these kind of attacks. The only benefit is that the attacker needs one more request to get the token initially each time. – Demento Sep 13 '13 at 12:57
  • @Demento... can the attacks be prevented if we store the token in session also at time of loading it in form's hidden field and match the token received with that in session, i guess the attacker script won't be able to get the token from my session – Vishal Chawla Sep 13 '13 at 20:57
  • @Viashal Chawla: An attacker in this scenario can easily simulate everything the browser does. This means he can use a valid session and also include the hidden form fields in his requests to the server. Therefore this does not offer additional protection. To avoid automation you need a challenge that is not easily solvable by a computer, like a difficult CAPTCHA. – Demento Sep 15 '13 at 15:57
  • yes i agree, but... by this we can only make it difficult for a hacker to break the security :) – Vishal Chawla Sep 16 '13 at 04:37