29

In this question on software recommendations, the OP asks for an alternative to Google reCAPTCHA because "for a security reasons also we don't want to depend on any out side services".

As far as I know, you ask Google for a CAPTCHA, you display it, you send the user’s input to Google who tell you if the input was correct or not.

Where’s the possible insecurity?

It's not like you send Google the user's log in, password, d.b.b, bank account number or any other sensitive information.

I suppose that a truly determined attacker could use some man-in-the-middle attack, but why? CAPTCHAs are generally used to prove you are not a bot and not as login credentials.

Am I missing something? Is the OP correct to be concerned or is he just going to cause himself a heap of extra work, possibly by trying to implement his own system which he believes to be safer than Google's because ... security through obscurity?

Community
  • 1
Mawg says reinstate Monica
  • 1,368
  • 2
  • 13
  • 26
  • 20
    IMHO, the OP's belief that by implementing his own CAPTCHA system is wrong. As a security professional, I always recommend the use of widely accepted, regularly audited and patched algorithms and implementations for tasks like CAPTCHAs, Encryption and Random Number Generation. – feral_fenrir Sep 28 '15 at 13:15
  • 3
    @feral_fenrir The OP was asking on software recommendations, so they clearly want to use an existing captcha solution, if there is one fitting their requirements. Not wanting to use a SAAS solution is understandable, both from a security point of view (including javascript from an untrusted source is self inflicted XSS) and from a privacy point of view (google is tracking users). – CodesInChaos Sep 29 '15 at 09:55
  • That comment isn't specifically targeted at Google. All I would take from that comment is that they don't want to use _any_ third party services. – MrWhite Sep 30 '15 at 10:51
  • 1
    Recently, captcha issues abound for those who have tracking protections turned on in their browsers. Myself included, which suggests more than just "website sends to google / google sends back to website, and website authorizes. If it were that way, why would captcha be blocked while tracking is turned on, and work when tracking is turned off? – TG2 Mar 22 '19 at 00:49

3 Answers3

58

Well, there could be a couple of concerns:

  • Denial of service: In case the Google reCaptcha system somehow goes down, your users will probably not be able to authenticate anymore. This could also happen if they implement some kind of update, which breaks the whole system.
  • External JavaScript libraries: when using Google reCaptcha, you need to include some JS libraries. In case Google wants to execute some XSS attack, you have just made it a lot easier for them.
  • Tracking: anyone clicking through the reCaptcha 'consents' to be tracked by Google. This may impact your user's privacy, as well as provide a means for Google to track traffic on your website.

However, as mentioned in this answer, they probably care more about their reputation than about compromising your website. Although I doubt that when it comes to the 'tracking' concern.

Community
  • 1
Michael
  • 5,393
  • 2
  • 32
  • 57
  • 7
    Note that it wouldn't have to be Google who wanted to execute an XSS attack, but anyone who gained ability to MITM them. See the recent DDOS attack on Github, allegedly orchestrated by the Chinese government injecting XSS into Baidu advertising code. – IMSoP Sep 28 '15 at 17:14
  • 1
    Or maybe a side-swipe Denial of Service attack: MITM the connection/s between the user/s and the reCaptcha service and dynamically modify every user response a little so that validation always fails. :) – mostlyinformed Sep 29 '15 at 04:29
  • 1
    Whether the user 'consents' or not, the important thing from a security POV is that they *are* tracked by Google! Using a third party for all or part of your authentication means as you say that third party in effect is watching your front door and noting who comes in. This isn't necessarily a problem, but when it is a problem there isn't really a workaround. – Steve Jessop Sep 29 '15 at 08:30
  • Actually, an XSS by a malicious third party might not need a Google compromise or MITM to be carried out. The google CDN serves old (and thus vulnerable) versions of commonly used js libraries. So, if you're plugging a hole in your Content-Security-Policy just to allow google, and if you have code that'd be XSS-vulnerable without CSP, you'd end up with no effective protection: http://git.io/vcYdc this example is for ajax.google.com, recaptcha uses apis.google.com instead. I'm not aware of vulnerable code hosted there, but this doesn't mean that we shouldn't be cautious (what's the threat?) – berdario Sep 29 '15 at 10:36
  • 1
    On the side note - the tracking is the ultimate source of Google's reputation. They wouldn't be where they are now without all this tracking going on. Only switching the tracking _off_ would ultimately harm the rep. – Pavel Sep 29 '15 at 14:17
  • I can certainly attest to the denial of service... I have a service that I couldn't access because recaptcha apparently doesn't like the default (and only) browser in our desktop estate. Makes quite a few services unusable I can tell you. – James Snell Nov 17 '17 at 19:19
9

It isn't clear from the OP's question, but it is possible that for security reasons the whole system is not able to communicate with third party networks. The OP may wish to have a system that he can implement server-side because the server, and potentially the clients too, are unable to connect to Google, or anywhere else on the Internet. The security benefits of not being connected to the Internet when you don't need to be are widely known.

Dezza
  • 199
  • 1
  • 2
  • 7
  • An excellent point, maybe the OP will clarify this for us – Mawg says reinstate Monica Sep 28 '15 at 15:07
  • OP of other question says "don't want to" , not can't – Neil Smithline Sep 28 '15 at 15:07
  • 6
    While this may be possible, I think it is highly unlikely to require a captcha at all in an intranet (if no one can connect to the internet) - You have usually a countable number of users in the intranet and it is usually easy to identify them by IP-Adress/Subnet or similar. So no real need for captchas. – Falco Sep 28 '15 at 15:21
  • 8
    @Falco The number of users on the internet isn't just *countable*, it's *finite*. :) – CodesInChaos Sep 28 '15 at 18:16
3

According to Egor Homakov's blog:

  1. Google reCAPTCHA relies on a whitelist based on your previous online behavior (cookies) which thing does not make the task difficult for bots as the legacy flow is still available and old OCR bots can keep recognizing the old CAPTCHA.
  2. The replacement of the the traditional challenge/response procedure by this cookie whitelist makes the whole service vulnerable to attacks via clickjacking.
  • I don't think that the OP was concerned about how well reCAPTCHAs work at identifying humans v. bots. I think the question is about whether calling Google's CAPTCHA implementation adds additional security risk. – Neil Smithline Sep 28 '15 at 19:33
  • 1
    @NeilSmithline Are not the two points I took from that blog talking about security risks? –  Sep 28 '15 at 19:34
  • 2
    Not in the same way. Consider an application with no CAPTCHA. Adding CAPTCHA might make the app more secure, but shouldn't make the app less secure. Your two bullet points explain why CAPTCHA might not make the app more secure but, at least to me, the OP is asking whether adding CAPTCHA makes the app less secure. – Neil Smithline Sep 28 '15 at 19:38
  • *... makes the whole service vulnerable to attacks via clickjacking*: **this answers** : *the OP is asking whether adding CAPTCHA makes the app less secure* –  Sep 28 '15 at 19:40
  • How does usage of a cookie whitelist make a page any more vulnerable to clickjacking than any other method of dynamic interaction? In general, clickjacking is a UI issue, so anything that involves interaction with rendered components on a website has some potential clickjacking vulnerability. – JAB Sep 29 '15 at 13:20