Because you're trying to bolt things on top of JWT, you're creating a worse version of that stateful authentication pattern:

1. You lost the statelessness of JWT by making database queries. Your claim that "you don't need to verify against user's secret immediately" is false, as you need to do that in all cases immediately after verifying the JWT signature to get the benefits of your system (token invalidation). Sure, you reject completely invalid tokens early, but you still need the statefulness to authenticate users properly (if your goal is to be able to invalidate tokens).

2. In your version, getting a read-only access to the user database (leaking per-user secrets) completely destroys token invalidation, and all your authentication now depends on one key. If, in addition to that, the JWT signing key leaks, user authentication is completely destroyed and can be bypassed by the attacker, who now can sign in as any user. (A common way to leak all this is by failing to properly secure backups).

Compared to a stateful session system with split-tokens, where the database stores tokenId => verifier, where verifier is Hash(randomToken), and user's token is id||randomToken, read-only access to the database doesn't let the attacker authenticate as any user. If the tokens that users presents are in the form of id||randomToken||HMAC(serverKey, id||randomToken) for early rejection as above, leaking serverKey still won't allow the attacker to authenticate as any user. The attacker needs write access.

> Is author's brain stateless -- my bad, I thought this was not reddit

I didn't realize that you were the author, I thought you were a reader who was misled by this blog post. Even better: you can go and edit it, removing "stateless" everywhere! It's fun to invent various protocols, but when someone points out the errors, surely you'd want to fix them -- no shame in making mistakes if you correct them.

Usually, when I think of a protocol, after writing down "Benefits" (as in your blog post), I write "Drawbacks" and then try to come up with downsides and compare it with existing protocols. I'd suggest you do the same.

PS. Find yourself in this picture: http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-...

> Each user has a secret: Stored securely in the database.

> Stateless Validation: The core validation remains stateless. We only need to consult the database for the user's secret, which we'd likely do anyway for authorization checks.

Is "stateless" the same as "serverless" now? Is author's brain stateless?

A block cipher is just a keyed pseudorandom permutation! :)

Imagine that we have arranged all numbers from 0 to 115792089237316195423570985008687907853269984665640564039457584007913129639936 (2^256-1) in an array and then shuffled that array 115792089237316195423570985008687907853269984665640564039457584007913129639936 (2^256) times uniquely, each time recording the resulting shuffled array.

Here's the Go-like type:

var perm [115792089237316195423570985008687907853269984665640564039457584007913129639936]uint256

This is an unkeyed permutation (we can already build a secure hash function like SHA-3 from it, e.g. SHA-3 uses [2^1600]uint1600 permutation, while Ascon-Hash uses [2^320]uint320. The best we can do with ours is 2^127.5 collision security).

A keyed permutation takes 2^256 of these arrays, again shuffled differently and uniquely, so we have:

var keyedPerm [115792089237316195423570985008687907853269984665640564039457584007913129639936][115792089237316195423570985008687907853269984665640564039457584007913129639936]uint256

A block cipher is just P[k][p] where k and p are indexes into the arrays. Let's call k the key and p the plaintext — first we select one particular permutation using the key, and then select the resulting number (ciphertext) using the plaintext.

A simple hash function built from this keyed permutation splits the message into 256-bit numbers and then selects permutations using the message as k, and previous value as p and adds them together:

   h = (some starting number called IV)
   h += keyedPerm[m[0]][h]
   h += keyedPerm[m[1]][h]

Of course, it's physically impossible to have that much memory for the arrays and it's physically impossible to shuffle that many times, so a block cipher is an approximation of that by smashing and rearranging bits, hoping to cause diffusion and confusion.

> "When a contact calls you and you're both using Phone by Google, their device sends a silent confirmation signal in real time to your device to verify the call is legitimate and truly coming from the contact's device," Google writes in a blog explaining the new feature. "Because this digital handshake uses end-to-end encrypted Rich Communication Services (RCS) technology, it is completely private."

That's not true, it became available in all NSTextViews by default, although with a bit different look.

"Additional acquisitions in 2006 included ShoeBuy.com,[46] which the company later sold to Jet,[47] and Connected Ventures including CollegeHumor and Vimeo".

Already in Chrome as an origin trial: https://developer.chrome.com/docs/ai/prompt-api

Comments URL: https://news.ycombinator.com/item?id=47599795

Points: 2

# Comments: 0