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

221–230 of 254 posts

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

#221

Post by dboreham »

tptacek wrote: post #134
dboreham wrote: post #132

Earlier quoted context omitted.

Signed requests were also invented when the transport connection was in the clear: if the request were not signed then it could be modified in transit by an attacker. These days all sessions are encrypted (SSL/TLS) and so this concern doesn't exist (or doesn't exist if you trust the transport).

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.

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

#222

Post by logicuce »

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.

Fair point.

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

#223

Post by [deleted] »

tptacek wrote: post #193
adambkaplan wrote: post #187

Earlier quoted context omitted.

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.

I run security teams for startups with my current firm, Latacora, which is me and 5 other veterans of security firms. Our clients engage with financial services and with regulated environments (like HIPAA/HITECH and the standards and practices of large health networks). Before that, I founded a company called Matasano, which for almost 10 years was one of the largest software security firms in North America. Unlike a…

[deleted]

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

#224

Post by stephenr »

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?

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

#225

Post by Blazespinnaker »

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…

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

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

#226

Post by stephenr »

u801e wrote: post #191
acdha wrote: post #103

Earlier quoted context omitted.

> With client certificates you install certificate once and (given enough support from web developers) forget about passwords "forever". The problem is that this isn't really true: it's more like this: 1. You go through a tedious and convoluted process to get the certificate, which requires using a largely-ignored browser feature which is now deprecated: ( https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ke.…

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

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

#227

Post by vfulco »

From the cheap seats (as I am a liberal arts major) and currently an entrepreneur trying to launch some microservices for my resume editing and other professional services business using R-project and the plumbing api creator package. What about a fairly lengthy random password provided to clients (human beings) they input into the intake form using Typeform, then the underlying code checks for it in the "authorized" file and removes it after 1 time use? The form feeds the api inputs directly.

TIA.

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

#228

Post by Squithrilve »

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…

Every time I read a API that uses signed/authenticated requests (AWS, Let's Encrypt ACME) I wonder exactly the same thing - why is this needed in the first place? If TLS guarantees lack of replays it seems to me like signed requests just protect their own complex infrastructure from reusing the same request twice...

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

#229

Post by Promarged »

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.

I'm not from Amazon but I'd guess they want to protect the request from being replayed inside their own systems.

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

#230

Post by Squithrilve »

6ue7nNMEEbHcM wrote: post #64

Hi, can someone explain me why SSL client authentication is not widely used? You can use the same protocol you use to authenticate hosts to authenticate users, yet no one seem to do that nowadays. I'm not professional web developer so maybe answer to this question is obvious (but I just don't know it).

Poor support of SSL certificates in browsers is commonly attributed to bad UX but the real reason is that they are credentials that can be re-used by multiple services to track you as an individual. Newer standards like U2F completely compartmentalizes origins so that if you register to service X a different service Y will not know who you are.

SSL certificates also doesn't work in HTTP/2 (because of multiplexing multiple requests).

Benefits include storing private key in a hardware tokens, most OSes support them out of the box. You can just plug your token into USB port, visit site that requests a client certificate, enter PIN and be done (e.g. Yubico PIV applet).

HTML also has/had element that would generate private key in a browser, send the public key to be signed to a webpage essentially creating private/public key credentials but that is being removed from browsers.

For inter-service communication I'd definitely consider using SSL client certificates pinning private keys e.g. to TPM but regular users can't be bothered with it.

If you're interested check out Token Binding that makes tokens (cookies, etc.) bound to TLS connections essentially providing security of client certificates for tokens.

Post reply on HN