Can GnuPG be used with a login system?

Question

I was thinking about creating a proof of concept for the following type of website login system.

Instead of passwords being used, on account creation, a public GnuPG key is uploaded to the server, and that serves as the main form of authentication for a users account. To login, the user would give their username. The login app would get the usernames public key, encrypt a random string with their public key, and the user would have to decrypt that downloaded file, and used the decrypted string as the password.

Does there seem to be any flaws in that system? If the user is able to keep their key secret, I don't see why this type of system wouldn't be feasible.

What do you think?

Answer 1

Can GnuPG be used with a login system?

Yes, there are ways you could do that.

But…

While possible, there are two things that immediately pop into my mind:

1. Public key crypto can be somewhat slow, which might or might not cause resource problems on the clients as well as on your server… depending on the number of users that simultaneously try to login, and how exactly you implement things.
2. Expecting users to decrypt a file to get a temporary login password (as you describe) doesn't seem to be very handy from a usability and UX point of view. Yet, that doesn't mean your idea would not be possible as a "proof of concept"… I just don't think it would be very practical. After all, you're putting a lot of burden on the client here (additional work of decryption, introducing additional steps since client first needs to download the encrypted password file, etc.) which – if you think about your idea twice – is rather unneccesary if you use a secured (read: HTTPS) connection. And you need to, otherwise, your Public-Key-Login-Adventure might be an easy target for MITM attacks. Sure, you can try to work around those too… but why invent a square wheel (your idea) if there is a good, secure, and working round wheel (SSL/TLS) available already.

I'ld say this boils down to a case of "just because you could, doesn't mean you should".

Answer 2

This is basically what is done with SSH login keys, except they don't require the user to manually decrypt the inbound data. Likewise in your application, just have it point to the private key, and have the option for manual decryption if one does not want to give the app access to their private key, and you are set.

Using keys like this is actually more secure against outside brute force attacks than password hashes, since when using a proper password hash the attacker brutes the password. Note that the SSH login key is subject to vulnerability if another user is logged into the same system, but the same is true for passwords when its saved in the web browser.