4 ms·
TIL: make private key for your service easy to match with regexps
by comboy 4y ago
TIL: make private key for your service easy to match with regexps
- hunter2_ 4y agoReminds 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!
- Breza 4y agoI 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.
- echelon 4y agoThe 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.
- jve 4y agoBad 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.
- mewpmewp2 4y agoI think prod_ might not be the important part there, so something like __secret__ should be enough.
- MattJ100 4y agoYou're not the first with this idea! There exists a standard, see RFC 8959: https://www.rfc-editor.org/rfc/rfc8959.html https://www.rfc-editor.org/rfc/rfc8959.html Previous HN discussion: https://news.ycombinator.com/item?id=25978185 https://news.ycombinator.com/item?id=25978185
- gl-prod 4y agoYeah, prefixing your keys with your service name like SRVCE_{KEY} is the way to go. Bonus: adding SRVCE_PRVT_{KEY} and SRVCE_PUB_{KEY}.
- rytis 4y agoAnd 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, ...?")
- gl-prod 4y agoI meant as an abbreviation, like GitHub becomes ghp_XXXXXXXXX. But yeah anything is better than just random characters.
- hawski 4y agoI 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.
- miohtama 4y agoThere 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 https://datatracker.ietf.org/doc/html/rfc8959
- throwaway290 4y agoI 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.
- miohtama 4y agoIf any value does not natively support secret token sceme, you can apply secret-token: prefix and then strip it during the usage.
- GoblinSlayer 4y agoI don't think it's a regex pattern, most keys are random strings.
- semiquaver 4y agoThat’s the idea. Add a deterministic prefix to make it identifiable as associated with a specific service.