Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

From a UX perspective, CAPTCHA's are bad, bad, bad.

But let's say we have this as a requirement. And it's for a hybrid app (compiled app, but built upon an HTML5 platform).

I'm trying to find out:

  • is bot traffic from an iPhone (or Android device) actually a problem? (or--my theory--is this an outdated hold-over requirement that has been cut-and-pasted into technical requirement documents since 1998?)
  • If so, are there better alternatives that are mobile-centric over yet-another-annoying-CAPTCHA?
share|improve this question
1  
Would using something like Google Authenticator be a possible alternative? –  Evil Closet Monkey Feb 7 at 17:09
3  
Where there's an API, there's a way... –  Roger Attrill Feb 7 at 17:18
7  
If your app has no CAPTCHA, my emulator can bot it. –  WChargin Feb 7 at 22:56
3  
@PatrickM The goal of a CAPTCHA or any other method to limit bots is to make it difficult to code for. The method does not need to be perfect just better than most. As the old saying goes you don’t have to run faster than the bear to get away. You just have to run faster than the guy next to you. –  stoj Feb 8 at 13:18
2  
Can you tell whether the requirements were written by a thinking human or a robot? –  Paul Gregory Feb 9 at 23:14
show 9 more comments

13 Answers

With regards to your question of whether a bot can actually go and submit a form automatically, this is what I found on an answer on Stack Overflow.

It is comparatively harder to automate data submission within native apps. This is due to the fact that you cannot just write an automated script to discover elements within the source code and then mimic form submission. Also, you'll need to (purchase and) install the application (on a physical device or in a simulator).

That said, one of the comments actually suggests that form submission is much easier on mobile.

It's much easier to do it for a mobile app as they usually talk to a REST API (or some other well-defined API), you don't even need a scraper.

So with regards to your question I dont have a definite answer yet about whether CAPTCHAs are needed.

That said, with regards to CAPTCHAs for mobile devices, there are a number of interesting approaches which have been suggested.

  • The slider CAPTCHA: Luke Wroblewski suggests using a slider CAPTCHA to involve human interaction and prevent automatic submission of content. To quote the article:

    Instead of the distorted text strings that typify most modern CAPTCHAs (above), the sign up form on They Make Apps uses a slider that asks people to: "show us your human side; slide the cursor to the end of the line to create your account." Moving the slider to the right completely submits the form and triggers error validation just like a standard Submit button would.

    The slider CAPTCHA

    While the above option is web based solution, the easy slide interaction would fit into the mobile paradigm and would fit into the design as well.

  • Another option is to use image recognition to beat automated form submission. This would scale within the design of the app and would also be friendly as the user can click and select the right option. An example of this is given at this link.

    Image recognition CAPTCHA

  • MotionCAPTCHA: Another option I found requires the user to trace a path on the screen to complete the CAPTCHA. To quote the article:

    MotionCAPTCHA is a jQuery CAPTCHA plugin based on the HTML5 Canvas. It is requiring users to sketch the shape they see in the canvas in order to submit a form. It could be an awesome alternative to mobile captchas mobile users will surely appreciate that they don’t have to input those tiny numbers.

    MotionCAPTCHA

  • Ring CAPTCHA: This one is an interesting one which requires you to provide a phone number to validate your submission and either sends a text message or calls you to provide a pin code for validation.

    Ring CAPTCHA

  • NuCaptcha: NuCaptcha is another option which uses the traditional CAPTCHA model but is optimized for mobile devices. To quote this TechCrunch article:

    The mobile version of NuCaptcha includes the same simplicity as the web version. But the new optimized mobile Captchas provides a consistent user experience on multiple devices. For example, when a user clicks on a mobile touch screen to solve a Captcha, it will fit perfectly into the space left by the keyboard so that the Captcha can be quickly and easily completed. NuCaptcha does not require Flash or JavaScript; and the company expects to release the HTML5 mobile version of its Captcha technology in early Q4 2011.

    NuCaptcha

