Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 247 posts

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

#61

Post by weego »

yolo1 wrote: post #42
mattbgates wrote: post #35

Email or text message sent to customer and they just input the number they were sent to match.

This is called two factor auth. SMS is not considered a secure method of transport (mostly due to porting). It only solves opportunistic password compromise via password dumps.

In reality it solves far more than that for the average system for the average user. No on in reality is having their mobile number socially engineered to get into startup xs system. It's a good place to start until you are at a scale where you would have dedicated security engineers to work on the problem.

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

#62

Post by askmike »

atonse wrote: post #11
arkadiyt wrote: 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…

Also (separate post for separate replies), why not use CORS? this is the first I'm hearing about this. SPA websites often use things like JWT and CORS (ours included)

Wondering about the same thing.

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

#63

Post by techsupporter »

weego wrote: post #61
yolo1 wrote: post #42

Earlier quoted context omitted.

This is called two factor auth. SMS is not considered a secure method of transport (mostly due to porting). It only solves opportunistic password compromise via password dumps.

In reality it solves far more than that for the average system for the average user. No on in reality is having their mobile number socially engineered to get into startup xs system. It's a good place to start until you are at a scale where you would have dedicated security engineers to work on the problem.

> No on in reality is having their mobile number socially engineered to get into startup xs system.

The problem is that you can't know whether that's the case at start, at some point in the future, or never. You'll only find out that your guess was wrong when you're breached which is never a good time for any service, particularly one covered by HIPAA. Besides, why intentionally implement a known-to-be-insecure second factor method? This is brand new code; there's no need to incur technical debt from day one. Which leads to:

> It's a good place to start until you are at a scale where you would have dedicated security engineers to work on the problem.

Except that day never comes for a variety of reasons. "Users already expect it so we can't remove that." "There are several dozen other security audits/features/fixes we need to make, let's prioritize those first." "What? SMS is insecure? Weird, never knew that."

Also, if we don't start making the decision now, before the second factor is ever implemented, to move away from using SMS as that second factor for the reasons it is known to be broken, when do we start?

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

#66

Post by jondubois »

mcbits wrote: post #18
aeleos wrote: post #12

Earlier quoted context omitted.

Isn't JWT also a type of bearer token? Could you please provide some more detailed arguments about why JWT shouldn't be used other than linking its wikipedia article?

JWT is fine if "revoke" isn't in your vocabulary for the service. If you do need to revoke tokens, JWT becomes a racey contraption that requires synchronizing and looking up state on every request, the avoidance of which was the main reason to use JWT in the first place.

If you use a realtime transport like WebSockets, you could keep automatically re-issuing a fresh JWT with a very short (e.g. one minute) expiry every 50 seconds; just push them at an interval to authenticated clients. That way your banning mechanism would only have a one minute a delay. No need to revoke tokens; just let them expire.

In such a system, a user would be logged out after one minute of closing the connection... Probably good enough for online banking. In a way, this is safer than standard sessionId-based auth because once you've issued the token, you don't need to worry about scenarios where the user has gone offline suddenly.

There are very few systems that need banning with down-to-the-millisecond accuracy.

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

#67

Post by sebslomski »

All new apps I’m building are based on password-less auth [1] & bearer token. NoPassword is just so much more comfortable than having to remember passwords. And boy, people are really bad at coming up with passwords - you might have seen it this Christmas at your parents’. [1] http://notes.xoxco.com/post/27999787765/is-it-time-for-passw...

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

#68

Post by metafunctor »

moltar wrote: post #54
metafunctor wrote: post #36

Earlier quoted context omitted.

If you have an API, you can program your web client like an API client, using bearer tokens for authentication (put them in local storage). It's probably better than cookies.

How is that better than a cookie though? Cookies already provide automatic storage and expiry mechanism. Bonus feature is that they are not accessible by JS code at all, if set httponly flag.

Browsers automatically attach cookies to HTTP requests, opening the door to attacks like CSRF.

The security impact of automatic client-side expiry is tiny, since token expiration must be done server-side anyway.

The HttpOnly flag as an XSS mitigation is almost useless; competent attackers will simply run their code from the victim's browser and session. To protect against XSS, HttpOnly doesn't really help you at all. You should be setting a CSP that prevents inline and 3rd party scripts by default, and whitelist what you must.

Overall, cookies may seem like they have a lot of security features, but in reality they are just patches over poor original design. IMHO, using local storage is probably better, because there's less room to get it wrong.

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

#69

Post by vwpolo3 »

The open source ory ecosystem ( http://github.com/ory/ ) might have what you're looking for, but it's definitely for advanced usecases. I know a lot of people that worked with Auth0/Okta/AWS Cognito but got so frustrated by downtimes, bugs, and complexity that they moved away. But it is an option for rapid prototyping although I'd keep a "replace it" somewhere in my milestone planning. Another possibility is Keycloak which is very enterprise / java fullstack and quite complex to understand.

Most advice in the comments is pretty bad though. Stuff like "API Clients need bearer tokens" is completely backwards and pushed by marketing people from companies (Auth0, Okta, ...) that misuse open protocols (OAuth2, OIDC) as a way to legitimize the closed source saas approach they took. Along the lines "if it looks complex it looks secure because most people have no idea". It's actually very easy to use cookies (httpOnly, secure) with API clients and you're saving yourself so much complexity with refreshing tokens and all that stuff.

Yet another possibility for super rapid prototyping is: https://github.com/bitly/oauth2_proxy

edit:// I forgot KeyCloak, but it's also for advanced enterprise use cases (SAML, OIDC, Realms, ...) and (from what I've heard) with a steep learning curve and heavy.

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

#70

Post by kilburn »

geezerjay wrote: post #56
throwawaymath wrote: post #51

Earlier quoted context omitted.

Again, expiry is not revocation. This is an uncontroversial fact - if you disagree, please advise me as to how you'd revoke a token prior to its timestamp-mandated expiration without augmenting it further. And the jti field is not intended for what you think it is. Anti-replay is not at all the same as revocation. Those are different things entirely. I certainly believe (and have seen) the jti field used in the manne…

> Again, expiry is not revocation. Issue and expiration timestamps are used along with nonces to enforce single use tokens. Once a token is used then the client is expected to discard and refresh the token. Implementations are also free to keep track of issued tokens and that does not pose any problem in the real world. > And the jti field is not intended for what you think it is. Anti-replay is not at all the same a…

> Why are you expecting to revoke a token in a scenario where the token is supposed to be used once?

An attacker was able to somehow issue a bunch of tokens for himself. Now you want to invalidate them even though they're not used yet.

> Either the token is deemed valid and accepted or it's invalidated and rejected, which triggers clients to refresh the token and retry the request.

The other point here is that you are probably (not always, not in every possible case, but in most common cases) better off using just a bearer token (refresh it on every use if need be). There's no performance benefit in using stateless tokens when they can be used only once, and handling bearer tokens is much easier from a gun-to-shoot-your-feet-with perspective.

Post reply on HN