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

231–240 of 254 posts

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

#231

Post by thijsvandien »

tptacek wrote: post #219
thijsvandien wrote: post #218

Earlier quoted context omitted.

Could you clarify why (or when) to use bearer tokens instead of Basic Authentication (i.e. sending username and password) with every request? Is it that if the server is compromised, only passwords from future logins can be stolen rather than those of everyone who performs a request? The cost of checking the hash? Other reasons?

The purpose of a password is to have an authenticator that is human-readable/writeable and, ideally, human-memorable. Ideally, a strong password is stored only in a person's head; in the very worst (and unfortunately common) case, it's also stored in a password manager. API authentication doesn't have the memorability problem, because the password has to be stored somewhere the client program can reach it. But, as yo…

It was my impression that the token is obtained by supplying username and password to a login API, through which it can also be replaced when it expires. Now it seems that I was wrong. How do you suggest the token be managed?

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

#232

Post by sloxy »

dboreham wrote: post #221
tptacek wrote: post #134

Earlier quoted context omitted.

The AWS API runs over TLS, and uses signed requests.

Perhaps because it was originally designed for use without TLS? Request signing was pretty much ubiquitous 10 years ago.

more likely it's so they don't have to have a more convoluted process where they call out to requesting service to verify RQ & all which that entails (on both sides).

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

#233

Post by tptacek »

stephenr wrote: post #224
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…

I like your "keep it simple" approach here. Can you confirm re: your recommendation for random "bearer token" auth, are you talking about just short-lived tokens that are the response to a regular user auth flow (ie login in one request, get a token, use that for subsequent requests in this "session" ala a session cookie) or do you (also) intend it for long-lived tokens used eg for machine accounts?

You can use short-lived tokens, or you can use long-lived tokens. A long-lived 128 bit secret is superior to a username/password, for reasons explained elsewhere on the thread. So if your short-term token scheme requires programs to occasionally deploy the root account's password (or really any password that a user had to come up with), it's flawed.

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

#234

Post by tptacek »

thijsvandien wrote: post #231
tptacek wrote: post #219

Earlier quoted context omitted.

The purpose of a password is to have an authenticator that is human-readable/writeable and, ideally, human-memorable. Ideally, a strong password is stored only in a person's head; in the very worst (and unfortunately common) case, it's also stored in a password manager. API authentication doesn't have the memorability problem, because the password has to be stored somewhere the client program can reach it. But, as yo…

It was my impression that the token is obtained by supplying username and password to a login API, through which it can also be replaced when it expires. Now it seems that I was wrong. How do you suggest the token be managed?

You can do that, or you can just have a page in the application where the user manually fetches a new API token, which is a pretty common UX for this.

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

#235

Post by tptacek »

e12e wrote: post #214
oxymoron wrote: post #213

Earlier quoted context omitted.

Well, you don’t, so if that’s a requirement you’ve got to do it some other way.

You can rotate the secret to invalidate all tokens.

No, you can't. That breaks all of your users, and so you'll rarely do it, even when it might be warranted. Don't engineer security countermeasures that you (a) might need to rely on and (b) will be afraid to use.

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

#236

Post by tptacek »

Blazespinnaker wrote: post #225
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…

A lot of text for your argument which is x isn't secure. Not very compelling. Signed rest requests ensure that auth tokens can not be leaked as each request is individually signed by a private key. Your extreme example btw is hyperbolic. Providing signing sample code to clients is pretty typical

I'm explaining where I'm coming from as a courtesy. I am also comfortable with the number and kind of HN readers who would simply take my argument as-stated without justification: "don't do signed URLs if you can get away with bearer tokens".

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

#237

Post by stephenr »

tptacek wrote: post #233
stephenr wrote: post #224

Earlier quoted context omitted.

I like your "keep it simple" approach here. Can you confirm re: your recommendation for random "bearer token" auth, are you talking about just short-lived tokens that are the response to a regular user auth flow (ie login in one request, get a token, use that for subsequent requests in this "session" ala a session cookie) or do you (also) intend it for long-lived tokens used eg for machine accounts?

You can use short-lived tokens, or you can use long-lived tokens. A long-lived 128 bit secret is superior to a username/password, for reasons explained elsewhere on the thread. So if your short-term token scheme requires programs to occasionally deploy the root account's password (or really any password that a user had to come up with), it's flawed.

Right - I agree that deploying a human-used password is not a viable option.

I'm thinking more in terms of deviating from your described solution on storing keys (particularly long term ones), by storing them hashed (and thus require some kind of account identifier prefix in the Bearer token string).

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

#238

Post by u801e »

stephenr wrote: post #226
u801e wrote: post #191

Earlier quoted context omitted.

> Wait for the email to arrive and follow the retrieval process to get the certificate Is there a reason why the server couldn't send the certificate back to the browser via HTTPS? > You then need a non-trivial amount of work to export the private key and certificate and install it on all of your devices, Would it not be better to just use a different key for each device? That is, repeat steps 1 and 2 for every devic…

A number of the undesirable factors described here (email, 12 month limit) are because that process isnt generating a client certificate for use on a private site, it's generating an S/MIME cert for handling encrypted/signed email.

I guess I'm not clear on the current process. If we had a process as shown below, I think it would be much easier to get people to adopt client certs.

1. Click on link to sign up for new account on news.ycombinator.com

2. Enter information for the account including a CSR that your browser generates for you

3. Submit the information to the server

4. Server servers another page that confirms account creation and includes the certificate

5. The browser provides a way to import that certificate to a client certificate store it maintains

6. Next time you visit the website, your browser knows to use that client certificate

Registering other browsers would require sending the CSR via the first registered browser and copying the certificate that the server returns to the second browser.

Of course, this would be for websites that don't have a need to verify your identity (like reddit or Hacker News). For banks, or credit cards, there would have to be a way to verify the identity of the person signing up for an account.

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

#239

Post by scriptkiddy »

icebraining wrote: post #195
scriptkiddy wrote: post #141

Earlier quoted context omitted.

Cert renewal can be automated the same way letsencrypt does it for instance.

Let's Encrypt validates during each renewal if the server still controls the DNS and/or HTTP endpoint. The point of the limited duration is to ensure that an attacker who got a copy of the certificate, but who doesn't control the DNS or HTTP endpoint, can't keep using it for long. In this case, I don't see any automated check that can verify that the client trying to renew the cert is the original device, so there's…

That is an interesting limitation. I'm sure there is some way to get around it. However, I'm not a network security expert. I just thought using SSL certs for authentication was an interesting idea.

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

#240

Post by scriptkiddy »

icebraining wrote: post #190
scriptkiddy wrote: post #109

Earlier quoted context omitted.

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.

Well, I mean that's true of almost every authentication method. If I have 2FA set up and someone knows my password and has access to my phone, of course they get into my account. I have a pentester friend who told me once: "Nothing is unbreakable or un-exploitable." I tend to believe that. Things like social engineering can always be applied to get the information you need to spoof credentials or gain access to critical systems. If someone is motivated and has enough resources, there's no amount of security methods that can stop them.
Post reply on HN