That said, none of these options would prevent a human being who is paid to be a CAPTCHA breaker.

share|improve this answer
4  
@VoronoiPotato I am not very technical but how does that prevent automated bot submission ? –  Mervin Johnsingh Feb 7 at 18:52
5  
Some of these would prove problematic for blind users. Still a good answer, but I'm just sayin'. –  mikeTheLiar Feb 7 at 20:38
7  
How does the drag-a-slider one work? I can't see any way it could be used to differentiate humans from robots. –  Robert Feb 7 at 22:08
8  
@MervinJohnsingh I would just short out the whole script. A real capcha has to be enforced on the server –  Andrey Feb 7 at 22:41
3  
@MervinJohnsingh If the bot is running in a native environment then it would already be doing taps and drags just to get around. If the bot is talking directly to the API then it would depend on what was being transmitted. What characteristics of a drag would tell you if it was done by a real human finger or just a bot emulating one? –  Robert Feb 7 at 23:41
show 16 more comments

Snapchat recently added image recognition:
(http://venturebeat.com/2014/01/22/snapchat-find-the-ghost/)

enter image description here


Note:
As most captchas, this is also breakable.
But until your app becomes a popular target, this is a pretty nice alternative ;-)

share|improve this answer
6  
I like this. Not only do you prove you aren't a robot, you are enhancing your brain function. =D –  Code Maverick Feb 7 at 18:40
4  
But do see this: kaggle.com/c/dogs-vs-cats . . . . current leaderboard scores (recognition accuracy of 94% making basic use of open-source software) are starting to show that robots will have image CAPTCHA's covered in a few years. –  Neil Slater Feb 7 at 19:43
5  
Ah, it has only the image of the obvious ghost up above the directions. That's stupid; presumably the target will always appear there? You're giving the bot software the solution, all it has to do is look for resized/rotated versions of that... –  Izkata Feb 8 at 3:13
2  
Oh dear I hadn't spotted the tell tale image yet that @Izkata mentions... That really needs to be removed! –  Marjan Venema Feb 8 at 11:55
8  
This captcha was already cracked, see here. –  André Feb 8 at 13:57
show 4 more comments

Rather than asking the user to answer a question or choose a correct picture or enter something, another option is to simply delete something from a regular text field.

enter image description here

From an implementation perspective at least, it could not be easier!

share|improve this answer
2  
I really like this idea –  Mervin Johnsingh Feb 7 at 21:53
5  
While I did see this approach on a lot of pages, I don't think it would be hard to circumwent this once a robot is trained to do it. –  SztupY Feb 7 at 22:21
    
It's true, a trained robot might not have too much trouble, and often it is a case of staying one step ahead all the time. With that in mind, some variation in the wording and the position within the form might help a bit. Leave this blank unless you are a...Womble. Don't leave this blank unless you are a...Human –  Roger Attrill Feb 7 at 22:47
    
It's nice, but will only work as long as bot developers haven't yet picked up on the words used to tell a human to leave the field blank. –  Marjan Venema Feb 8 at 11:51
1  
Well, this field could use a very suggestive name in the markup (e.g. <input type="text" name="username">), though it would detriment page maintenance. It could also be applied some styling so it is visually overlapped by another field, but still looks right to a conventional bot. Of course, depending on the level of interest from the attacker, this would be relatively easy to circumvent. –  Kroltan Feb 8 at 17:00
show 5 more comments

Is bot traffic from an iPhone (or Android device) actually a problem?

The problem is not so much 'from an iPhone', but rather that the API you are talking too needs to be protected. At the underlying IP level there is not much you can do to prove what a remote device is, for HTTP it is really just the headers or form data, which a Bot can generate easily. Ie, I don't care what your UX is, I will attack your API directly.

