Is PGP for user authentication a good idea?

Question

I am building a web site that provides user login. For that, I am currently researching good strategies for dealing with authentication.

How I'm doing it right now

My current concept is modeled after what seems to be the common consensus right now. Passwords are salted with 64 bytes from /dev/urandom and then hashed with 100 rounds of SHA-512. After every round, the original password is concatenated to the result and then fed into the next round. When a user wants to log in, they send their credentials to the server, where the described procedure is then repeated (using the same salt, obviously) and compared to the hash in the database.

This strategy seems adequately secure to me (please correct me if I'm wrong, it is basically just the result of reading a lot of online guides and watching YouTube videos). However, I think it has a major flaw, which is the client having to send the password in plain text to the server. Yes, I naturally use HTTPS, but still, if the connection was somehow compromised for whatever reason, so is the password.

The alternative concept

So I thought of an entirely different approach: using PGP keys. When a user signs up, they generate a PGP key pair, encrypt the private key using a password of their choice and send it to the server. When they want to log in again, the server generates a string of random characters and encrypts it using the public key. The encrypted random string and key pair are then sent to the client, who will need to decrypt it again to prove they have the private key's password.

This method would prevent the password from ever being transmitted over the network and even allow for cool stuff like end-to-end encrypted chat between users. The only drawback I could find is the server having to give out encrypted private keys to basically anyone who requests them, making brute-force attacks way easier. I could mitigate that by running a computationally expensive key expansion algorithm on the client side and use the result of that for encrypting the private key.

But I still don't really trust the whole thing, and so I would love to hear your feedback on whether this is a good idea or if I should just stick with how I'm doing it right now.

EDIT:

Based on some of the answers, I think my question is a little misleading. My requirement is that the only thing users ever need to provide for successful authentication is their username/password and nothing else, regardless of what device they are using or whether they were logged in on that device before.

Answer 1

You should never try to secure a "real" web application with a scheme that you invented on your own. As such we shouldn't discuss practicalities on how you would actually implement or use such a method.

Will it work?

Your scheme does not send a password over the wire. What immediately jumps out is that you send the private key to the server, which never does anything with it, for no reason. Yes, it is supposedly still protected by the password, but why?

As others have pointed out, the private key is supposed to remain with the owner.

Even if you consider the private key's password encryption, there is the following problems (at least):

• Handing out the private key in your scheme is essentially the same as making the password hash public: Anyone can now do an offline dictionary attack against the key's password; and nobody can stop that.
• Even worse, they can get the key for a given login, meaning that they can check if a user exists and then attack the password for the user name.

With a small modification, your scheme would be a very simple form of public key authentication:

• The client creates a key pair, and sends the public key to the server
• To log in, the server sends out a random string.
• The client signs the string and sends it back to the server.
• The server verifies the signature to make sure the client has the private key

Something like this is actually already possible in https using client certificates. The same thing is used for ssh.

The Challenge-Response mechanism mentioned by ThoriumBR is another way of authenticating, although the implementation described there assumes that the server stores the password in cleartext -- which is much more dangerous than sending it over an encrypted connection.

Will it be "better"?

No. The scenario that you want to defend against is supposedly that someone gets inside the encrypted https connection. If you assume that this is the case, they would not only be able to read the password but also steal your session cookie and all the data that is shown in your session. In that case, the attacker has already won, regardless of whether they read the password or not.

You could of course roll your own encryption and authentication, but the question is why you'd think that this will be better than the https connection?

The realistic scenario isn't that someone breaks the https connection, it is that someone breaks into the server's database and tries to "recover" the passwords in an offline attack. This is what most authentication schemes try to defend against.

The danger with passwords is not that they are interceptable, but that they can be guessed.

What should you do in real life?

For a "real" web application, use an established framework and a well-known authentication library. Don't write it yourself, because it is easy to get wrong and very hard to get right.

Don't use SHA-anything for hashing the passwords, use a dedicated password-hashing function such as bcrypt or PBKDF2 to make attacks more difficult (see this answer also). You can also use or add some TOTP mechanism for your app, which is better than just a password.

Addendum

You added the following after I wrote my answer:

My requirement is that the only thing users ever need to provide for successful authentication is their username/password and nothing else, regardless of what device they are using or whether they were logged in on that device before.

This explains why you want to send the private key back to the server, although it doesn't change the reason why it is a bad idea.

You could still use a challenge-response mechanism, like ThoriumBR suggested. There are even advanced challenge-repsonse mechanisms such as SRP which use clever math to avoid storing the password on the server.

However, all those mechanisms, and also client-side hashing (see this answer), have one thing in common:

They need to execute code on the client side.

In a web app, this can only be Javascript sent by the server. Implementing the client side is not the problem (there is even a OpenPGP library), but since you worry about the security of the https connection, you have another problem:

Any man in the middle could therefore simply inject malicious client side code to steal the password, rendering your whole clever mechanism obsolete.

Answer 2

As the others said, private keys aren't shared. full stop. Otherwise, they are called public keys.

But: Cryptographically signing on is pretty standard. HTTPS supports that:

Authentication using HTTPS client certificates; and all modern browsers have the built-in means to generate the necessary keys when asked to.

Your problem has already been solved; the user generates a key pair, gives you its public key, keeps the private key, and upon connection, the server asks the client to prove they own the private key (essentially, by letting them sign something).

Done!

Other cryptographically established methods include at least one method I'm aware of:

Single-sign on via Kerberos ticket – this is extremely wide-spread in intranets that use Active Directory. Again, modern browsers (at least Edge, Internet Explorer, and Firefox) support this out of the box – on both windows and Linux (haven't tried on OS X or FreeBSD)

Answer 3

While I like the idea of PGP for login, this is not the way it's supposed to work. The private key should remain on the client side, always, and never be shared with anyone. This setup encourages bad practices and provide incorrect education about PGP.

What you could do is, have users upload their public key to the server, and then you present them a challenge (basically, an encrypted string) upon login, that requires the private key and of course the associated passphrase..

The problem is that few people know PGP or have a serious inclination to use it. If you can do it, go for it.

Answer 4

As Anonymous said, the private key must always be private. Sending the private key to any entity negates any security provided by your login.

Basically, what you are designing is called Challenge Response Authentication, and can be done even without a keypair:

• One party (the server) generates a random token and sends it to the other

• The other (the client) concatenates his own password with the token, hashes it, and sends back

• The server knows both the token and the password, concatenate those values, hash, and compare with what the client sent

If you want to use a keypair, you can use the keypair to sign:

1. Generate a random value R1 and send to the user

2. User receives R1, and signs it using its private key

3. Server checks the signature against user's public key

This is technically easy to do, but I doubt most users will have the necessary know-how to generate a keypair, and use the keypair to sign things.

Answer 5

An alternative approach that implements the same concepts is SRP. Ignoring the math in the protocol, the idea is that when a user signs up the client generates a password verifier which is sufficient to verify credentials, but not to act as them and sends it to the server to store.

At login time the parties then exchange messages based on random values that eventually leads to the server using the stored verifier to ensure that the client has the correct password. The messages that the client send to the server are one-way derived from the password and the random value so the password is never sent on the wire. The random message from the server ensures that the messages from the client are valid only for the current login attempt (prevents MITM from being able to replay login attempts if HTTPS fails).

While the protocol is daunting to implement, there are out of the box implementations out there, e.g. AWS Cognito and its client JS SDK, so it is practical to implement in any web app.

Answer 6

While the scheme described in the question has a significant problem in enabling offline bruteforce attacks against the password, it is possible to redesign it without this vulnerability.

For example, one can generate private key directly from password. That avoids the need of storing the private keys at all - basically the password becomes the private key.

However in a practical web application implementation, you would have to do the cryptography in client-side javascript. And if HTTPS as transport is broken, it is quite likely also to enable compromising that piece of javascript, giving out the password in plaintext.

Such a scheme correctly implemented would be slightly more secure than current standard practice of plaintext over https + hashing on the server side. But without extensive review, it is easy to make subtle but critical mistakes in cryptography code, and effort would be better spent securing other parts of the application.

Answer 7

This already exists.

OpenPGP has "authentication" as a possible key usage, and a PGP key can be used to authenticate an SSH session if gpg-agent is used in ssh-agent mode. I use that daily as a single-sign-on solution with a smartcard, but there is no reason why this wouldn't work with a regular key.

There are also various plugins that allow signing messages during a TLS handshake using gpg-agent, allowing users to use their PGP key for SSL client certificate authentication.

As the key never leaves the user's device, it isn't even necessary to generate a new key, users can just enroll with their existing key.

You need enough of a PKI infrastructure on the server side to decide which keys are valid for which users. Most services (e.g. gitlab, github and launchpad) allow you to upload your public key into a form in the user profile editor.

Answer 8

Can you?

Yes

Should you?

No

Why not?

Don't reinvent the wheel. Unless it's broken... which it is not.

There are plenty of tried-and-true authentication methods that don't involve the transmission of private keys, which should ALWAYS stay with the user. I would recommend against using PGP call-response as outlined by @ThoriumBR as the main authentication method (though it has uses which I describe later).

What you should do

Stick to dedicated libraries and frameworks for authentication such as the password-hashing functions (bcrypt, PBKDF2, TOTP) that @averell posted in their answer. If throughout the user-experience of your website/app PGP key encryption is required, only use it when necessary.

For example, messaging between users can easily be achieved without storing any private keys on the server by letting (or requiring) users upload their public PGP key to the site, allowing others to sign with that key. The user can decrypt using the private key stored on their device. It is a trivial matter to copy your private keys to whatever device you'll be using them on.

Thanks to OpenPGP many libraries have been created to facilitate what you're trying to do including the OpenPGP.js JavaScript library.

PGP for 2FA

Since PGP is an otherwise integral part of your application anyway, you can add a layer of security to logins by using PGP as 2FA for the account. You can also use the challenge-response

1. Client signs in with trusted framework for authentication.
2. Client adds their public PGP key to their account.
3. Server authentication workflow contains the public PGP key as a variable of whatever framework you use.
4. Server generates a 2FA string (short numerical, long message, the content is not important) which it then signs with the public PGP key associated with the user sending the authentication request.
5. User decrypts the message client-side with their private PGP key, obtaining the encrypted message necessary to fill in the 2FA form.

Note that under no circumstance does the server know the private key. This is hugely important for security. The private key stays with the client, always. As for the public key, add it anywhere that's necessary, there's no security risk to storing the public key on the server. One could argue that fingerprinting a user between applications/sites using their public key is at the very least a privacy risk, one which can be avoided by using different keys for different apps. This is an edge case though and is not problematic unless a user is using the same public key on a site/app they'd rather not be associated with publicly.