Proposal
Add a detector for Google Cloud Storage HMAC keys. They authenticate against data-hosting infrastructure on a paid platform, so they look like a fit for the sourcing guidelines in hack/docs/Adding_Detectors_external.md.
Nothing detects them today. I searched issues and PRs for HMAC and GOOG1 and found no prior art.
Why the existing detectors don't cover it
A GCS HMAC key is an access ID plus a secret, created for interoperability with the S3 API. That interop is exactly what makes it slip through:
- The access ID is
GOOG1-prefixed, so it does not match the AWS detector, which keys on AKIA, ABIA, ACCA and ASIA.
- The secret is a 40-character base64 string — the same shape as an AWS secret access key. On its own it is indistinguishable, so the access ID is the only thing that disambiguates the two.
- Because they exist for S3 compatibility, these credentials are normally stored and consumed under AWS names:
AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY, or an s3 client's config block. Any tool that reads the surrounding context will conclude "AWS" and be wrong about which cloud the credential belongs to.
The practical consequence of that last point is that a detector for these has to anchor on the GOOG1 prefix in the credential itself rather than on nearby keywords — which is also what the detector docs recommend ("Use identifiers in the secret preferably"). A context-driven match would both miss these and risk sending a Google credential to AWS for verification.
Shape
An access-ID and secret pair that appear near each other, the same two-part arrangement pkg/detectors/aws/access_keys already handles — so that detector is a reasonable structural model, with a different prefix and a different verification target.
I have deliberately not written an exact length for the access ID here; that is worth confirming against a real key before anyone writes the regex.
Verification
The GCS XML API accepts AWS Signature Version 4, which is what HMAC keys are for, so a signed request against storage.googleapis.com verifies the pair. The signing code already in the AWS detector should be largely reusable.
Happy to put a PR together if this looks worth having.
Proposal
Add a detector for Google Cloud Storage HMAC keys. They authenticate against data-hosting infrastructure on a paid platform, so they look like a fit for the sourcing guidelines in
hack/docs/Adding_Detectors_external.md.Nothing detects them today. I searched issues and PRs for
HMACandGOOG1and found no prior art.Why the existing detectors don't cover it
A GCS HMAC key is an access ID plus a secret, created for interoperability with the S3 API. That interop is exactly what makes it slip through:
GOOG1-prefixed, so it does not match the AWS detector, which keys onAKIA,ABIA,ACCAandASIA.AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY, or an s3 client's config block. Any tool that reads the surrounding context will conclude "AWS" and be wrong about which cloud the credential belongs to.The practical consequence of that last point is that a detector for these has to anchor on the
GOOG1prefix in the credential itself rather than on nearby keywords — which is also what the detector docs recommend ("Use identifiers in the secret preferably"). A context-driven match would both miss these and risk sending a Google credential to AWS for verification.Shape
An access-ID and secret pair that appear near each other, the same two-part arrangement
pkg/detectors/aws/access_keysalready handles — so that detector is a reasonable structural model, with a different prefix and a different verification target.I have deliberately not written an exact length for the access ID here; that is worth confirming against a real key before anyone writes the regex.
Verification
The GCS XML API accepts AWS Signature Version 4, which is what HMAC keys are for, so a signed request against
storage.googleapis.comverifies the pair. The signing code already in the AWS detector should be largely reusable.Happy to put a PR together if this looks worth having.