Since you are specifically asking about native apps, a more programmer like approach to your problem would not involve the user, but rather encrypt your payload using a public/private key scheme before transmission. As only your app has the key, bots that attack your API directly are thwarted. Note, I really mean encrypt your payload before sending, not just using SSL (which is not really authenticating the application, but protecting data in flight).

Of course the problem with embedding keys in apps is that apps can be reverse engineered too.

In our lower security apps we have a table of a few hundred keywords and apps (which are often html hybrids) are required to transmit several of these with http form requests. Which ones are to be selected is based on current date using an algorithm that both client and server know. It is then transmitted using ssl. Not perfect, open to reverse engineering of the app, but simple enough to implement.

For higher security apps we store device specific keys on every device rather than a common table, and the server watches/tracks carefully every key use. Of course this isn't practical for mass delivered apps.

share|improve this answer
add comment

Honeypot

Since you mentioned HTML5, I'm a big fan of the honeypot approach. Most of your users won't even know it's there. Use all four of the following input fields which you must validate server-side on submit:

  • Required, hidden by CSS
  • Must be null, hidden by CSS
  • Required, hidden by JavaScript
  • Must be null, hidden by JavaScript

The required fields should already be filled in. The fields that must be null should be creatively named "Contact number" or something that a bot would likely assume is a genuine field. Just remember not to use input names that are already in use!

If the user has CSS or JavaScript disabled, you must explain what is required for the submit to be successful, such as "Leave this field alone" or "Leave this field blank".

Note: These must be out of sight but not hidden from the browser entirely, otherwise they won't even register. Test thoroughly!

share|improve this answer
1  
The honeypot (hidden by CSS method) is indeed great for catching bots. However, I have found that it can occasionally catch real users who allow their browsers to autocomplete form fields (maybe not applicable in a mobile app) - the browser is just another bot. So, on the web at least, you really need to prompt the user with a secondary captcha method in such situations if you want to completely automate this. –  w3d Feb 10 at 18:02
    
You can turn autocomplete off. –  rybo111 Feb 10 at 18:40
    
Yes, we can, but many users don't and it is often enabled by default. Some end users don't even know how to turn it off or even what it is. –  w3d Feb 10 at 18:51
2  
I meant you can include autocomplete="off" on your inputs. Most (all?) browsers support this. –  rybo111 Feb 10 at 20:57
    
Ah yes - of course - thanks! :) –  w3d Feb 10 at 21:55
add comment

Please DO NOT use most of the examples in the upvoted answer, they completely exclude people with a wide range of impairments (image recognition is useless if you're blind, metaphorical association is useless if you're autistic, maths questions are useless if you're discalculaic etc etc), and they also do nothing at all to remove the problem of humans working in captcha-farms.

Basically, if your verification requires a different type of skill than your content, you're unnecessarily excluding people.

There are other methods available that do not have this disadvantage, such as askismet, honey pot, or if you have something that people really are willing to jump through hoops for, SMS verification.

If you are absolutely set on offloading the responsibility for fixing your site's security issues onto your users, at least offer them a choice, and by choice I don't mean the abysmal 'audio' versions as seen in reCAPTCHA (reCAPTCHA seem to have overlooked the fact that the most common reason for vision impairment, old age, often also results in hearing impairment). So provide multiple CAPTCHAs, and let people choose whether they would prefer to answer a simple question, recognise an image, etc.

Or alternatively you could, as some companies do, simply accept the security issues as your own problem, dispense with user-side attempts at protection, and just accept the implications.

share|improve this answer
1  
re: your last paragraph...we can dream... :) –  DA01 Feb 9 at 4:36
add comment

You could use honey pot fields.

They provide a field within the form that is hidden from the user but designed to be noticed and filled in by any given bot.

They can be as simple as a field called 'phone_number' hidden with css. The bot doesn't process the css and sees the field, but the user doesn't.

This would work on both desktop and mobile and has been in circulation for quite a few years now.

