3
$\begingroup$

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?

$\endgroup$
  • $\begingroup$ If you're just looking for a secure remote login system you may want to have a look at the SRP algorithm / protocol (I guess it's something in between :) ). $\endgroup$ – Maarten Bodewes Jul 9 '17 at 10:03
2
$\begingroup$

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".

$\endgroup$
  • $\begingroup$ RSA ENcryption can be quite fast. I'd myself worry about the client more than the server: how to connect the private key to the session, for instance. RSA decryption using Java Script may be exceedingly slow. $\endgroup$ – Maarten Bodewes Jul 9 '17 at 10:05
2
$\begingroup$

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.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.