Ask HN: What do you use for authentication and authorization?
201–210 of 247 posts
Re: Ask HN: What do you use for authentication and authorization?
#202Earlier 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)
Re: Ask HN: What do you use for authentication and authorization?
#203I 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.
Re: Ask HN: What do you use for authentication and authorization?
#204Re: Ask HN: What do you use for authentication and authorization?
#205Earlier 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?
Re: Ask HN: What do you use for authentication and authorization?
#206I 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://…
If you've got questions about them I'm happy to answer.
Re: Ask HN: What do you use for authentication and authorization?
#207Re: Ask HN: What do you use for authentication and authorization?
#208Earlier 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.
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?
#209I 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
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?
#210Earlier 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…
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? ;)