Some more detail, including comments that cover accessibility concerns: http://haacked.com/archive/2007/09/11/honeypot-captcha.aspx/

Here Smashing Magazine outline this in more detail as well as dealing with some other Captcha methods:

http://coding.smashingmagazine.com/2011/03/04/in-search-of-the-perfect-captcha/

They also cite social login, image recognition and friend recognition as other more modern methods, all of which could be implemented nicely on mobile, as well as showing in their poll that honeypots are the next most popular choice for their readers after traditional web form Captchas

PS a honey pot field is actually also a CAPTCHA, which stands for 'Completely Automated Public Turing test'. Learning about this principle may help with a general understanding of the underlying ideas.

http://en.wikipedia.org/wiki/CAPTCHA

share|improve this answer
    
So, the big question, is a honeypot seen by a bot when it's attacking an app (vs. a web site)? –  DA01 Feb 7 at 17:22
    
technically I wouldn't know, but presumably the principle, or at least one of the mentioned principles, could be adapted technically to fit the case? –  ColinSharpe Feb 7 at 17:25
2  
This is great for the web and what I typically do just because it's so simple. That said, it wouldn't stop bots that do parse CSS. Some easy checks are display: none;, display: hidden; height: 0;, width: 0;, position: aboslute; paired with a huge ABS number in one of the top, bottom, left, or right properties. –  Code Maverick Feb 7 at 18:22
    
I think that there are also tricks with hash codes and JavaScript that can augment the honey pot idea, though the link eludes me –  ColinSharpe Feb 7 at 18:32
2  
A problem with honeypots is that form autocomplete helpers may try to fill the username in. Every human filling in a form is doing so with a computer of some sort, which may be set to automate some of the monotony of filling in forms. If the HTML is only found within the compiled app, someone who wants to run a bot must have specifically sought out the form. If the form contents are being sniffed from the app based on what it submits, honeypot fields won't show up! It's not like a bot that just seeks out WordPress comment forms on the open web. –  Paul Gregory Feb 9 at 19:39
show 5 more comments

I'm personally a big advocate for a simple math equation for a captcha. For instance, having a fieldset at the end of your form:

What is 1+5?
[_____________]

Have the two numbers generate at random. I have seen a significant decrease in spam/bot form submissions with this method. It seems as if these bots do not have the programming to recognize and solve these equations. Maybe because they're more accustomed/programmed to solve word-based captchas.

Plus from a user experience prospective, these are the easiest forms of captchas I've come across. Simple and not difficult. And they are easy to code/scale (responsive designs) in HTML/CSS.

share|improve this answer
9  
This only works because it's not (yet?) widely used. Developing an algorithm to solve questions like this is very very simple. –  Sebastian Negraszus Feb 7 at 20:09
2  
This is usually flagged for being a cognitive accessibility hurdle. That said, I find a regular Captcha to be worse, so it's probably a wash. I do think it's better than the typical cryptic scribbles. –  DA01 Feb 7 at 20:30
5  
@SebastianNegraszus - Although if the numbers were images, the very very simple algorithm you mentioned just got a ton harder. –  Code Maverick Feb 7 at 22:08
12  
@CodeMaverick If the numbers are images, then they are either simple to read (so standard OCR software can read them, too) or obscured and difficult to read (so you end up with a traditional captcha and gain nothing). –  Sebastian Negraszus Feb 7 at 22:55
add comment

I'm not a developer so I'm not sure of the security concerns (if there are any), but what about having the user respond via touch input? For example, you could have the user tap a box three times, or maybe do a simple swipe. You could even have the user draw a shape: http://www.josscrowcroft.com/projects/motioncaptcha-jquery-plugin/

share|improve this answer
    
There is talk of this...namely a swipe action to get to the next part of the form. This is a good option if it works for security. –  DA01 Feb 7 at 17:23
6  
Tapping boxes and swiping things are easy to replicate. That MotionCAPTCHA is entirely clientside JavaScript and offers as much security as a "no bots please" sign. –  Blender Feb 8 at 11:30
add comment

