13

I've been reading how the SSH public/private key works and realized how handy they are (taking the secure out of the equation). And started to wonder why websites do not implement the same thing?

Let me explain why I am interested in this: When you register to a website, you don't know what happens with your password, it may very well be stored as plain text in a DB. Any admin can see your username/password combination (plus e-mail or any other information) and just try them in other services et voilà, clean access to your e-mail, Facebook, Stackoverflow, etc. The password, even if not stored, can be sent non-encrypted over the wire to the server and caugtht by a man in the middle. All this is easily solved using an approach like the one implemented by SSH, for instance (or having a different, password for every service, but my memory has severe limitations).

Therefore, how can I implement such a strategy for logging into a website? I couldn't find no browser extensions nor instructions on how to do it. For the time being, my objective is to have a website to serve ~10 people (colleagues, all in the same network) and whom I can convince to do some extra work (like installing an extension or generating the key pair).

Community
  • 1
Aquiles Carattino
  • 431
  • 4
  • 8
  • Have you thought about using [client certificates](https://en.wikipedia.org/wiki/Client_certificate)? This is supported natively by all major browsers. – WhiteWinterWolf Sep 14 '15 at 14:25
  • 1
    Re your rationale: admins on a website, mailserver, etc. usually have access to your data *without* using your id and password. In fact your password is almost always better secured than your "ordinary" data. (Password breaches are in the news because they are more serious, not because they are more common.) And any site today that accepts a password on unencrypted HTTP is loudly criticized from all directions. But those don't affect the answer to your question as asked. – dave_thompson_085 Sep 14 '15 at 19:39
  • My rationale is that by using private/public keys, no matter what level of breach a site faces, I know all my other sites are secured. There are PLENTY of sites that don't encrypt users' passwords (in any case, how can I, end user, know if they do?) How many users out there use the same password for all (or many) websites? It just strikes me the fact that we still use username and password to identify. – Aquiles Carattino Sep 15 '15 at 10:02

2 Answers2

6

Certificates can be used in that purpose. The general use of certificates is for TLS/SSL connections, but client certificates can be issued to handle two-way authentication. Certificates are basically public keys with an added layer of "trust networking".

If you want to do this properly, you should implement a PKI to handle certificate request, creation and revocation. But alternatively, you could just ask a user to upload any public key certificate they want to use.

Many recent browsers are also able to generate certificate request (private/public key) on the fly when connected to a website. Then the certificate are stored in the browser profile.

M'vy
  • 13,053
  • 3
  • 48
  • 69
  • "Client certificate" was the keyword I was looking for but didn't succeed. Thanks! Still wonder why is it not implemented in massive websites such as Facebook or Google... Or is it implemented and I just didn't realize? – Aquiles Carattino Sep 14 '15 at 14:41
  • 1
    Even though client certs are supported by most browsers, managing the certificates and their private keys is a complex and error-prone process @AquilesCarattino. In the past they've been used as a second factor of authentication though mobile apps seem to have largely replaced that. – Neil Smithline Sep 14 '15 at 14:46
  • 2
    @AquilesCarattino - client certificates tend to be installed on a single computer; it's not particularly easy to move them around. That's why you rarely see them used. There are some attempts (Mozilla Persona, Windows Hello) to implement a more modern approach. – paj28 Sep 14 '15 at 14:47
  • 1
    Client certificate *and privatekey* can also be stored on a **smartcard** and *used* by the browser (or other software) usually controlled by a PIN. This is used on a large scale by the US government first with [CAC](https://en.wikipedia.org/wiki/Common_Access_Card) for military and now [PIV](https://en.wikipedia.org/wiki/FIPS_201) for civilian. This not only makes it easy for the user to move from one PC to another, it can't easily be *left* active in a PC when the user goes somewhere else because the same card will often be needed for physical access controls like doors. – dave_thompson_085 Sep 14 '15 at 19:33
  • Thanks for the comments. I'm still puzzled by how easy it is to implement in SSH and how "complicated" it is for websites (or at least, how little interest they've shown.) Even big players like Google, with their own browser... – Aquiles Carattino Sep 15 '15 at 09:53
  • @AquilesCarattino it is not complicated to implement. It is complicated to manage. Google do not want people to request daily recovery of client certificates (or other private key). Passwords are something one know, public key something one has. It is easier to manage something people have in mind rather that an object they are suppose to carry with them. – M'vy Sep 15 '15 at 09:58
  • 1
    It's only a matter of giving the choice. Like the 2-step auth; it also implies carrying a device around. – Aquiles Carattino Sep 15 '15 at 10:08
5

For people looking at this question now - this may be a better (updated) answer:

https://webauthn.guide/

From the site:

The Web Authentication API (also known as WebAuthn) is a specification written by the W3C and FIDO, with the participation of Google, Mozilla, Microsoft, Yubico, and others. The API allows servers to register and authenticate users using public key cryptography instead of a password.

OmarSpira
  • 51
  • 1
  • 1