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

Ask HN: What's the recommended method of adding authentication to a REST API?

news.ycombinator.com

Post reply on HN
Print view View original

181–190 of 254 posts

Re: Ask HN: What's the recommended method of adding authentication to a REST API?

#181

Post by batoure »

nullbyte wrote: post #169
tptacek wrote: post #116

This question comes up all the time on HN. I'm one of a bunch of people on HN that do this kind of work professionally. Here's a recent comment on a recent story about it: https://news.ycombinator.com/item?id=16006394 The short answer is: don't overthink it. Do the simplest thing that will work: use 16+ byte random keys read from /dev/urandom and stored in a database. The cool-kid name for this is "bearer tokens". Yo…

What's so bad about JWT's? The cryptographic protocol is sound.

There is nothing wrong with JWT, implementing them requires some thought so that you don't leak sensitive info as well as configuring your backend properly.

Large swaths of the internet love to hate on JWT but its a major feature in oauth2 and is in use all over the place as decentralized APIs have become more commonplace.

Re: Ask HN: What's the recommended method of adding authentication to a REST API?

#182

Post by 013a »

tptacek wrote: post #116

This question comes up all the time on HN. I'm one of a bunch of people on HN that do this kind of work professionally. Here's a recent comment on a recent story about it: https://news.ycombinator.com/item?id=16006394 The short answer is: don't overthink it. Do the simplest thing that will work: use 16+ byte random keys read from /dev/urandom and stored in a database. The cool-kid name for this is "bearer tokens". Yo…

> Do not use JWTs, which are an increasingly (and somewhat inexplicably) popular cryptographic token that every working cryptography engineer I've spoken to hates passionately.

Can we get more intel behind why JWT is bad? I've always been told that as long as you explicitly check both the signature and that the signature algorithm type is what you expect, its fine. Libraries tend to make the mistake of not doing that second part for you, so implementations have to be aware of that.

The one concern I've always had is that even though they are stateless, most implementations end up making a db request to get info about the user anyway (i.e. their role and permissions), so the stateless advantage of JWT isn't as big as it is touted. You can embed that into the JWT, but then the token inevitably gets huge.

Re: Ask HN: What's the recommended method of adding authentication to a REST API?

#183

Post by batoure »

tptacek wrote: post #159
Blazespinnaker wrote: post #149

Earlier quoted context omitted.

Signed REST requests are good too, more secure. And what’s wrong with delegated auth?

Signed requests are not in general more secure: * The implementation of cryptographic "signing" (really, virtually never signing but rather message authentication) is susceptible to implementation errors. * The concept of signing is susceptible to an entire class of implementation errors falling under the category of "quoting and canonicalization". See: basically every well-known implementation of "signed URLs" for e…

>susceptible to implementation errors.

So just like anything else you might want to implement if you do it wrong its insecure.

Re: Ask HN: What's the recommended method of adding authentication to a REST API?

#184

Post by tptacek »

zaroth wrote: post #179
tptacek wrote: post #171

Earlier quoted context omitted.

All of this seems inferior to just using a 128 bit random token drawn from /dev/urandom and stored in a database. If you see "HMAC" in an API authentication design, something weird and probably bad is happening.

I would say, store the hash of the token in the database, but that's my personal preference to add a bit of defense against timing attacks, insider stealing the token, or token database breach.

I don't think this buys you anything. Keep things simple.

Re: Ask HN: What's the recommended method of adding authentication to a REST API?

#185

Post by tptacek »

batoure wrote: post #183
tptacek wrote: post #159

Earlier quoted context omitted.

Signed requests are not in general more secure: * The implementation of cryptographic "signing" (really, virtually never signing but rather message authentication) is susceptible to implementation errors. * The concept of signing is susceptible to an entire class of implementation errors falling under the category of "quoting and canonicalization". See: basically every well-known implementation of "signed URLs" for e…

>susceptible to implementation errors. So just like anything else you might want to implement if you do it wrong its insecure.

So really what everyone should do are PAKE schemes based on isogenies, because then we're all post-quantum secure, and, after all, it's only insecure if you do it wrong.

Re: Ask HN: What's the recommended method of adding authentication to a REST API?

#186

Post by san_at_weblegit »

everdev wrote: post #124
tptacek wrote: post #116