Necessary?

To your first point, I cannot believe there will be much 'bot' traffic to a URL that is only declared within the HTML code embedded in an app. The primary goal of spambots is to plant links back to other sites, and there's not much point doing that on pages that are not themselves indexed, and no point at all on forms that do not affect content.

Whilst it is possible to disassemble the app or sniff the requests, there would need to be some purpose to a bot created from the information. If the objective was simply to swamp your server with traffic, sending incorrect CAPTCHA data often enough would be sufficient. Without knowing what you seek to protect, I cannot say whether a CAPTCHA is necessary.

Mobile-Centric Alternative

As the only known purpose of the CAPTCHA is to comply with a robotic request from the specification drafters, a sufficiently foolproof CAPTCHA would be the following text instruction:

Please hold your device in your left hand.

As we all know, computers do not have hands and always follow instruction so when faced with this they will probably like self-destruct or something. Stands to reason.

(This is mobile-centric as desktops are typically too heavy to hold in one hand.)

This text genuinely ticks all the key boxes for an alternative CAPTCHA:

  • Delays completion of the form by all humans
  • Alienates the disabled
  • Makes zero difference to the form fields submitted, thus requiring no server-side programming
  • Is easily circumvented by anyone with genuine malicious intent

just like other answers here, like the one where you have a slidey thing because computers don't have fingers.

An enhanced version of this would be to place the word left in a blurry image of a particularly hard to read font in an eye-watering colour combination, which will achieve:

  • Ruins the design
share|improve this answer
add comment

is bot traffic from an iPhone (or Android device) actually a problem?

Yes, and anyway your servers can't dissociate traffic from a PC and traffic from a smartphone if the spammer has done things correctly.

If so, are there better alternatives that are mobile-centric over yet-another-annoying-CAPTCHA?

There is no alternative to captcha.

Things like the concept that was linked in another answer are totally incomparable to a captcha. Captcha is to that kind of solution as strong password hashing is to obfuscation. Anyone with a few reverse-engineering skills will be able to break it.

Captcha (visual or audio) is relying on the limited power of computers nowadays, and thus, their limited capabilities in image or sound recognition. Other solutions are simply relying on the fact that the spammer may be too stupid to make a correct spambot.

share|improve this answer
add comment

When the technology involved in voice recognition has evolved to an acceptable level, it would be a real alternative to touch input CAPTCHA. Sadly to say, we are not quite there yet, if we read the findings of Kapil Chalil Madathils et. al. article Evaluating the usability of CAPTCHAs on a mobile device with voice and touch input. They concludes that...

The results indicate that users may not be satisfied completing CAPTCHAs by voice, at least when using the current Dragon Mobile SDK voice recognition software. Incidentally, Siri - the speech recognition application and personal assistant developed for the iPhone - was not availablefor use at the time of this study. Our results also suggest that Confident Touch is an effective and usable CAPTCHA for mobile devices. An additional benefit to this CAPTCHA is its space saver version that takes up less space on a web page and mobile screen. Overall, our results generally support the use of image-based CAPTCHAs where this is feasible. Some participants in our study appeared frustrated when attempting to recognize the distorted characters in Google's CAPTCHA, and a few even mentioned their frustration with similar text- based CAPTCHAs encountered online. The scores on our usability measures for Google's CAPTCHA, however, werereasonably good.

But things move quickly in this world, and the fact that Siri wasn't tested brings hope for the future of voice recognition CAPTCHA. Until then, image based CAPTCHA is the best option.

share|improve this answer
add comment

How about generating two random numbers between 0 and 10 and asking the user what is the sum of those numbers.

share|improve this answer
1  
And how do you prevent a bot from entering the sum? The solution doesn't scale, the more sites use it, the more bots will start including the very simple algorithm for knacking. –  Rumi P. Feb 11 at 11:44
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.