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

191–200 of 247 posts

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

#191

Post by rocqua »

i_cant_speel wrote: post #188
Klathmon wrote: post #137

Earlier quoted context omitted.

> if someone makes a request over port 80 revoke that token I really like this trick! Not only do you now have a log of "shady stuff" happening, but you've gotten rid of the now compromised tokens instantly!

Can you elaborate on what this means? I'm not too familiar with authentication flows. Why would someone make a request over port 80? Why is that bad?

Im guessing a downgrade attack where a mitm convinces the client to use plaon http so they can read the plain text credential.

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

#192

Post by [deleted] »

rocqua wrote: post #191
i_cant_speel wrote: post #188

Earlier quoted context omitted.

Can you elaborate on what this means? I'm not too familiar with authentication flows. Why would someone make a request over port 80? Why is that bad?

Im guessing a downgrade attack where a mitm convinces the client to use plaon http so they can read the plain text credential.

[deleted]

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

#193

Post by metafunctor »

jakelazaroff wrote: post #136
metafunctor wrote: post #68

Earlier quoted context omitted.

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

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?

#194

Post by fiatjaf »

Ignoring the body of your question and answering just the title, I'm developing https://accountd.xyz/ as a system for mixing and linking identities (email, twitter, github, trello, indieauth for now) and using that for https://trackingco.de/, https://listhub.xyz/ and https://sitios.xyz/.

In theory anyone can use it, it works automatically and you don't have to register or anything like that, but I don't know if people are interested in it.

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

#195

Post by ramijames »

Well, we build and use Scatter (http://get-scatter.com), which is both a desktop app and a JS and C# library. This allows you to use the EOS or Tron blockchains and their account systems. Our users have local access to remote accounts on those networks. It's pretty amazing software, and it is really fun building something totally new.

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

#196

Post by fiatjaf »

Deestan wrote: 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.

How do you know what expert is worth hiring?

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

#197

Post by scottydelta »

felipelemos wrote: post #187
throwawaymath wrote: post #152

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.

Exactly, the attacker can always not use the browser and emulate a browser request if motivated enough.

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

#198

Post by Klathmon »

i_cant_speel wrote: post #188
Klathmon wrote: post #137

Earlier quoted context omitted.

> if someone makes a request over port 80 revoke that token I really like this trick! Not only do you now have a log of "shady stuff" happening, but you've gotten rid of the now compromised tokens instantly!

Can you elaborate on what this means? I'm not too familiar with authentication flows. Why would someone make a request over port 80? Why is that bad?

To kind of combine the others comments and add some more depth:

HTTPS runs over port 443, and port 80 is normally for HTTP only.

Most people setup their webservers to serve HTTPS over 443 and redirect port 80 to 443 so anyone that sends something to `http://example.com` automatically gets forwarded to `https://example.com` (and then the browser can tell them to ONLY use the HTTPS version from that point forward)

This is a generally "acceptable" tradeoff between usability and security.

But when you control the API and the client, you can know that you will never send credentials over HTTP, only HTTPS. So you should have nothing coming over port 80.

Then, with a simple script, you could set it up so that it will accept everything on port 80, and if it includes a token of some kind from your app, it logs the request, then marks the token in your database as "expired" so it can no longer be used anywhere (even on port 443).

There's a kind of attack sometimes called "SSLStrip" which can block all requests for someone to an HTTPS version of the site, and in many cases can trick the client into trying the HTTP version if the HTTPS fails. This kind of thing would not only stop that attack, but it would also log it and ensure that any tokens sent that way would be instantly expired, so that the attacker (who saw the tokens when the client tried to send them) can't use them.

There are other reasons too. It will notify you of any developer-mistakes that are sending credentials over HTTP (it's a one letter difference, and despite the best efforts sometimes these kinds of things slip into a codebase as typos or a dev just not thinking), and it can help you tell "scanning" traffic from "normal" traffic (since nothing in your app will ever talk to port 80, so everything on port 80 is "bad" and can give you some clues into what attackers are trying on your network).

And the best part is that it's easy! I could probably throw something together for our API servers that does this in a day or so start-to-finish. That's a REALLY good ratio between time spent and security benefit that you normally don't get!

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

#199

Post by spricket »

If someone else needs to use your API, please use OAuth/OIDC. I've seen countless hand-rolled (and insecure) authentication schemes. It's almost always a nightmare. If you plan on connecting this to multiple apps and partners, rolling your own will create a hellscape for everyone

If you use OAuth, anybody can connect using a standard library and "flow" across tons of languages. And you don't need to worry about screwing up the most security critical part of your API. It will save you countless headaches.

Some people bash OAuth because of JWT, but this overblown. Storing permissions in a token is the only sane way to do things if you end up with multiple services down the line (you will).

The whole revocation debate is a bunch of noise about nothing. Make the expiration interval fairly short, and if that isn't enough you can make a cache of revoked tokens that only needs to live as long as your expiration interval. This is still orders of magnitude more efficient than not storing permissions in the token and just as secure.

If you need to revoke all tokens in a breach scenario you just change your signing key. I recommend using SHA256 based signatures rather than public/private key since even though public/private is theoretically more secure, calculating signatures is quite a bit of overhead. If your backend is using a fast language like java/C#/Go, the majority of server CPU will be signing tokens.

Read about OAuth and ignore the haters. The design is well thought-out, secure, and efficient. If it was really that bad you wouldn't see most of the tech giants migrating to and using it. There's a lot of people that don't like it because they don't understand it well enough.

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

#200

Post by pritambaral »

geezerjay wrote: post #155
pritambaral wrote: post #147

Earlier quoted context omitted.

No, they've described a Bearer Token workflow. JWT is a specific method that also (most times) uses Bearer tokens, but it wasn't the first, nor does it have a monopoly on Bearer tokens. I remember building a service when I was experimenting with web development that used randomly generated tokens in a custom HTTP header, and that is closer to Bearer Token (the standard) than Bearer Token is to JWT.

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 JWT", whereupon [3] clarifies that the original suggestion is just a normal bearer token scheme, which, I claim, shares nothing with "JWT" except the "T".

> ... JWT, which is a bearer token scheme ...

The "T" in "JWT" is the least interesting bit of JWT, and merely a necessity.

> It's irrelevant if the workflow is specific to JWT or is shared by other bearer token schemes

When not talking about any specific bearer token scheme, it is absolutely relevant. Only the generic point was under discussion, until JWT was introduced. 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.

----

[1]: https://news.ycombinator.com/item?id=18768173

[2]: https://news.ycombinator.com/item?id=18768212

[3]: https://news.ycombinator.com/item?id=18768242

Post reply on HN