I see that password based authentication is out of favor today, and Internet is moving toward RSA keys-based authentication.

Coming from that fact, I am wondering if there would be a real benefit to widespread its use for regular websites? I see the usage as follows, and it's exactly the same as you would normally expect:

  1. When signing-up onto a web-resource, User's browser generates the public-private pair, as well as scope she/he is willing to give to this key (not root/admin by default)
  2. Browser encrypts the private key, and User communicates the public key to the web-resource

For all other requests, User is automatically logged in thanks to the private key stored in browser. Note that the user could (should) also sign-in (sign-up) with a federated profile, and only this method would provide the root/admin-like scope. This root user will be able to revoke key-pairs if they are compromised.

Wouldn't it resolve the 'N passwords for N websites' problem which everyone is facing, since only 1 admin password exists (which is not known by the web-resource)?

Yes, I kinda feel like reinvening the wheel, and if this is so obvious, why nobody seems to use it?


2 Answers 2


Your intuition is correct! There are two protocols that I'm aware of which use public-key crypto as a way to log into websites. (neither are actually SSH though)

TLS client certificates

We are all familiar with TLS (that green lock icon in your browser bar). Typically it serves two purposes:

  1. Encrypt the traffic between you and the server.
  2. Prove that the server is who they say they are.

By clicking on the green lock, you can see the server certificate for the site you are currently connected too.

It turns out that TLS also supports a mode called "mutual authentication" where, in addition to the server providing a certificate to prove its identity, you (the user) do too.

Diagram of the TLS handshake with a client certificate

To do this, you need to get a personal certificate (usually issued by the website in question) and import both the cert and the matching private key into your browser (usually via a .p12 file). When connecting to a site the requires it, you'll see a popup like this:

Safari popup for TLS client auth

FIDO Universal 2nd Factor (U2F) USB sticks (think Yubikey)

This is the technology where you plug a USB crypto device into your computer and a website communicates with the device to authenticate you. This has pros and cons compared to client certificates, but one big pro is that the private key is stored in cryptographic hardware, so even someone with admin access to your laptop can't make a copy of your key.

Picture of a Yubikey plugged into a laptop

From wikipedia:

Universal 2nd Factor (U2F) is an open authentication standard that strengthens and simplifies two-factor authentication (2FA) using specialized USB or NFC devices based on similar security technology found in smart cards.

U2F Security Keys are supported by Google Chrome since version 38 and Opera since version 40. U2F security keys can be used as an additional method of two-step verification on online services that support the U2F protocol, including Google, Dropbox, GitHub, GitLab, Bitbucket, Nextcloud, Facebook and others.

  • In addition to U2F there is webauthn now, which is very similar but also allows software authenticators, meaning your browser can generate and store the key in a built in authenticator directly instead of requiring a hardware token. It looks like Dropbox already supports it, and it's gotten some media attention, so more will probably add support in the future. Aug 16, 2018 at 14:23

Does something close to ssh public keys exists for HTTP? Yes, is is called client certificates, and it is used when strong authentication is really required. In European countries, a smart card certificate should give the same legal value as a signed paper would, provided it can be established that the private key has always be under exclusive control of his owner, and that the certificate was delivered to the proper person

Why is it not widely used? Close to a chicken and egg problem. As few clients have certificates, is is no use implementing it in site servers and web applications. And as few servers accept it, it is no use for a client to buy a certificate. And the implementation is not that trivial, because the authentication occurs in the early steps of the SSL protocol, before any request has ever reached the actual server, not speaking of the possible nightmares for proxy systems and CDNs.

Things could easily change, if the US government or the European countries decided that every citizen should have a certificate on its ID card. Then the market for server side implementation would dramatically grow, but until that...

In addition, 2FA authentication is far simpler than certificates (from a server perspective) and is generally considered as secure enough for standard security needs. So still one reason to not widely adopt client certificates.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .