3 ms·
The key insight here is that random tokens should be self-describing, so you know their intended use and therefore can make decisions and take action when one i
by mperham 6y ago
The key insight here is that random tokens should be self-describing, so you know their intended use and therefore can make decisions and take action when one is detected.
If a script sees "ABC123" in a code commit, that's meaningless. If you see "secret-token:ABC123", now you can fail the commit with an error message: "Secret token detected in public commit, aborting."
- echelon 6y agoOne of the biggest learnings of our org was to prefix tokens with the entity type. It's helped immensely. entity-type:RANDOM_TOKEN * Helps in migrations, especially complex ones where you split up entity types. * Identities what tokens are so people can look them up if they see them in logs. * Polymorphic relationships can delegate to the appropriate owning service easily without additional bookkeeping. You can also encode other stuff in the token entropy, too, such as the author DC/region for active-active setups where you need to forward the request to the source of truth in the brief window where the other regions don't know about it yet.
- 11235813213455 6y agothat's how Stripe prefixes their IDs too, depending on what type of entity it is. Makes debugging, docs, .. easier
- fiddlerwoaroof 6y agoI’ve always thought that a Java-style reverse domain name format (or, perhaps, URLs) is a great way to encode IDs: com.foo.bar.Person:0000-11111-22222-33333 or whatever. That way, any code that logs IDs or transfers IDs across the network gets tracing “for free” and, when you see an ID in a bug report, you can use it to help focus the investigation.
- ljm 6y agoRuby/Rails has this in the form of GlobalID[1]. To be honest I haven't seen it used outside of whatever Rails itself automatically does, but the concept is there. [1]https://github.com/rails/globalid https://github.com/rails/globalid
- xPaw 6y agoFor those that haven't seen it, "secret-token:" is an RFC. I've started using it at work. https://tools.ietf.org/html/rfc8959 https://tools.ietf.org/html/rfc8959
- nine_k 6y agoAn unencrypted version marker would be pretty useful, too. If anything is long-term, you can safely bet in that it'll need to evolve.
- mikepurvis 6y agoFair, though usually a token like this is just an ID into a database table and doesn't itself contain any data.
- cornstalks 6y agoNote that the RFC's category is "informational", which doesn't give it as much weight as something that is "standards track". Usually the important RFCs are "standards track" though there are some "informational" RFCs that are also important. From Wikipedia[1]: > An informational RFC can be nearly anything from April 1 jokes to widely recognized essential RFCs like Domain Name System Structure and Delegation (RFC 1591). Some informational RFCs formed the FYI sub-series. [1]: https://en.wikipedia.org/wiki/Request_for_Comments#Informational https://en.wikipedia.org/wiki/Request_for_Comments#Informati...
- staticassertion 6y agoFWIW it is still very much worth reading the article, since they talk about how they implement that approach. They bring up why they use an underscore, checksum'ing, entropy, etc.
- revicon 6y agoThe ID prefixing is cool from an identification point of view, but we've been using UUIDs for tokens and if we implemented this we wouldn't be able to use the UUID optimized datatype field in Postgres.
- deleted 6y ago[deleted]
- marksomnian 6y agoSurely you can just strip off the prefix in the application layer before sending it to Postgres? You still get the benefits, while being able to use the native query.
- edoceo 6y agoI do it like that. We're only using a two char prefix (I copied Twilio)
- orf 6y agoWhy not? You don’t have to store the prefix and the UUID in the same column?
- asimpletune 6y agoCan’t you just add a column to your schema with the prefix?