Dmitry Chestnykh, founder of Coding Robots, a tiny software company (productivity apps, currently: Mémoires, Video Mémoires). Created and maintaining "I Write Like" (https://iwl.me) and Calcish (https://calcish.com). Created BlogJet. Failed with StableLib (https://news.ycombinator.com/item?id=9342769).
Author of Password Authentication for Web and Mobile Apps (https://dchest.com/authbook/)
// userLookupGetent uses "getent" to look up users so that even with static
// tailscaled binaries without cgo (as we distribute), we can still look up
// PAM/NSS users which the standard library's os/user without cgo won't get
// (because of no libc hooks). If "getent" fails, userLookupGetent falls back
// to the standard library.
I did something like this using fail2ban for some time, but 1) it didn't help much due to the larger number of IPs, 2) it blocked widely used VPN services.
Being able to quickly reject invalid sessions identifiers is a useful property in some cases and is normally done by authenticating stateful session tokens with a MAC using a global app key. This can be used for DoS protection if the cost of a database lookup is more than the cost of MAC, and the complexity is justified. It ensures that the random numbers a user is trying to present as their session token are the numbers generated by the server if the key is not leaked.
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.
> 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?
It's interesting that most of the comments here are about using this feature to bypass security restrictions (whether valid or not). It says a lot about the attack surface of GNU utilities caused by featuritis.
> just a block cipher in the category of endofunctors
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]
This is SHA-2, SHA-1, MD5, etc, and with a slight variation and a larger block cipher, BLAKE(1,2,3).
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.
Did you use their volumes for node_modules or a shared dir? I mounted the whole project directory (with node_modules) inside the container and it seems to work fine (MBA M1 8 GB RAM).
> "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."
Well, obviously, software can't do things that the author didn't write code for. But AppKit components do get updated with some new features even if the original software didn't have support for them originally.
> For instance, an app can't start using Apple Intelligence if it's compiled with an older version of the SDK that doesn't know that such a thing exists.
That's not true, it became available in all NSTextViews by default, although with a bit different look.
How does a high-reliability system have a broken /dev/random? You're better off fixing it rather than trying to fix every downstream component that uses it. You can put your AES-128 counter there if you can count reliably.
"Additional acquisitions in 2006 included ShoeBuy.com,[46] which the company later sold to Jet,[47] and Connected Ventures including CollegeHumor and Vimeo".
Author of Password Authentication for Web and Mobile Apps (https://dchest.com/authbook/)
Based in Montenegro.
Email: [email protected]
X: @dchest Bsky: dchest.com Mastodon: mastodon.social/@dchest
Website/blog: https://dchest.com
GitHub:
https://github.com/dchest
https://github.com/coding-robots
(CC-BY) All my comments on HN are licensed under Creative Commons Attribution 3.0 license.