Some time ago I thought of an authentication scheme for website registration (or anything else) using asymmetric encryption, which went something like this (Alice is the user, Bob is the server):

  1. Alice signs up for an account and gives her public key to Bob.
  2. Bob stores it.
  3. When Alice wants to log on to Bob’s site, Bob sends her a random number of sufficient length, Alice signs it, Bob verifies that it is indeed she, and he logs her on.

At the time I hadn’t seen this protocol anywhere, and I was wondering why noone used it since it has so many advantages. I recently read Bruce Schneier’s Applied Cryptography (an excellent book) and (not very surprisingly) saw my scheme in it. As Schneier noted, “It is foolish to encrypt arbitrary strings—not only those sent by untrusted third parties, but under any circumstances at all.” Indeed, someone might mount a chosen-plaintext attack or, more simply, make you sign “I wear women’s underwear”. That would not be very flattering.

It is possible for Alice to sign the hash of the string Bob sent her, but I will forgo this completely and propose a new protocol (until someone points out that this, too, is useless):

  1. Alice signs up for an account and gives her public key to Bob, who stores it.
  2. When Alice wants to log on to Bob’s site (or otherwise prove her identity), she tells Bob her name and Bob sends her a random number and signed by him and encrypted with Alice’s public key (E~A~(S~B~(N))).
  3. Alice decrypts it, verifies Bob’s signature and sends the number back to Bob.
  4. Bob verifies that the number is the one he sent Alice and lets her in.

This has the downside of requiring an extra step, i.e. that Alice tells Bob her name so he can encrypt the random number to her public key, but on the other hand, Bob can send her anything he wants and he will be sure that only Alice will read it. He can, for example, send her a random session key. Alice doesn’t have to send the key back, but instead she can use it to establish an encrypted connection with Bob using symmetric encryption.

To prevent man-in-the-middle attacks, Bob has signed his key. Alice will see who sent her the data and can choose to trust him or not. If, additionally, Bob’s key is signed by a central authority Alice trusts(SSL-style), Alice doesn’t have to know (or trust) Bob beforehand, she can now do business with him.

This method has various advantages over traditional password authentication schemes:

  • Alice’s password (or private key) is never stored on Bob’s computer. Bob can never authenticate himself as Alice to other people, even if Alice trusts him. Consider this scenario, Alice has an account on Mallory’s site, and she tries to authenticate. At that moment, Mallory contacts Carol’s site, on which Alice also has an account, and tells her Alice’s name. Carol sends Mallory a random number, and Mallory sends it to Alice. When Alice decrypts the message she will see that the signature is not Mallory’s, but Carol’s, and Mallory’s plan is foiled.
  • Alice no longer has to use (or remember) different passwords for each site, she just uses her public key on each one.
  • Brute force cracking is not applicable to this scheme, unlike when using passwords (and short ones, at that).
  • This can be done automatically (through the user’s browser), so the user never notices the authentication process.
  • This can be done with freely available tools (i.e. GPG)

This method also has some disadvantages:

  • If Alice’s private key is compromised, anyone could claim they are Alice. This is the same as with passwords, but much harder to do in practice.
  • If the user’s browser doesn’t support this, the user has to copy/paste the message to another program and back to the browser, making it much harder for the user to adopt this.
  • It requires an extra step (the user sending the username to the server), i.e. one extra page load.

If you notice any advantages/disadvantages I haven’t caught, feel free to comment. I do believe that this is far superior to the traditional password authentication protocol, if not because of its security, at least because of its convenience. Passwords are a hassle and a security risk.