1

There are primarily two ways to authenticate using Google's reCAPTCHA Enterprise in a non-Google cloud environment (we use AWS). Google recommends using Service Accounts along with their Java client. However, this approach strikes me as less preferable than the second way Google suggests we can can authenticate, namely, using Api Keys. Authenticating via an Api Key is easy, and it’s similar to how we commonly integrate with other 3rd party services, except rather than a username and password that we must secure, we have an Api Key that we must secure. Authenticating using Service Accounts, however, requires that we store a Json file on each environment in which we run reCAPTCHA, create an environment variable (GOOGLE_APPLICATION_CREDENTIALS) to point to that file, and then use Google's provided Java client (which leverages the environment variable/Json file) to request reCAPTCHA resources.

If we opt to leverage Api Key authentication, we can use Google’s REST Api along with our preferred Http Client (Akka-Http). We merely include the Api Key in a header that is encrypted as part of TLS in transit. However, if we opt for the Service Accounts method, we must use Google’s Java client, which not only adds a new dependency to our service, but also requires its own execution context because it uses blocking i/o.

My view is that unless there is something that I’m overlooking--something that the Service Accounts approach provides that an encrypted Api Key does not--then we should just encrypt an Api Key per environment.

Our Site Key is locked down by our domain, and our Api Key would be encrypted in our source code. Obviously, if someone were to gain access to our unencrypted Api Key, they could perform assessments using our account, but not only would it be exceedingly difficult for an attacker to retrieve our Api Key, the scenario simply doesn't strike me as likely. Performing free reCAPTCHA assessments does not strike me as among the things that a sophisticated attacker would be inclined to do. Am I missing something? I suppose my question is why would we go through the trouble of creating a service account, using the (inferior) Java client, storing a Json file on each pod, create an environment variable, etc. What does that provide us that the Api Key option does not? Does it open up some functionality that I'm overlooking?

I've successfully used Api Keys and it seems to work fine. I have not yet attempted to use Service Accounts as it requires a number of things that I'm disinclined to do. But my worry is that I'm neglecting some security vulnerability of the Api Keys.

jpsartre
  • 13
  • 2
  • I apparently didn't make myself clear. Google provides a Java client that is used on the backend to create assessments and retrieve scores. So the client that I'm referring to here is not a front-end client but, rather, Google's Java client that they provide for use of reCAPTCHA assessment creation. I might have a misunderstanding (hence the question) but I understand the basic gist of how to perform assessments and key the api key secure. I'm just not sure if it's sufficient. I get that our server is making requests. I'm not sure what made you think that's not what we're doing. – jpsartre Jan 10 '23 at 18:15
  • My sincerest apologies - allow me to retract my earlier comments. I don't think I interpreted the use of the word "*client*" correctly in my earlier read-throughs. – esqew Jan 10 '23 at 19:33
  • Can you add additional details as to the threat model you're protecting against in this scenario? Are you concerned about insiders gaining access to the key and leaking it externally or using it to commit some sort of malfeasance? – esqew Jan 10 '23 at 19:34
  • No worries, @esqew. Thanks for your help. This is a good question. I think that what worries me is that Google seems to suggest (https://cloud.google.com/recaptcha-enterprise/docs/getting-started) that you should only use Api Keys if (1) your backend is deployed on a non-Google Cloud, on-premises, CRM, or SaaS provider or (2) your environment does not support external authentication methods, such as OAuth and service accounts. But it's not clear to me why Api Keys wouldn't be used even if our environment does support OAuth and service accounts. We could use service accounts, for example. – jpsartre Jan 10 '23 at 22:18
  • (2 of 2) But it isn't clear why we should when we could instead encrypt an Api Key. So what gives me a little bit of pause is that Google seems to imply that using Api Keys is the last resort, but it does not seem to me that it is inferior to using service accounts for many common scenarios, as long as the team takes good care to secure the key. – jpsartre Jan 10 '23 at 22:19
  • To address your question a bit more directly. I'm not too worried about anyone getting access to the key. Of all the things we secure, our reCAPTCHA key would be among the least interesting. In addition, the key will be encrypted at rest. But I suppose I am worried that I've not thought of some scenario that would lead Google to recommend against using Api Keys in favor of these alternative methods. it seems that Api Keys is far easier than the other options, and provided that one can secure the key, should do the trick just fine. – jpsartre Jan 10 '23 at 22:49

1 Answers1

0

After poring a bit more over the documentation, it would seem that there are only two reasons why you'd want to explicitly choose API key-based authentication over an Oauth flow with dedicated service accounts:

  1. Your server's execution environment does not support Oauth flows
  2. You're migrating from reCAPTCHA (non-enterprise) to reCAPTCHA Enterprise and want to ease migration

Beyond that, it seems the choice really comes down to considerations like your organization's security posture and approved authentication patterns. The choice does also materially affect things like how the credentials themselves are provisioned & managed, so if your org happens to already have a robust set of policies in place for the creation and maintenance of service accounts, it'd probably behoove you to go that route.

Google does mention sparingly in the docs that their preferred method for authentication for reCAPTCHA Enterprise is via service accounts, but they also don't give a concrete rationale anywhere I saw.

esqew
  • 42,425
  • 27
  • 92
  • 132
  • Thanks for taking the time to look into this and comment, @esqew. I tend to agree with you. Our situation is similar to (2). While we aren't migrating from non-enterprise to enterprise, we are just now implementing reCAPTCHA and aren't exactly sure the extent to which we'll use it, etc. Given the relative time commitments between using Api Keys and service accounts, etc (and the fact that we don't really care to use Google's Java Client), it seems to make sense to take the road of least resistance. But I'm with you: Google clearly prefers service accounts but doesn't appear to explain why. – jpsartre Jan 11 '23 at 18:11