Live data from Hacker News

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

news.ycombinator.com

201–210 of 247 posts

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

#202
post #79

Earlier quoted context omitted.

It's not called two factor authentication. Two factor authentication is when you have two factors for authentication. This is just one..

something you have (phone) & something you know (password)

I only “know” the code it gave me for what, a few seconds? If at all... macOS now automatically copies them from texts and 1PW automatically copies TOTPs for relevant logins to the pasteboard. I think the “know” part is something _you_ create/control and use over many instances.

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

#203
I would echo a bunch of the comments in this thread. I am only posting this because I own a healthcare startup and your question put the fear of god in me. I would strongly advise that you build a different app if you do not already possess the knowledge required to do this. If you have the means hire a professional and you will be better off. You need to get this right from day 1 or people will get hurt, you will be fined into oblivion and/or possibly thrown in jail. There are also numerous other security concerns that you should be worried about since Auth is just the tip of the iceberg.

I will add the following details which are specific for healthcare companies and a bit of inside baseball. Typically people use an email address as the lookup field for a user account. Since email addresses are considered protected health information under HIPAA, I would highly suggest you use usernames instead (possibly auto generated to be safe). HITRUST includes some details about password rules for their certification process. No one will question you if you follow their rules (I think it's 12 characters minimum 1 Upper/Lower/Symbol/Number each). Use a banned password list, you can find one here[0]. You are going to want to set up some manner of 2 factor authentication (I would recommend U2F or TOTP) for all accounts with manual code backup. OAuth and OpenID are goddamn nightmares. You need to own and manage this process entirely by yourself.

[0]: https://haveibeenpwned.com/Passwords

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

#205

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?

How can they send authenticated requests if they can't access your cookies and your backend ignores the cookie header?

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

#206
post #183

I wonder why macaroons [1] are not even mentioned in this discussion yet. They have all the upsides of cookies, but also can be narrowed down to be handed to third parties (good for APIs), caveats, and have a standardized and implemented [2] verification scheme. I wonder why they don't see wider use. Do they have significant downsides? [1]: http://hackingdistributed.com/2014/05/16/macaroons-are-bette... [2]: https://…

Macaroons have their own issues, see my previous comment here: https://news.ycombinator.com/item?id=17879403

If you've got questions about them I'm happy to answer.

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

#207
We did the bakeoff and AWS Cognito is the by far the cheapest. It's not as well documented but supports Open Id Connect just like all the other 3rd party auth solutions. The downside is that Cognito does not support a Resource Owner Password Flow (not recommended anyhow. see RFC6749).

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

#208
post #154

Earlier quoted context omitted.

He suggests KISS: you can probably get away with plain old server-side auth, and if you really need client-side tokens, use something simple that just encrypts and signs them: https://news.ycombinator.com/item?id=13612941#13615634

> Something simple that just encrypts and signs them Like JWT? I feel like that argument goes around in circles.

JWT's are NOT encrypted by default. They are cryptographically signed. That is totally different.

If you get somebody's JWT, you can get everything stored in the token as well.

If you want it to be encrypted, you have to encrypt the token (presumably following JWE).

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

#209
post #8

I was in a similar position, we started using Okta and eventually migrated to AWS Cognito. Rolling your own auth is a recipe for disaster unless you know what you are doing and really need to. Also, be prepared to be fairly locked in once you choose an auth provider, especially if you choose one that is fairly integrated into your ecosystem.

We use Lambda authorizers, how do you use cognito

You can create a custom auth flow using lambda and cognito; you can return a series of challenges and create a stateful flow using session tokens which results in a set of access, identity, and refresh tokens.

Alternatively you can use the auth code flow baked into lambda; if you have premium support make a case and someone can walk you through it :)

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

#210
post #124
post #70

Earlier quoted context omitted.

> 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 ar…

> 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? ;)

Post reply on HN