Hacker News Reader

Comment by remus | Hacker News Reader

Perhaps not about the security of basic auth per se, but if you are using basic auth then setting up mfa is a little more painful as you first need to migrate all your API access to tokens before you can change to mfa. If you're already using tokens then turning on mfa is just flipping a switch and scanning your totp code.

View on HN

What would be nice is if Github would allow one factor of authentication via a client side TLS certificate. That's what's essentially being done when one clones a repo via SSH since Github has a copy of the account holder's SSH public key.

That is, 2FA could be achieved via use of that certificate and a username/password.

Can client side certificates be "locked" in the same way that SSH keys can (where you require a passphrase before it is loaded into the ssh agent)?

When you generate a private key using openssl, it will prompt you for a passphrase.

One issue with HTTPS client cert auth is that it can be non-trivial to support at the application level when you have a multi-tier architecture where TLS termination happens at the edge of your infrastructure.

I wonder if there are any solutions out there that can handle TLS client cert verification along with validating the username/password (which, if provided via HTTP basic auth, would be in the header of the request). That way, the application itself could just concern itself with serving resources, interacting with resources, etc instead of handling authentication or authorization.

The infrastructure edge device could communicate additional information if needed by adding headers to the original HTTP request when it's passed down to the endpoint that actually handles the request.

Reply on news.ycombinator.com