CAPTCHA on mobile: what are the alternatives?

  • 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?

    Very interesting topic, can't wait for some great answers. I'll put up a bounty in 2 days when I'm able to. :)

    Would using something like Google Authenticator be a possible alternative?

    Where there's an API, there's a way...

    If your app has no CAPTCHA, my emulator can bot it.

    On top of the other concerns about the UX, I don't think it's really feasible to ensure only your app can communicate with your server. Any countermeasure you deploy will be somewhat exposed because you're giving attackers the code in the app.

    Hate to spoil the party here, but I agree with @WChargin. Anything a human can do with a page, a bot will be able to do as well. Software is getting smarter and smarter and how well a "bot deterrent" works really is only a matter of how much effort the bot developer needs to expend to thwart it. Honeypot fields are nice now, but bot developers will pick up on that and their effectiveness will dwindle, especially as long as form developers keep using "recognizable" css class names to hide them for humans. ... continued ...

    ... The slider sounds interesting as does anything javascript/css based, but bot developers will eventually load both if that is what is needed to allow them to do their dirty work. Even the "phone" option @Mervin talks about is automatable. The only thing that can distinguish a human from a bot is asking the human to make use of human faculties that bots' would find incredibly hard to emulate: the "how many apples in this picture?" type questions, provided the pictures __and__ the questions are varied sufficiently randomly.

    @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.

    Any Completely Automated Public Turing test to tell Computers and Humans Apart is still a CAPTCHA regardless of its form. The 'type the text in this image' type is only one possible form; the only requirement is that it differentiates between humans and computers.

    @stoj I'm well aware of the purpose of the CAPTCHA. My point was to emphasize what Roger Attrill said, namely that you can't guarantee that your API is only accessible to mobile devices and you will be attacked on many more fronts. Once your API endpoint is exposed (i.e. as soon as you release your app), an attacker can come at you using any device, script or platform they prefer.

    You speak of bot traffic rather than bot spam. It sounds like you suspect the CAPTCHA requirement in your spec serves no purpose. Everyone here so far assumes that there is a need for a CAPTCHA, but you know what your app is and will know whether there is anything that you actually need to secure. You are not going to get random spambot traffic if your forms aren't discoverable, just targeted attacks. Do you have anything where mass or fabricated submissions would be a problem?

    @PaulGregory I tend to be highly suspect of all CAPTCHA requirements. I find that they tend to be there out of habit more than real requirements for the particular project. This is no different, in that no one has been able to show why this is truly need other than "It's in the requirements" so am just trying to meet the requirement in the least obnoxious way in terms of UX.

    Can you tell whether the requirements were written by a thinking human or a robot?

  • 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 don't 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.


    • 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.


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

    As the Book of Luke is gospel, I may be able to run with that one!

    Reading the post prompted me to think of a solution to the rest injection, simply include a salted hash of the form information. Then on the server hash the received information and it should match the hash. The salt could be the hour time.

    @VoronoiPotato I am not very technical but how does that prevent automated bot submission ?

    Some of these would prove problematic for blind users. Still a good answer, but I'm just sayin'.

    How does the drag-a-slider one work? I can't see any way it could be used to differentiate humans from robots.

    @Robert How would you program a bot to slide a slider till a particular point ?

    @MervinJohnsingh I would just short out the whole script. A real capcha has to be enforced on the server

    @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?

    @MervinJohnsingh: A "bot" communicates with the server, like a web browser. Both the drawing and the sliding "CAPTCHAs" run entirely in a web browser, so if my program doesn't communicate with your server using a webbrowser, the CAPTCHA doesn't even exist from my perspective. Convenient CAPTCHAs are easy to bypass by anyone determined to do so. If they weren't, the hard-to-read ones wouldn't exist.

    +1 for all the ideas you provide, but in the end everything is automatable and bot developers will pick up on and find ways around all bot deterrents (see my comments on the question as well). The only thing that can distinguish a human from a bot is asking the human to make use of human faculties that bots' would find incredibly hard to emulate: the "how many apples in this picture?" type questions, provided the pictures and the questions and answers are varied sufficiently randomly.

    @MarjanVenema Isn't “click the flower” just one such question?

    @GaëlLaurans: Yes, you're right. I'd call that a variation on the "how many apples in this picture" type question.

    I like the 'slide to submit' idea, but it doesn't need _any_ explanation. If I were to implement that feature I would totally avoid mentioning robots or anything of that nature. However, I'm not convinced a bot cannot emulate that action eventually.

    Looking at the "They make apps" source code we can see this function: `updateSlider1(a){if(a==4){$("UserHuman").value="6).%Y.g-";`. So it's security through obscurity. I'm not sure whether this magical string is different for different ips, but once it is found (source grepping, calling this function, etc), then it can be easily emulated by bot. The only secure element is that the bot should be specifically tailored for the website.

    @MervinJohnsingh: I would remove the first and third examples. This isn't the first time I've seen people suggest using MotionCAPTCHA. The developer refuses to make it clear that it's not actually a CAPTCHA.

    @Blender while I can do that,the question asked for captcha alternatives. The slider is a test though its technically not a captcha

    couldn't a bot hack the slider?

    @MervinJohnsingh: They aren't alternatives if they don't work.

    @MervinJohnsingh hashing with a salt would make it as hard to fraudulently create a post through rest injection as it would be to guess a password of a user.

    @VoronoiPotato: So a CSRF token? All it does is force a bot to load the webpage and extract the token before submitting your form.

    No, not a CSRF token. You hash the contents of the message with a salt. then when receiving the message you hash the contents of the message (with the matching salt. In order to reverse engineer this, you would have to know how the salt is created and create a matching salt, then know to hash the entire contents of the message, and submit the correct hash. It's by no means perfect, but fairly easy to implement, and prevents just "creating rest api calls" Server would only accept posts with a matching hash.

    Note that most of these approaches lock out vision-impaired users.

  • Snapchat recently added image recognition:

    enter image description here

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

    I like this. Not only do you prove you aren't a robot, you are enhancing your brain function. =D

    But do see this: . . . . 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.

    @NeilSlater I think it's fair to say any CAPTCHA will be circumvented in a matter of time.

    Should the middle-right and bottom-middle be considered ghosts? I'm really not sure, as they're living things (like the other butterflies, fish, and elephant), _except_ that they're a ghostly color just like the obvious ghosts. I know I'd automatically include the middle-right if I wasn't thinking about it too much.

    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...

    +1 This is a very nice variation on making a human use faculties that bots' would find incredibly hard to emulate: the "how many apples in this picture?" type questions, provided the pictures and the questions and the answers are varied sufficiently randomly.

    Oh dear I hadn't spotted the tell tale image yet that @Izkata mentions... That really needs to be removed!

    This captcha was already cracked, see here.

    This captcha is pretty easy to break.

  • 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!

    I really like this idea

    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.

    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

    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.

    Well, this field could use a very suggestive name in the markup (e.g. ``), 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.

    @MarjanVenema I was thinking that one way to make that harder for bots would be to make that particular label an image rather than text?

    @RogerAttrill: OCR (Optical Character Recognition) has come such a long way since its inception, that captcha's need to be "only just readable" for humans for a reason. Putting instructions in an image is only gonna help until bots pick up on it, especially if that field is the only one with an image for a label. Honestly, the only thing that really thwarts bots (until AI finally takes off) is to have a human use their human faculties to put two things together to come up with a third.

    @MarjanVenema Hmmm...yes, I think you're right. *Sigh*

    @RogerAttrill: Yeah... _sigh_

    This seems to be following the honeypot approach but with the added inconvenience that you're bothering the user with it. Make it an invisible field that indicates non-human entry if it *has* a value in it.

  • 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.

    re: your last paragraph...we can dream... :)

    +1 for 'offloading the responsibility' . I hate CAPTCHA in all its forms.

  • 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.

    Of all the comments here, I think you're most on the right track. I want to protect my API!! I like the idea of using a public key on the device to encrypt the traffic - however, if someone reverse engineers your (native) mobile app, they'll get the key. It's harder to do than sniffing REST traffic (which is super easy with Fiddler, however still not fool proof. I suppose it comes down to the skills of your enemy. At the end of the day, the NSA and their buddies probably break RSA anyway :-(

    Yep, I also agree - protect your API. Modern versions of Android make it quite hard to attack the underlying SSL communication if you use Cert pinning, do the network stuff in native code to make it more tedious to reverse engineer.

  • 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:

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

    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.

    So, the big question, is a honeypot seen by a bot when it's attacking an app (vs. a web site)?

    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?

    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.

    I think that there are also tricks with hash codes and JavaScript that can augment the honey pot idea, though the link eludes me

    I brought this up on a prior occasion, honeypots are vulnerable to a headless browser bot. Anything the user doesn't see the bot doesn't see, any javascript html injection the bot can respond to. They're becoming more and more common with javascript being used in regular forms, but still not quite prolific yet.

    Though in this case, we're trying to solve it from a UX POV, so I'm cool with the honeypot option (regardless if it actually does anything). :)

    Another CSS property is `clip` which can hide a field by i.e., clipping it to 1x1 pixels. Another thing to think about is how all these affect visually impaired users. For instance, I believe screen readers will not read a field hidden with `display: none` but will read a clipped field.

    I have observed on real sites a honeypot field work, ie automated spam a client was getting stopped after it was implemented instead of a traditional captcha

    Honeypot fields are nice, but will only work as long as form/css developers don't use obvious words to identify the classes used to hide the fields from humans, and bot developers haven't picked up on those words.

    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.

  • 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!

    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.

    You can turn autocomplete off.

    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.

    I meant you can include `autocomplete="off"` on your inputs. Most (all?) browsers support this.

  • 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.

    This only works because it's not (yet?) widely used. Developing an algorithm to solve questions like this is very **very** simple.

    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.

    @SebastianNegraszus - Although if the numbers were images, the very **very** simple algorithm you mentioned just got a ton harder.

    @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).

  • 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:

    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.

    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.

  • 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

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM