Hacker News Reader

Comment by tptacek | Hacker News Reader

I don't recommend PASETO either.

What do you recommend then? What technology has been designed, completed, then used for years without any updates or problems?

Bearer tokens are a dead end? You have to validate them anyway so traditional auth is the fallback.

https://fly.io/blog/api-tokens-a-tedious-survey/

tl;dr: most of the time you should use opaque random strings.

API tokens are a very small narrow part of the authorization universe. Having a shared secret relies on a trust relationship between the resource server and the identity provider that does not exist between, say, my SaaS backend and Google or Meta's login system.

The OP was talking about sessions (which include session cookies and API tokens). I'd argue these use cases are far more common for the average programmer than tokens and signatures that are used for federation, but I'll bite the bullet here:

JWT is a serviceable solution for service trust and federation. This use case often just requires a very-short-term token, so lack of revocation support is not an issue. Replay attacks are still an issue, but they can also be prevented with single-use nonces that are included in the token claims.

The OP's take (and my take as well) is that JWT is rarely the BEST solution for this use case. You kinda have to use it if you need to implement a standard that mandates JWT such as OpenID Connect. But OpenID Connect is a great example for a place where JWT was used, but was never really necessary. If you do use the authorization code flow securely (on the server side, with a strong client secret and proper CSRF protection) you don't need the ID token. In fact, you don't need to use any cryptography at all! Just like random session IDs, you've got a stateful solution that works reliably without any cryptography.

If you cannot do a series of authenticated network requests between HTTPS endpoints to verify trust, then a signed payload could be useful, but you've got better standards than JWS/JWT for that. That's all.

> If you do use the authorization code flow securely (on the server side, with a strong client secret and proper CSRF protection)

This restriction precludes all desktop clients, mobile clients, and webapp clients -- any place where you can't trust the client code to protect a secret.

I don't exactly disagree with you: Security becomes much easier once you rule out handling all the hard edge cases.

PKCE, OAuth 2.0 for Native Apps and the Device Code flow are a thing. In practice all of these clients work so well with OAuth 2.0, that the implicit and resource owner password credential grants have been removed from OAuth 2.1 and are the latest OAuth 2.0 BCP forbids the password grant and strongly recommends against the implicit grant.

... so, then, there is a need for something other than a shared opaque random string API key?

I feel like I'm being argued in a circle by a series of strawmen.

Random strings aren’t truly random, can be predicted, and don’t carry information that can be used elsewhere

For what? For just authenticating a client application to a server without getting access to any user data? By all means. You usually don't need the client credentials in OAuth 2.0 if you don't want to use it.

But if you want access to user information, you can't just give access to an app that has a shared secret key to a all user data for every single users in the planet. You need to authenticate the user somehow, and sharing the user's password directly with the app is not a good idea for many reasons.

Even if you trust the app to be "written without any bugs", the moment you allow the password grant in OAuth, your service cannot use CAPTCHA, MFA or Passkeys efficiently. The password grant does not allow any of these, so this app that you've let through becomes the weakest link for all cybercrime groups that want to attack your service.

https://www.latacora.com/blog/2018/06/12/inter-service-authe...

Archived from 2018, it’d be more relevant to bring up a recipe about Oreo pie.

That’s dodging the question, and a very generic and blank recommendation.

Seems like a very specific recommendation?

I asked for a perfect tech in your eyes, that once created was never updated or improved upon.

*edit: a recommendation for random strings in most cases isn’t perfect

In what way? Random strings are basically the gold standard. A lot of token cryptography actually destroys value already present in the random string.

You keep arguing random strings are “basically” perfect for cryptography. I’d potentially read your research paper for strings if you cited it, but my main question is what technology do you think is perfect? I don’t want to hear about misplacing pseudo-random strings until I know your basis for a perfect technology that never improves from updates.

Edit: also there have been how many attacks have there been on pseudo-random generators?

There have been basically no practical attacks on the LRNG or on Windows CryptGenRandom and its subsequents over the last 20+ years. People have gone of out of their way to build userspace RNGs and blown their toes off, but getrandom/urandom have been rock solid.

I think "don't use Mersenne Twister as your RNG" is a much safer bit of load-bearing advice than "use precisely these safe settings for your JWTs".

I hear a lot of “basically” and “rock solid”, yet still no answer to my question or no “perfect” claim.

Edit: an impractical attack can still be used

Name the impractical attack that can be used on getrandom(), please.

1) https://cwe.mitre.org/data/definitions/338.html 2) if a system has partial entropy, output can be predictable https://www.netbsd.org/~riastradh/tmp/20200510/getrandom.htm... 3) the setting flag of GRND_INSECURE https://www.netbsd.org/~riastradh/tmp/20200510/getrandom.htm...

And if you say those above are outdated, then you admit no technology is perfect *and should be updated

You’re welcome

I don't think you understand the links you just presented me. Two of them are getrandom man pages from NetBSD, and one of them is a CWE, which documents a broad class of vulnerabilities --- the specific vulnerability here being "not using getrandom".

It's ok if you're totally unfamiliar with this space, but I'd recommend replacing some periods with question marks in your comments.

I’m not quite sure you can read. The two points with getrandom directly tie into the points made, and the cwe points to the larger vuln.

Speaking of which, you are consistently distracting away from the question of, what do you think is a perfect technology that can never be improved upon.

Edit: separate track, i will agree random strings can be useful if you agree technology should always be updated.

EditEdit:provide me a recipie of Oreo cookie smore pie

Reply on news.ycombinator.com