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

> 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 device you plan to use?

> Every time you visit a site or send an email, you now have to select which key you want to use.

Could the browser remember which website the client certificate was used for? If so, then the user won't have to make the selection more than once.

> Every year, repeat the process starting at step 1.

Outside of a device getting compromised, is there a good reason for updating certificates more often than once every 5 years?

> It'd be really nice to have a LetsEncrypt-style effort to remove the warts from this process so it's approachable for normal people without a heavy support pool.

I'm still doing more research on this, but what did the HTML element lack that the process used by Let's Encrypt provide?

> This is another area where I wish Mozilla hadn't prematurely killed Persona as it'd be really nice if there was a service which would allow you to associate different client certificates with a single user identity so private keys never needed to leave the device

Shouldn't the private key be something that's associated with the browser? That is, when you install the browser, a private key is generated and used for all certificate signing requests. I think the process could be extended to add additional browser instances for a given account on a website. For example, you could take the CSR from the other device and use your first device to send it to the server, get the certficate and then copy it back to your other device.

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 at Latacora, where our clients are all startups, Matasano's clients ran the gamut from startups to big tech firms to international banks, trading exchanges, utilities, and pharmas.

With the exception of the military, which I on principle won't work with, there's probably no regulatory or audit regime I haven't had experience with.

I say all this as lead-up to a simple assertion: I have never once seen an auditor push back on bearer-token API access. It's the global standard for this problem. If you knew how, for instance, clearing and settlement worked for major exchanges, you'd laugh at the idea that 128 bit random tokens would trip an audit flag.

tl;dr: No.

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 no point in limiting the lifetime of the certificate, unless you send a person to do that verification manually.

It's very possible I completely misunderstood your suggestion, however in case I didn't.

If you're storing the key on the client (cookie or w/e) and in the database and solely using it to authenticate, aren't you going to run into timing attacks if you're using it for retrieval?

What I typically do is also store a unique identifier like email for the lookup and then use a random key for comparison / validation.

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

The public implementations are generally trying to verify current ownership of the specified email address. That's part of why I wish this could be linked to a third-party which already does that so users don't have to repeat the process as often.

> > 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 device you plan to use?

It would, but currently you can't do this if you use Google Chrome or Microsoft Edge. Again, remember that I'm talking about the practical impediments doing this now rather than any sort of conceptual problem: if the industry cared this could improve a lot very quickly.

>> Every year, repeat the process starting at step 1.

> Outside of a device getting compromised, is there a good reason for updating certificates more often than once every 5 years?

The general idea is that it protects against unknown, non-permanent mistakes but I think the main point here is that key rotation should be automated so it can happen simply since it reduces the window of problems for any mistakes considerably. I'd expect a modern implementation to have a tiered approach where e.g. keys generated on a secure enclave, token, etc. are trusted longer than ones where user error makes it possible to get access to the private key.

> > It'd be really nice to have a LetsEncrypt-style effort to remove the warts from this process so it's approachable for normal people without a heavy support pool.

> I'm still doing more research on this, but what did the HTML element lack that the process used by Let's Encrypt provide?

It's been awhile since I looked at the discussions but I believe it was basically another case of an early feature chucked in in the 90s having a bunch of dubious design decisions which people didn't want to support for since it was rarely used. I'd be happy with it going away or substantially changing if there was a modern JavaScript API.

> > This is another area where I wish Mozilla hadn't prematurely killed Persona as it'd be really nice if there was a service which would allow you to associate different client certificates with a single user identity so private keys never needed to leave the device

> Shouldn't the private key be something that's associated with the browser? That is, when you install the browser, a private key is generated and used for all certificate signing requests.

I was referring to the two related concepts here: I like the model where each browser manages a private key (preferably stored in secure hardware) but you also need to handle the question which keys are allowed to sign responses for a specific person. Consider e.g. all of the sites which trust Google or Facebook to authenticate users and imagine what it'd be like if that could be extended so you could ask that trusted third-party which keys correspond to a verified email address. Having it be something which is commonly used would also be a great place for rotation if there was a seamless way to repeat the signing process every n days rather than a user having to do it the first time they access a site a year after the last time they renewed, when they may have forgotten a lot of the steps.

That last point underscores how much of this has nothing to do with PKI and everything to do with horrible UI: the failure mode for not having a valid certificate is generally horrible — looping selection dialogs, low-level TLS failure messages with no indication of what you can do to fix things, etc.