Secure website-authentication using GPG keys

This is an old post I wrote, which was originally posted on neverfear.org on Sun, 9th Dec 2007 23:00:43. Archived here for posterity.

There are 10 comments on this post.

Overview

Currently, most websites log you in the same way: You enter a username and password, the web-server hashes the password (generally via MD5(), or SHA1()). This hash is then compared to the one stored in a database - if it matches, the user knows the original password, so it logs them in.

This method has numerous problems, such as the password being sent unencrypted to the web-server, and the fact many users reuse passwords, if an intruder works out a users password (though any means), there is a good chance they can log into the same users email account, online banking etc etc..

The whole username/password login method has many flaws, most are down to the fact most people struggle to remember a single 5-6 character password, let alone multiple random messy looking passwords such as "Xm2K?pdT&av", as most "good password guides" suggest.

GPG ("GnuPG"/"GNU Privacy Guard") is a free/open-source replacement for PGP (archive.org link) . I won't go into what GPG is, since I guess quite a lot of the people reading this already know, however if you do not, it is primarily used to sign or encrypt email messages - see the Wikipedia page on it (archive.org link)

Back to website-logins. When you enter a username/password into a website, you are basically trying to prove you are you, but with this method, you are only really proving you know the password - something that is surprisingly easy to capture. GPG is far more secure than a simple password, as it uses a public/private key system - anything signed/encrypted by GPG is effectively using a 4096 character password, and you never send your password anywhere; only you can sign a message with your private key, and others verify it using your public key.

Since GPG is basically used as an identity-verification tool, it seems logical to use this to prove who you are. You give the site your public key, it gives you a random string, you sign it with your private key and it knows what key-owner signed the string. No private data (private key or password) is ever transmitted.

Steps

• Site displays random string/paragraph.
• The user copies this string, using: gpg --sign -armour
• The user copies the output into a textarea on the site, and submits it.
• The site runs gpg --verify on the returned textarea
• If it validates, who ever's key it is ("gpg: Good signature from "Bob Smith (Bob) bob@someFakeSite.com (archive.org link) ") is logged into the site.

Problems

• Replay attacks. If the signed string is the same, you could simply send the same signed message again. This is easily fixed by using a temporary, random string, like the captcha-systems use. As long as the string is only valid for a short amount of time, these attacks are no longer possible. Even if the string is predictable, the user cannot generate a new signed message.
• Session-stealing. If the login in "remembered" by the site, using cookies, however you login does not prevent "cookie stealing", so this would be up to the specific site to prevent (Binding the cookie to a specific IP address for example?)
• Mapping GPG-key in GPG keychain to user-account. Not all that complicated, but it's far more complex than simple MD5($password)..
• Getting users GPG public key. Again, not all that complicated - when the user signs up, they fill in a textarea with their public "ASCII-armored" GPG key.
• One of the bigger problem with this I can foresee is userA putting userB's public key in their own account - this would lead to duplicate keys. Although this would effectively lock userA from his own account, allowing userB to possibly log in as him. The email/name/nickname could be used to verify who the key belongs to, but since a user may sign up to a site using a nickname or alias, not their real name, it's may be impossible for the computer to validate this.
• Portability. It's rather difficult to memorise GPG keys, so the user would be required to carry their keys around if they wish to login from other computers (Schools/libraries/other peoples houses/etc/etc). Although, if SSH is accessible, it's simple to use GPG on a remote machine (assuming you trust the machine to not have keystroke-loggers and such, but those problems apply even more so to regular password auth)

Implementation

This is just a concept currently, I haven't tried to implement this yet. The biggest hurdle currently seems like the connection between the webpage and the GPG system.

The most obvious method would be system() calls to the "gpg" binary. This would be cross-platform and fairly easy to implement, but does raise possible command-injection security problems (admittedly these are easy to prevent with input-sanitisation).

There is a GPG extension for PHP (called GPGext), which would certainly make implementing this far easier, but I always preferred native implementations over extensions that require shared libraries in system folders and such. There are similar libraries for various other languages commonly used for server-side programming (Perl/Python/Ruby/etc)

Alternatives

• OpenID (archive.org link)
  • The closest implemented system I am aware of. It's a "decentralised identity system": It allows you to login to any compatible websites simply by entering an "openID endpoint", basically a URL. It's an interesting system, but it's uptake is very slow, and very few websites have an OpenID login option (See the "Where?" (archive.org link) section on the OpenID.net site)

Conclusion

For most sites, this is fairly overkill in terms of security. For "normal" users it's complicated - setting up GPG alone is beyond a lot of people. But, for certain sites (very technically-oriented sites, like NEVERFEAR), where the users are very technically competent, it really becomes a matter of do the users really care enough about their account's security?

Taking NEVERFEAR as an example, I'd imagine, no. The most a malicious user could achieve would be to make or delete that users posts - something easily undone.

There are two important things when it comes to security systems. First and most obvious, is the actual security improvements, and second is connivence. If the security improvements aren't worth the reduced convenience, it's not going to be popular.

The security improvements are fairly substantial. SSL for a site like NEVERFEAR isn't practical. With the GPG login system, SSL would be more or less unnecessary, since no passwords are ever sent, and the "signed-message" used to login is invalid once the user has used it once.

The problem is, are these security improvements worth the hassle of having to use GPG every time they want to login? With the regular username/password system, browsers have built-in functionality to remember passwords, so all they have to do is click "Login". Compare this to having to copy a string, run the GPG command, enter their GPG pass-phrase, paste the string, copy the output to the page and click "Login"..

That's not to say if the method would ever popularised, it couldn't be made much easier (By having it built into the browser, or with browser-extensions) - but the possibility of that happening is nearly zero, so the benefit of only having the GPG password to remember is no longer valid (as you still need to remember passwords for every other site on the internet..)

I may make a test site, to prove the concept, but I don't see it progressing much more than that.

One last thing - this GPG auth system is applicable to any system that can deal with text being sent/receive. IRC for example. This may be a more plausible testing ground for such a concept. Many networks use their own NickServ auth systems, and it would be fairly simple to add a GPG-Auth command to the services, without disruption regular /msg NickServ identify commands. OperServ would benefit most greatly from this, as it would help secure the fairly powerful oper logins, and opers are always going to be very technically competent. The fact IRC clients are also very easily scriptable helps too.