What are potential risks of using PGP for website login?

Question

I'm currently using a login system outlined below:

1. String of 1000 characters is generated on the server each time the website is opened and works for maximum of 5 minutes at which point a new string is generated which will be in memory until next login
2. String is then encrypted using my public key which is stored on the server
3. PGP encrypted message is then shown on the login page
4. After I decrypt PGP message using my private key I copy/paste the decrypted message onto the login page
5. and finally server-side script compares the decrypted message to the string generated in step 1 and after login previously generated string is no longer available

Pros of using this system:

• password is only stored in server memory for a very short time
• PGP message can only be decrypted using my private key(RSA - 4096 bits) AND my passphrase

Cons:

• inconvenience
• my implementation might be flawed

This is for educational purposes only, and won't be used on any production system.

I also uploaded the code to github if anyone wants to see the code

What are some of the potential security risks of using such system?

Answer 1

As this is for education/learning purposes and not a production solution, the normal warnings about not rolling your own security solutions don't apply. However, still strongly recommend looking at some of the established solutions - possibly doing so after attempting your own solution is a good idea as you may understand why things are done a certain way or some of the issues a little more.

Some things to consider with your solution (just off the top of my head, no real deep thought).

• Cut and paste - or using the clipboard generally has a number of security risks. Last time I looked (a while ago now), Metasploit even had a module which you could use to steal the contents of the clipboard.

• Your scheme is really only providing assurances in one direction. There is nothing which would prevent me from getting your public key, spoofing the site and then creating a situation where you think your authenticating against the site, but are actually authenticating against my spoofed site. Similar issues with man in the middle attack - attacker can simply pass through the encrypted string to you, get back your decrypted version and then login to the site. You will need to ensure your connections are over SSL with a valid and verifiable SSL certificate.

• Randomness of 1000 character string. This is often the big weakness. It is vary hard to generate true randomness and is why some programs which require randomness will do things like require you to move the mouse around while the random value is being generated. If your initial 1000 character string is at all predictable, then it would be possible to narrow the search space for decrypted versions of the string and effectively bypass the need to have your private key to decrypt it.

Answer 2

What are you actually trying to achieve? Your system seems to be a two-factor authentication... without the first factor (the password) and the extra complexity of having to use PGP.

In no particular order:

• Do you protect your PGP key with a passphrase? If so, is it cached in memory or do you have to type it every 5 minutes? If not, then you are likely doing something wrong.
• Why 5 minutes? Why is this better than a reasonably implemented session cookie?
• I'd question the usability of your scheme; and with poor usability comes habit and you end up lowering your guard.
• How do you get your public key on the server? If it's an automated mechanism where the server retrieves it from a keyserver given a key ID, then your system is vulnerable to a trivial MitM attack. If you need to transfer your key to the server off-channel then you'd be much better off with a ssh session and port redirection.

Don't get me wrong, the idea sounds enjoyable. I'd love if you could elaborate more, for example what are your goals, how do you measure an improvement in security, etc. etc.

Answer 3

The risk is that security will get in the way of usability to the point where no one will use the system.

Answer 4

You are doing an assymmetric client (a.k.a) user authentication here. Basically this is fine.

But think of this: What you implemented here already exists! It is calles TLS and TLS Client Authentication.

You can configure your webserver to require a client certificate for starting the TLS connection. Each browser support using client certificates. All of them support soft certificates in the browser/certificate store and can protect the private key with a passphrase.

Some browsers also support using smartcards (IE, Firefox via PKCS11), so that the private key is contained on a smartcard and will never leave this.

(Leaving the certificate verification out of scope here) the server does exactly this. The server sends a challenge (a.k.a. you 1000 char random string) to the browser. The browser signs this with your private key, after you provided the Passphrase. The data is sent back to the server and the server can verify the signature with your public key. Done.