Visual Confirmation

[NeoThermic]

i didnt bother to mention it in my previous post, because i thought it is not material to the goal (producing a random string).

Of course thats the goal. Anything that can be perdicted makes a captcha weaker. Your code doesn't do replacement, so that means that the maximum combinations it can do for a 6 character code (the default in phpBB 2.0.x) is 1,168,675,200, while the current code generates a maximum combination space of 1,838,265,625. In short, you've just knocked out over 6.6 million combinations the captcha can come up with, and given a nice easy clue for the captcha breaker (along the lines of "If I've already used a character, I know that no other character can be this one").

Don't forget, half the battle in solving captcha's with a computer is to reduce the problem down to something easy. If you've limited yourself in any way (non-repeat, two colours, simple noise, fixed character position, set numbers of characters/numbers in an image (I've seen this one before!)), then you make it so much simpler to the attacker, much in the same way a password that is less than 7 characters is easy to break.

NeoThermic

[{o}]

What about blind people? Are you going to implement sort of vocal confirmation as an alternative? But this is problematic too. If the speaker is english and i don't know english? And both are able to break.

What about some methods that are not onerous for user? For example - making the names of fields more fluid? Instead of name="username" - name="av4fhsD". This would stop bots that simply find a phpbb scripts and send hardcoded HTTP request creating an account without analyzing the form.

[Acyd Burn]

What about some methods that are not onerous for user? For example - making the names of fields more fluid? Instead of name="username" - name="av4fhsD". This would stop bots that simply find a phpbb scripts and send hardcoded HTTP request creating an account without analyzing the form.

Now, this would be an interesting approach to follow. Anyone interested in discussing such possibilities further?

If this being done, a bot could of course only add an additional step, scanning the page and then submitting the request. Though it has to be made sure the name is changing again on every pageview - similar to what we do with the confirmation at the moment.

[SHS`]

Now, this would be an interesting approach to follow. Anyone interested in discussing such possibilities further?

If this being done, a bot could of course only add an additional step, scanning the page and then submitting the request. Though it has to be made sure the name is changing again on every pageview - similar to what we do with the confirmation at the moment.

I actually thought about doing this on my own contact form on my site, then quickly realised any "automagic" form filling by browsers would be broken, since there would be no consistant form names.

Of course, a way to do it would be a further hidden field with a randomised value pair...

[dhn]

I actually thought about doing this on my own contact form on my site, then quickly realised any "automagic" form filling by browsers would be broken, since there would be no consistant form names.

Well, this only happens on registration, so breaking the auto-complete should not be a big problem. You are only seeing it once anyway. I think it is worth the gain of one more barrier.

The problem as Meik notes is, that with a page load before submitting the information, a bot can simply use the order of the fields. Unless we make it random of course, which would break usability. Unless we add a number of more random fields that we can simply hide with CSS.

[Xore]

Unless we add a number of more random fields that we can simply hide with CSS.

I think using CSS for functionality is a bad idea. You have to deal with cross-browser compatibility issues, and accessibility (which will likely be a bigger problem?). It seems to me that using CSS in this fashion is an ironic inversion of it's purpose: CSS separates the styling from the functionality... yet now you're moving functionality into CSS also.

[R45]

I do not really think changing the form field names will do much against bots, as the order of fields as well as the exact text in the language packs and the general layout of the html could be used by the bot to determine which field is which.

I do think however that the CAPTCHA needs improving. Some of the things I can think of:

• Randomise Colours - Right now, the text of the CAPTCHA is constant and easier for a bot to recognise. I'd like to see a variety of colours used on different sides of the colour wheel, for both the background and lettering.
• Alternate Fonts
• Font Deformation - Add a random algorithm to alter the formation of characters, however not to a ridiculous extent where it isn't human readable
• Different CAPTCHA Spins - Example, have a CAPTCHA with 20 characters in various colours, and ask the user to input the characters of a specific colour, eg ABCDEFGHIJKLM and ask them to enter all the Orange characters

Just off the top of my head. I could also think of expanding the whole area where users can design their own captcha, where they can for example, set custom background images for the text to further randomise the process. I think any developments in the area has to emphasize making no two phpBBs exactly the same, because regardless of how complex an algorithm is made, anything constant can probably just be reverse engineered in a script because the code is there to see. Having the user's being able to significantly alter the process (eg they can decide in the ACP what characters would be used in th CAPTCHA, foreign languages can add all sorts of variations) and having some randomisation done at installation time will help.

I however wouldn't even support using case sensative characters, because it can be very confusing to casual internet users. It's a hard balance.

[{o}]

I've just invented an other variant - randomize the... address of registration page Now bots have to determine which link on the main page is the registration link.

The problem is that bots evolve. Even the visual or vocal confirmation can by bypassed by computer algorithms - OCR, AI... Look for example here: http://sam.zoy.org/pwntcha/" target="_blank Efficiency against current phpBB - 97%

I think the only we can do is changing the methods time after time...

More on this topic at W3C: http://www.w3.org/TR/turingtest/" target="_blank

ABCDEFGHIJKLM

Which are orange? Daltonists are even more numerous than blinds.

[R45]

Which are orange? Daltonists are even more numerous than blinds.

The option for the Administrator to manually approve the user (via email or a form) is always there. No possible way of significantly preventing automation without having to hand-hold some people for whatever reasons. Should be part of an Administrators functions, and toggable options are the answer if they want to vary the CAPTCHA process.

[Xore]

• Randomise Colours - Right now, the text of the CAPTCHA is constant and easier for a bot to recognise. I'd like to see a variety of colours used on different sides of the colour wheel, for both the background and lettering.

This tends to work pretty well, although if your algorithms for color generation are weak, then it can be difficult for the user to read, especially if it mixes into the background.

• Alternate Fonts

Also good, but this requires ttf libraries generally. We can't even guarantee everyone has GD installed, much less ttf/tf

• Font Deformation - Add a random algorithm to alter the formation of characters, however not to a ridiculous extent where it isn't human readable

This is often good, however the built in php/gd/ttf libraries only support text rotation. Any more complex "deformations" almost exclusively require resampling. This makes me a sad camel.

An alternative is to parse the ttf files directly instead of using imagettftext(). So far, i'm not sure how to go about doing this.

• Different CAPTCHA Spins - Example, have a CAPTCHA with 20 characters in various colours, and ask the user to input the characters of a specific colour, eg ABCDEFGHIJKLM and ask them to enter all the Orange characters

These seem like a good idea, however, on closer look, you run into the old i18n/l10n problems of having the text to describe the color image. The alternative is to embed the color information into the page (perhaps obfuscate via css?) to show the user without words, but often then you're just giving the adversary a free hint about what they should be looking for.

Per-forum captcha configuration is most definately a good idea, something i've been working towards already. did you have any other ideas?