Live data from Hacker News

Ask HN: What do you use for authentication and authorization?

news.ycombinator.com

211–220 of 247 posts

Re: Ask HN: What do you use for authentication and authorization?

#211
post #4

Hard to say without more concrete details, but if I had to reply in broad strokes: - For web, user/pass login exchanged for plain session cookies. Should be marked httpOnly/Secure, and bonus points for SameSite and __Host prefix [1] - For web, deploy a preloaded Strict-Transport-Security header [2] - For api clients, use a bearer token. Enforce TLS (either don't listen on port 80, or if someone makes a request over p…

Why not JWT?

An oversimplified version of the arguments against JWT for session management (as well as the JOSE specification for signing and encryption) ...

1. The specification has points of ambiguity that have led to a number of flawed implementations. 2. JWT is saddled with unnecessary complexity which also contributes to recurring implementation flaws. 3. JWT increases the complexity of session revocation in contrast to a simple, stateless session ID.

The arguments and counter-arguments are a bit more involved, but be aware that by the time you account for the downsides, you may have negated the value you hoped to gain from stateless web tokens.

If you can use a simple session id, use it. If you need JWT to support external authentication providers, use a short expiration and swap the (fully verified) token for a session id.

Re: Ask HN: What do you use for authentication and authorization?

#212
post #105

Earlier quoted context omitted.

Also, people make a big stink when authentication cookies aren’t marked as HTTPONLY. Storing tokens in localstorage (even sessionstorage) is just as bad but for some reason more accepted.

Stealing tokens from localstorage or cookies means the attacker can run code in the user's security context. Why would they limit themselves to stealing tokens? Using them outside of the browser would be stupid, anyway, as it would risk tripping reauthentication, IPS, or whatever. HttpOnly is a joke, and people should stop claiming it helps with XSS. It does not help. It's security benefit is at most neutral. In fact…

Persistent access via an authentication token is a hell of a lot more reliable than relying on the user not navigating from/refreshing a specific page where XSS is present.

Re: Ask HN: What do you use for authentication and authorization?

#213

Earlier quoted context omitted.

You're trying to be disingenuously pedantic. It's irrelevant if the workflow is specific to JWT or is shared by other bearer token schemes. The point is that JWT, which is a bearer token scheme, follows that workflow, thus it makes no sense to present that workflow as an alternative to the JWT workflow, as it's precisely the same.

> ... as it's precisely the same. If you believe JWT is "precisely" the same as mere presentation of a token, then you're woefully ignorant of JWT. > ... it makes no sense to present that workflow as an alternative to the JWT workflow ... But that's not what happened, is it? In fact, it's the opposite. As I read it, [1] suggests a bearer token workflow, to which [2] replies that the suggestion is "an awful lot like J…

> JWT is not just another bearer token scheme. It comes with its own additional obligations, restrictions, and extra steps, not to mention the purpose-defeating pitfalls.

Care to provide an example?

Re: Ask HN: What do you use for authentication and authorization?

#214

Earlier quoted context omitted.

The author hasn’t clarified yet, but I suspect what they’re referring to is the fact that CORS does not support granular access control. If you make something public under CORS, any client can retrieve the resource if no other authorization or authentication check is in place. It’s not a system of authentication, it’s a system of authorization - specifically, for authorizing hosts to request resources which normally…

CORS is not a tool to turn resources private, but to protect the browser (not the server's content) from cross domain requests.

Yes, that's precisely why CORS is a poor fit for authentication :)

Re: Ask HN: What do you use for authentication and authorization?

#215
post #124

Earlier quoted context omitted.

> An attacker was able to somehow issue a bunch of tokens for himself I'm not expert in JWT and just jumping in here, but wouldn't that imply total compromise of the PKI if this ever happens? I'm saying, if this scenario comes to pass, with basically any old authentication system, isn't it now time to roll the master keys and invalidate _every previously issued_ token/session the old-fashioned way, by disavowing the…

> I'm not expert in JWT and just jumping in here, but wouldn't that imply total compromise of the PKI if this ever happens? Not necessarily. Let's say I steal your password and use it against the auth endpoint to get 10 one-time tokens for your account. Re-rolling the master key is a solution, but a very radical one if I can just invalidate all your tokens don't you think? ;)

> Not necessarily. Let's say I steal your password and use it against the auth endpoint to get 10 one-time tokens for your account.

The tokens are valid, thus there is no objective reason to reject them other than there was an unrelated security failure elsewhere in the system.

Additionally, tokens are generated per request and are short-lived, with an expiration timestamp that is just enough to send a request to the server.

When the token is passed to the server, the nonce is added to the server's scratchpad memory to revoke the token and thus avoid replay attacks. If anyone for some reason wants to revoke a token, they only need to add the token's nonce to the revoked list. If the nonce is present in the list then the server rejects the token and triggers a token refresh.

Re: Ask HN: What do you use for authentication and authorization?

#217

Earlier quoted context omitted.

If you use cookies as a storage mechanism and ignore the cookie header on your backend, you close the door to CSRF attacks. Here's one glaring problem with local storage: literally any script on your page can access it (for example, vendor scripts). Cookies can only be accessed by scripts from the same domain from which they're created.

That's true, but if you run untrusted scripts on your site it's pretty much game over, anyway. Why should those scripts limit themselves to stealing tokens when they can send authenticated requests from the browser? To put it another way, why would you care about knowing the root password when you have a way to run a root shell at will?

It's interesting that every time this comes up people talk as though the only vector for a malicious script running on your site is you serving it yourself. A reminder that browsers have a ridiculously lax permissions/security model for extensions which extension developers have been shown again and again to abuse (see the Stylish incident for instance).

Re: Ask HN: What do you use for authentication and authorization?

#218
post #90

Professionals. Hire an expert. If you can't answer these questions yourself (which is fine - it's specialized knowledge separate from the skillset needed for building a useful application), you are lacking critical competence for coding anything handling health information. The security minefield is much much bigger than the login page.

I would say you are assuming a bit too much (but just a bit). There isn't enough information on the question to tell wether the OP is a complete novice with no idea of the minefield he is getting it, or if he is somebody competent that wants a list of current practices to start further research.

<3 thank you. I have done a lot of research, and yes my healthcare knowledge is somewhat lacking. However my goal was to ask an open ended question to see what others are doing. Research is always key. I also do plan on hiring those with experience in the space as well

Re: Ask HN: What do you use for authentication and authorization?

#219
post #91

We use SAML set up for our customers' identity providers (most of the time, Office365 Azure AD or Google Suite), from a NuGet package. From there, it's a bearer token encoded in JWT format for ease of debugging. From another NuGet. We also support username and public key authentication for our SFTP server. We do support username and password if necessary.

and what do you use for authorization?

Custom rules on top of ASP.NET middleware.

Re: Ask HN: What do you use for authentication and authorization?

#220
post #97
post #90

Professionals. Hire an expert. If you can't answer these questions yourself (which is fine - it's specialized knowledge separate from the skillset needed for building a useful application), you are lacking critical competence for coding anything handling health information. The security minefield is much much bigger than the login page.

Classic hacker news. Ask for technical advice, get called incompetent.

Very few people in the field are competent to design security for health systems. No shame in being like most professional software developers. Immense shame in causing a life-altering breach because you couldn’t recognize the limits of your expertise.
Post reply on HN