How and Where encryption happens in a web application?
up vote
0
down vote
favorite
In a web application, how and where password encryption happens? For example, when a user register onto a web site, whether password set by the user is transmitted as the plain text and encryption is applied on server side and persisted in the database?
On the other hand, when HTTPS is used, data will be encrypted and sent across the wire. In this scenario, do we again apply any encryption algorithms upon incoming data and then persist in the database? Also, please explain which encryption algorithms will be used when data is transmitted over HTTPS.
https password-encryption websecurity
asked Nov 21 at 18:32
Anoop Deshpande
244
add a comment |
up vote
0
down vote
favorite
In a web application, how and where password encryption happens? For example, when a user register onto a web site, whether password set by the user is transmitted as the plain text and encryption is applied on server side and persisted in the database?
On the other hand, when HTTPS is used, data will be encrypted and sent across the wire. In this scenario, do we again apply any encryption algorithms upon incoming data and then persist in the database? Also, please explain which encryption algorithms will be used when data is transmitted over HTTPS.
https password-encryption websecurity
asked Nov 21 at 18:32
Anoop Deshpande
244
2
Passwords are salted and hashed, not encrypted, whether or not you're using HTTPS (you should).
– jonrsharpe
Nov 21 at 18:37
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
In a web application, how and where password encryption happens? For example, when a user register onto a web site, whether password set by the user is transmitted as the plain text and encryption is applied on server side and persisted in the database?
On the other hand, when HTTPS is used, data will be encrypted and sent across the wire. In this scenario, do we again apply any encryption algorithms upon incoming data and then persist in the database? Also, please explain which encryption algorithms will be used when data is transmitted over HTTPS.
https password-encryption websecurity
asked Nov 21 at 18:32
Anoop Deshpande
244
In a web application, how and where password encryption happens? For example, when a user register onto a web site, whether password set by the user is transmitted as the plain text and encryption is applied on server side and persisted in the database?
On the other hand, when HTTPS is used, data will be encrypted and sent across the wire. In this scenario, do we again apply any encryption algorithms upon incoming data and then persist in the database? Also, please explain which encryption algorithms will be used when data is transmitted over HTTPS.
https password-encryption websecurity
https password-encryption websecurity
asked Nov 21 at 18:32
Anoop Deshpande
244
asked Nov 21 at 18:32
Anoop Deshpande
244
asked Nov 21 at 18:32
Anoop Deshpande
244
asked Nov 21 at 18:32
Anoop Deshpande
244
asked Nov 21 at 18:32
Anoop Deshpande
244
244
2
Passwords are salted and hashed, not encrypted, whether or not you're using HTTPS (you should).
– jonrsharpe
Nov 21 at 18:37
add a comment |
2
Passwords are salted and hashed, not encrypted, whether or not you're using HTTPS (you should).
– jonrsharpe
Nov 21 at 18:37
2
2
Passwords are salted and hashed, not encrypted, whether or not you're using HTTPS (you should).
– jonrsharpe
Nov 21 at 18:37
Passwords are salted and hashed, not encrypted, whether or not you're using HTTPS (you should).
– jonrsharpe
Nov 21 at 18:37
add a comment |
2 Answers
2
active
oldest
votes
up vote
1
down vote
HTTPS encrypts the traffic between client and server, this prevents ManInTheMiddle attacks. With HTTPS you can transport the password savely to the server, for you as a developer there is no work involved.
The server will automatically decrypt the password, your application will get the plain text password. It is your job to use a password-hash before storing it to the database. Recommended password-hashes are BCrypt, SCrypt, Argon2 and PBKDF2.
answered Nov 22 at 7:55
martinstoeckli
17.4k43358
add a comment |
up vote
1
down vote
In addition of martinstoeckli answer :
Rule n°2 : Encryption will always be the second choice. If you can use hashing, please do.
HTTPS is asynchronous cryptography (private + public keys). The principle is everything encrypted using public key can only be decrypted using THE private key associated.
In our case, the client will use the public key to encrypt data. And the server will be the only one able to decrypt the data using the private key.
So you will get the plaintext of the data after the private key did its job.
At this point, the best thing to do (to my opinion) is hashing (+ salt + eventually pepper) data and store the hash in database.
When the user will, for example, try to login using his password, the server will once again hash the plaintext password received (using the same salt / pepper obviously) and compare with the one in database.
if the hash is the exact same that the one in database, it means that the password entered by the user is correct.
answered Nov 26 at 14:14
Kianii
1267
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
HTTPS encrypts the traffic between client and server, this prevents ManInTheMiddle attacks. With HTTPS you can transport the password savely to the server, for you as a developer there is no work involved.
The server will automatically decrypt the password, your application will get the plain text password. It is your job to use a password-hash before storing it to the database. Recommended password-hashes are BCrypt, SCrypt, Argon2 and PBKDF2.
answered Nov 22 at 7:55
martinstoeckli
17.4k43358
add a comment |
up vote
1
down vote
HTTPS encrypts the traffic between client and server, this prevents ManInTheMiddle attacks. With HTTPS you can transport the password savely to the server, for you as a developer there is no work involved.
The server will automatically decrypt the password, your application will get the plain text password. It is your job to use a password-hash before storing it to the database. Recommended password-hashes are BCrypt, SCrypt, Argon2 and PBKDF2.
answered Nov 22 at 7:55
martinstoeckli
17.4k43358
add a comment |
up vote
1
down vote
up vote
1
down vote
HTTPS encrypts the traffic between client and server, this prevents ManInTheMiddle attacks. With HTTPS you can transport the password savely to the server, for you as a developer there is no work involved.
The server will automatically decrypt the password, your application will get the plain text password. It is your job to use a password-hash before storing it to the database. Recommended password-hashes are BCrypt, SCrypt, Argon2 and PBKDF2.
answered Nov 22 at 7:55
martinstoeckli
17.4k43358
HTTPS encrypts the traffic between client and server, this prevents ManInTheMiddle attacks. With HTTPS you can transport the password savely to the server, for you as a developer there is no work involved.
The server will automatically decrypt the password, your application will get the plain text password. It is your job to use a password-hash before storing it to the database. Recommended password-hashes are BCrypt, SCrypt, Argon2 and PBKDF2.
answered Nov 22 at 7:55
martinstoeckli
17.4k43358
answered Nov 22 at 7:55
martinstoeckli
17.4k43358
answered Nov 22 at 7:55
martinstoeckli
17.4k43358
answered Nov 22 at 7:55
martinstoeckli
17.4k43358
17.4k43358
add a comment |
add a comment |
up vote
1
down vote
In addition of martinstoeckli answer :
Rule n°2 : Encryption will always be the second choice. If you can use hashing, please do.
HTTPS is asynchronous cryptography (private + public keys). The principle is everything encrypted using public key can only be decrypted using THE private key associated.
In our case, the client will use the public key to encrypt data. And the server will be the only one able to decrypt the data using the private key.
So you will get the plaintext of the data after the private key did its job.
At this point, the best thing to do (to my opinion) is hashing (+ salt + eventually pepper) data and store the hash in database.
When the user will, for example, try to login using his password, the server will once again hash the plaintext password received (using the same salt / pepper obviously) and compare with the one in database.
if the hash is the exact same that the one in database, it means that the password entered by the user is correct.
answered Nov 26 at 14:14
Kianii
1267
add a comment |
up vote
1
down vote
In addition of martinstoeckli answer :
Rule n°2 : Encryption will always be the second choice. If you can use hashing, please do.
HTTPS is asynchronous cryptography (private + public keys). The principle is everything encrypted using public key can only be decrypted using THE private key associated.
In our case, the client will use the public key to encrypt data. And the server will be the only one able to decrypt the data using the private key.
So you will get the plaintext of the data after the private key did its job.
At this point, the best thing to do (to my opinion) is hashing (+ salt + eventually pepper) data and store the hash in database.
When the user will, for example, try to login using his password, the server will once again hash the plaintext password received (using the same salt / pepper obviously) and compare with the one in database.
if the hash is the exact same that the one in database, it means that the password entered by the user is correct.
answered Nov 26 at 14:14
Kianii
1267
add a comment |
up vote
1
down vote
up vote
1
down vote
In addition of martinstoeckli answer :
Rule n°2 : Encryption will always be the second choice. If you can use hashing, please do.
HTTPS is asynchronous cryptography (private + public keys). The principle is everything encrypted using public key can only be decrypted using THE private key associated.
In our case, the client will use the public key to encrypt data. And the server will be the only one able to decrypt the data using the private key.
So you will get the plaintext of the data after the private key did its job.
At this point, the best thing to do (to my opinion) is hashing (+ salt + eventually pepper) data and store the hash in database.
When the user will, for example, try to login using his password, the server will once again hash the plaintext password received (using the same salt / pepper obviously) and compare with the one in database.
if the hash is the exact same that the one in database, it means that the password entered by the user is correct.
answered Nov 26 at 14:14
Kianii
1267
In addition of martinstoeckli answer :
Rule n°2 : Encryption will always be the second choice. If you can use hashing, please do.
HTTPS is asynchronous cryptography (private + public keys). The principle is everything encrypted using public key can only be decrypted using THE private key associated.
In our case, the client will use the public key to encrypt data. And the server will be the only one able to decrypt the data using the private key.
So you will get the plaintext of the data after the private key did its job.
At this point, the best thing to do (to my opinion) is hashing (+ salt + eventually pepper) data and store the hash in database.
When the user will, for example, try to login using his password, the server will once again hash the plaintext password received (using the same salt / pepper obviously) and compare with the one in database.
if the hash is the exact same that the one in database, it means that the password entered by the user is correct.
answered Nov 26 at 14:14
Kianii
1267
answered Nov 26 at 14:14
Kianii
1267
answered Nov 26 at 14:14
Kianii
1267
answered Nov 26 at 14:14
Kianii
1267
1267
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53418479%2fhow-and-where-encryption-happens-in-a-web-application%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
Passwords are salted and hashed, not encrypted, whether or not you're using HTTPS (you should).
– jonrsharpe
Nov 21 at 18:37