Skip to main content
Information Security

Return to Question

clarify the scope
Source Link
Sandtler
Sandtler
  • 329
  • 2
  • 7

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.

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.

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.

Tweeted twitter.com/StackSecurity/status/1215196695270694912
Became Hot Network Question
Source Link
Sandtler
Sandtler
  • 329
  • 2
  • 7

Is PGP for user authentication a good idea?

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.