Reminds me of how Airbnb redacts Hawaiian street addresses because they look too much like phone numbers, literally replacing them with a "phone number hidden" string in the host|guest chat.

Moral of the story: make your keys regexable without likelihood of false positives!

I spend a lot of time working with physician data. In the USA, physicians have a registration system called NPI. Apparently, NPI numbers are in the same format as some passport numbers. I know this because I started getting angry warnings about PII sharing until I got our tech team to turn them off.

The whole industry should adopt a convention to prefix production keys with a well known prefix, such as "prod_secret_".

We should have our systems and precommit hooks then alert us when those enter places they shouldn't and help us automate rotation.

Bad idea. Better do it in DEV like you would do in PROD, not to shoot yourself in the foot. If you do it right in DEV, no problem in PROD.

And what if your DEV is not actually well isolated from PROD/other infra? And what if some real data sneaked into DEV? Etc.

I think prod_ might not be the important part there, so something like __secret__ should be enough.

You're not the first with this idea! There exists a standard, see RFC 8959: https://www.rfc-editor.org/rfc/rfc8959.html

Previous HN discussion: https://news.ycombinator.com/item?id=25978185

Yeah, prefixing your keys with your service name like SRVCE_{KEY} is the way to go.

Bonus: adding SRVCE_PRVT_{KEY} and SRVCE_PUB_{KEY}.

And while we're at it, I think saving two chars isn't going to do much to prevent global warming, and let's just use more readable SERVICE_{KEY} and SERVICE_PUB_{KEY} (as opposed to having scratch your head thinking "did I call it SRV, SVC, SRVC, SRVCE, ...?")

I think OP meant to use the actual name of the service. For example FOOBARINC_{KEY}

I also think that it should look just a bit cryptic to make a person unsure if they can meddle with the string.

I meant as an abbreviation, like GitHub becomes ghp_XXXXXXXXX. But yeah anything is better than just random characters.

There is already RTC 8958 Secret token scheme for this, so you do not need to invent your own prefix

https://datatracker.ietf.org/doc/html/rfc8959

I see this standard linked here a lot. Did anyone read it though? It only helps with identifying whether a string is a secret, not at all the service or environment where the secret applies.

If any value does not natively support secret token sceme, you can apply secret-token: prefix and then strip it during the usage.

I don't think it's a regex pattern, most keys are random strings.

That’s the idea. Add a deterministic prefix to make it identifiable as associated with a specific service.