Hacker News Reader

Comment by mperham | Hacker News Reader

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."

View on HN

For those that haven't seen it, "secret-token:" is an RFC. I've started using it at work.

https://tools.ietf.org/html/rfc8959

Note 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#Informati...

An unencrypted version marker would be pretty useful, too. If anything is long-term, you can safely bet in that it'll need to evolve.

Fair, though usually a token like this is just an ID into a database table and doesn't itself contain any data.

One 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.

I’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.

Ruby/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

that's how Stripe prefixes their IDs too, depending on what type of entity it is. Makes debugging, docs, .. easier

FWIW 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.

The 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.

Surely 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.

I do it like that. We're only using a two char prefix (I copied Twilio)

Why not? You don’t have to store the prefix and the UUID in the same column?

Can’t you just add a column to your schema with the prefix?

Reply on news.ycombinator.com