This question comes up all the time on HN. I'm one of a bunch of people on HN that do this kind of work professionally. Here's a recent comment on a recent story about it: https://news.ycombinator.com/item?id=16006394 The short answer is: don't overthink it. Do the simplest thing that will work: use 16+ byte random keys read from /dev/urandom and stored in a database. The cool-kid name for this is "bearer tokens". Yo…

Don't major companies like Google use JWTs?

The answer would be yes with a rider. It would vary across the use cases and security requirements.

Re: Ask HN: What's the recommended method of adding authentication to a REST API?

#187

Post by adambkaplan »

tptacek wrote: post #116

This question comes up all the time on HN. I'm one of a bunch of people on HN that do this kind of work professionally. Here's a recent comment on a recent story about it: https://news.ycombinator.com/item?id=16006394 The short answer is: don't overthink it. Do the simplest thing that will work: use 16+ byte random keys read from /dev/urandom and stored in a database. The cool-kid name for this is "bearer tokens". Yo…

Key quote here is

> Do the simplest thing that will work:

For many a long, a randomized bearer token will do. Depending on the type of data you expose via the API (example - financial data, PII) this may not be sufficient for your security team or auditors.

Re: Ask HN: What's the recommended method of adding authentication to a REST API?

#188

Post by icebraining »

LandR wrote: post #34
icebraining wrote: post #25

Earlier quoted context omitted.

Can't store password on device (it's a device we don't control) Can you expand on this? Because storing a device-specific password (or api key, which is essentially the same) would be my first suggestion. If it's because you can't configure the device, then my suggestion would be to create a process that embeds the device key into the software before deploying to each particular device.

We need to run software on clients machines, we need this software to be running as service (no UI). This service needs to communicate back to use securely via our Web API. We could have a password entered by our systems guys who deploy to a new machine for the first time, the service encrypts and stores that on disc, then each time it wants to talk to us it can decrypt its password. I'm not sure if that would be a g…

I'm not sure if that would be a good solution, or is it just as insecure as having password in the code.

It's just as insecure, as the software would need to store the decryption key itself in plain-text.

But why are you so concerned about keeping the password secret? As long as each device has a different password, you can identify abusive uses (too many requests, or from multiple sources, etc) and block that account.

What do you fear that the client could do with the device password?

Re: Ask HN: What's the recommended method of adding authentication to a REST API?

#189

Post by batoure »

tptacek wrote: post #167
logicuce wrote: post #164

Earlier quoted context omitted.

With the right choice of algorithm, and if you control the code which interprets that JWT (whitelisting the alg and choosing the right library), I don't see a reason why JWT would be insecure.

It's absolutely true that if you do everything correctly, a JWT implementation can be secure. Generally, in crypto engineering, we're looking for constructions that minimize the number of things you need to get right.

Yeah this is the problem with crypto security people they are one dimensional. JWT has the benefit of allowing disconnected services to send each other information through the front end.

Which minimizess the number of things you need to get right or in your words equals more secure.

Designing a token that can be validated instead of looked up. (Design/Implement once)

Or

maintaining, updating and monitoring a set of firewall rules so that app-servers in network zone x and y can make call backs to a database in network zone z.(design many implement many)

There are a ton of great reasons to use JWT at scale. As with anything use case is important.

Re: Ask HN: What's the recommended method of adding authentication to a REST API?

#190

Post by icebraining »

scriptkiddy wrote: post #109
LandR wrote: post #34

Earlier quoted context omitted.

We need to run software on clients machines, we need this software to be running as service (no UI). This service needs to communicate back to use securely via our Web API. We could have a password entered by our systems guys who deploy to a new machine for the first time, the service encrypts and stores that on disc, then each time it wants to talk to us it can decrypt its password. I'm not sure if that would be a g…

I Found a somewhat interesting solution for this issue. I assume you know what an ssh public/private key is, correct? Well, apparently, there is a way to apply this concept of ssh public key authentication to the HTTP protocol. This technique is referred to as "Mutual Authentication": http://www.cafesoft.com/products/cams/ps/docs32/admin/SSLTLS... Basically, it's 2-way SSL. You use signed SSL certs to authenticate th…

SSL client certs are useful, but they don't fix the problem feared by LandR: like a password, they too can be copied and used by someone who controls the machine.
Post reply on HN