Hacker News Re-Imagined

Show HN: Prefixed, dual-token, base58 encoded API Keys

  • 100 points
  • 8 days ago

  • @seveibar
  • Created a post

Show HN: Prefixed, dual-token, base58 encoded API Keys


@kevincox 8 days

Replying to @seveibar 🎙

> we search our database for short_token and hash(long_token).

Sounds like some salt should be used here. Search the DB for short_token, then use the discovered salt to check the "password".

Reply


@seveibar 8 days

Replying to @seveibar 🎙

Author here: I was curious what HN would think of this token style, we're currently using it for getseam.com . I think it has a lot of advantages over other token styles (e.g. double-click to select, standard alphabet, compatible with secret scanning). Although this is a typescript library, we originally designed this API key for use in Ruby on Rails and the pattern should be fairly portable.

Reply


@lefrenchy 8 days

Replying to @seveibar 🎙

I wasn’t too sure based on the docs:

What parts of tokens does the server store in the Database (everything but the raw long token I think?)

What is sent to the consumer, and what do they need to send with the request?

Reply


@anm89 8 days

Replying to @seveibar 🎙

Why base 58? I've never even heard of base 58.

Reply


@wccrawford 8 days

Replying to @seveibar 🎙

  // Store the key.longTokenHash and key.shortToken in your database and give
  // api.token to your customer.
I'm pretty sure that should be "key.token" instead.

Reply


@phineyes 8 days

Replying to @seveibar 🎙

I created a similar project recently! Main difference is that I use base64 to encode unique Snowflake IDs, which are timestamped: https://github.com/hopinc/pika :)

Reply


@godmode2019 8 days

Replying to @seveibar 🎙

Very cool,

I use something similar but a fixed length for the prefix and uppercase

Basically a copy of stripe tokens

Reply


@tetch 8 days

Replying to @seveibar 🎙

Nice work! May I inquire as to the design decision behind storing a hash of the long token server-side for verification of the long token, versus digitally signing the short token plus a nonce and including this signature in the API key (instead of a long token), as some other API key schemes do?

Both are valid approaches of course, I'm just interested to hear your thoughts on the relative tradeoffs.

Reply


@miller_joe 6 days

Replying to @seveibar 🎙

Hey, cool idea. I like it. I made a Go implementation for fun/practice - https://github.com/joemiller/prefixed-api-key

Reply


@benatkin 8 days

Replying to @seveibar 🎙

I like it. I'm not sure that "short token" is the right term for that - perhaps "token id". Also the only occurrence of "it's" in the README should be "its": https://brians.wsu.edu/2016/05/19/its-its/

Edit: Actually, the short token is more than just a token ID - it's also required, right? Perhaps replace:

   When we receive an incoming request, we search our database for hash(long_token)
with:

   When we receive an incoming request, we search our database for hash(long_token) and short_token. A token can be blocklisted by its short_token.
So I think I prefer "short token" to "token id" but perhaps there is a better name for it. If it did get renamed it would probably make sense to rename "long token" as well. I'll defer to experts on this.

Reply


About Us

site design / logo © 2022 Box Piper