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:
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.
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.
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.
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.
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.
– Vanuan
Feb 08 '14 at 23:43
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.
– VoronoiPotato Feb 11 '14 at 16:58Snapchat recently added image recognition:
(http://venturebeat.com/2014/01/22/snapchat-find-the-ghost/)
Note:
As most captchas, this is also breakable.
But until your app becomes a popular target, this is a pretty nice alternative ;-)
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.
From an implementation perspective at least, it could not be easier!
<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 08 '14 at 17:00
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.
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.
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.
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 07 '14 at 18:22
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.
– David Conrad
Feb 07 '14 at 20:41
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 09 '14 at 19:39Since 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:
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!
autocomplete="off" on your inputs. Most (all?) browsers support this.
– rybo111
Feb 10 '14 at 20:57
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.
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/
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:
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:
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?)
Bot traffic to an API server is not usually from your iPhone or Android device, instead they come from bot farms, that nowadays(August 2020) are a collection of compromised servers and iot devices working together or individually to attack/crawl/scrape an API server.
I don't discard that mobile devices can also be compromised to act as bots, but that isn't usually the case. Unauthorized traffic that is reaching the API server from a real mobile device it's generally from a cloned/tampered version of the official mobile app available in the iOS and Android stores.
You also have the situation where an attacker may be performing a MitM(Man in the Middle) attack against the original mobile app installed in a device he controls in order to manipulate the traffic in both directions. An example of a good open source tool for doing a MitM attack is mitmproxy:
An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.
This tool can be used to exfiltrate data or to gain access to privileged features/data that the mobile app doesn't expose, but the API exposes. Another form of achieving the same is to use an instrumentation framework to hook at runtime on the original mobile app. An example of such a framework is Frida:
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
Bad bots traffic is indeed a very serious issue for API servers, and they are very hard to mitigate, because while it's easy to identify/authenticate who is in the request, it's very hard to do the same for what is doing the request.
Wait, I don't get it, but as you a lot of others are not aware that this difference exists or have a misconception about it. Until 2018 I was one of that developers, therefore I would like to first clear this common lack of knowledge or misconception about the difference between who and what is accessing an API server.
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
So think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
If so, are there better alternatives that are mobile-centric over yet-another-annoying-CAPTCHA?
You can use the Mobile App Attestation concept in conjunction with the Android SafetyNET and the iOS Device check in order to achieve a very high degree of confidence that you truly have locked down your API server to your genuine mobile app. Please read my answer to the question Restrict API requests to only my own mobile app for more details.
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
You could try NoMoreCaptchas.com to auth the user. Its done w a new type of technology called BioChronometrics. This is all passive to the user based on user behavior.
A very simple approach that worked for me in production was to add a checkbox field that was hidden via style definition (CSS) and not via attribute type="hidden".
If the field is checked on submit, the probability is high that a robot checked it, if not a user submitted the form.
This solution is not 100% safe but very very easy to implement, effective and more important: user friendly!
One of the options can be asking user to input the current-mobile number, sending an OTP to the mentioned number and reading it automatically (user should not be allowed to enter the same manually).
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.
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.
How about generating two random numbers between 0 and 10 and asking the user what is the sum of those numbers.
Firstly, to secure your API, add a new inbound rule to your firewall that only allows connections to your API's IP address and Port from your Web Server's IP address / Local network IP range (if developers or other machines need access), even if they are hosted on the same machine. This does of course mean that you need to assign a unique port to your API, but it shouldn't be a problem if your API isn't public. This will prevent any bots from making requests directly to your API.
Secondly, add Facebook or Google verification to your signup process. This means that you will automatically benefit from any new Captcha solutions that are implemented by them in the future. And it's great for users because they won't have to remember yet another password.
Captchas are a real eye sore and really hard to read sometimes, and judging by the comments above, definitely not worth the effort.
