https://hart.pglaf.org/

From Wikipedia:

"Michael Hart's email messages and blog posts had equal line length paragraphs in monospaced font: he chose the wording in such a way that each line had the same number of characters."

inserts 31KB JavaScript into tiny HTML pages.

WAL means it will write the same data at least twice. Similar issue, but even worse, with LevelDB -- it will just delay the inevitable huge rewrites for later. Funny to hear those proposals in the write amplification thread.

I believe journald log rotation is basically: close file - open a new one. How is it not completely different?

https://man.freebsd.org/cgi/man.cgi?query=crypto_dispatch&ap...

"crypto_dispatch() returns an error if the request contained invalid fields, or zero if the request was valid."

However, on an actual error from the crypto driver (e.g. invalid MAC), crypto_dispatch result is successful and the error is returned in crp_etype structure field.

https://cgit.freebsd.org/src/commit/sys/dev/wg?id=3427182452...

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

Points: 2

# Comments: 1

https://github.com/tailscale/tailscale/blob/e4144230f410204a...

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

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?