Crazy to let the client side determine image count

[Saeven]

Try this code on your demo page

        var captchaEl = $( '#sample-captcha' ).visualCaptcha({
            imgPath: 'img/',
            captcha: {
                numberOfImages: 1
            }
        } );
        var captcha = captchaEl.data( 'captcha' );

The answer will necessarily be the leftmost image.

[BrunoBernardino]

The backend doesn't let the user ask for less than 2 images (it will at least send 2).

The fact it's the front-end that decides how many pages is because your UI will vary, hence it's where the decision is made.

The previous version was controlled by the back-end and people had different needs (and image numbers) according to where they were displaying the captcha (even on the same website, different places).

Also, asking for less than 4 images allows an increased probability of randomly "getting it right", it's up to the developers implementing it to ensure you're not asking for a small number of images.

[Saeven]

I think you were a bit quick to close this case. Remains that the option of how many images to show should be the developer's choice, not the attacker's choice. Under your present code, you could specify 6, but I can simply run your JS again and specify 2 (as evidenced by the snippet I submitted below) to drastically increase my chances of defeating you with brute force.

The count of captcha items should be a server side parameter always, that can't be influenced by an attack.

The fact that your images all have distinct md5 signatures makes it extremely easy to beat this captcha when the two techniques are combined.

With a bit of repair, your captcha would be a great offering, as is though, it is much too vulnerable.

I'm just trying to help! Take it or leave it I guess ;).

Scribbled on my iPhone

On May 6, 2014, at 6:11 AM, Bruno Bernardino notifications@github.com wrote:

The backend doesn't let the user ask for less than 2 images (it will at least send 2).

The fact it's the front-end that decides how many pages is because your UI will vary, hence it's where the decision is made.

The previous version was controlled by the back-end and people had different needs (and image numbers) according to where they were displaying the captcha (even on the same website, different places).

Also, asking for less than 4 images allows an increased probability of randomly "getting it right", it's up to the developers implementing it to ensure you're not asking for a small number of images.

— Reply to this email directly or view it on GitHub.

[BrunoBernardino]

You brought up a very valid point. The biggest advantage of visualCaptcha, security-wise, is the fact everyone can customize it to their needs.

You can easily implement a minimum limit or a valid way to only get X images on a specific page.

I understand your point, but it seems you're suggesting we perhaps increase the minimum number of images in the backend? It's definitely doable. I just don't see another way of having what you're looking for done, while easily allowing differently "sized" captchas on the same site.

[Saeven]

Some things shouldn't be "mutable" though, you have to put your attacker hat on.

I'm not recommending that the back end increase the minimum count, but that instead, the count of images be defined on the back end [only]. This is critical, so that attackers can't increase the efficiency of a brute force attack by decreasing the count of images against the site programmer's original intention.

Having different sized captchas on the back end is very simple. These things should be initialized at the element level, not at the library level (e.g. in a form factory).

I've actually transformed your library into a ZF2 module that does precisely that. I ran into this vulnerability and wanted to report it. Client side configuration == suicide (Javascript == client side).

[BrunoBernardino]

Tbh, this is something I feel can be easily fixed by any developer (increasing the number of images or defining it on a fixed number, ignoring what's coming from the front-end), and so anyone can implement it if they feel is necessary. That's the main advantage of visualCaptcha.

I understand your concern, but your suggestion means it's always X images, no matter where on the site (and I see in your repo it's always 8, which doesn't always fit well, hence hurting the UX, which is visualCaptcha's primary concern), and I don't like that alternative.

I will likely increase the minimum number of images requested to 4 in future releases, though.

[CrazyPython]

@BrunoBernardino If reCaptcha doesn't prompt users for a captcha most of the time (most of the time its just checking a checkmark), and it's easier to implement (less customization), then why use visualCaptcha?

[BrunoBernardino]

@CrazyPython That's a great question. Apparently there are some privacy concerns and others that have been debated in this comment but I'd personally recommend reCaptcha if you have a real security threat/concern. For most situations, visualCaptcha will do just fine, though.

[CrazyPython]

@BrunoBernardino A decent hacker would just use a headless browser framework (ex. Phantom.JS) and set the image count to 2, so he/she could try just a few times and get in. You can make the no. of images the dev's choice, but by putting it on the client side, you make it the hacker's choice. It's like...