Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
Let me tell you (certainly almost) nobody uses passwords encrypted on the frontend. Not Google, not Microsoft, not your Bank.
And there is a reason for this.
Even if you encrypt a password and send it as a hash instead of plaintext, you need to accept username/hash combination on the backend. The Man-In-The-Middle attacker can take your hash instead and make authentication attempt the same way as he would do with plaintext password. You added no security.
You could try to solve this problem by encrypting your password on the frontend with random salt that the MITM does not know, generated for each login attempt. But for this you have to first send the user the random salt to the login form which MITM can read anyway so he has the salt and a hash - no added security...
All this has already been solved. It's called TLS (previously SSL) that is the lower part of the HTTPS protocol that does this during TLS session establishment where the very first part is to securely agree between the client and the server on random pre-shared key in a way, that MITM is not able to guess it - using Diffie-Hellman key exchange.
In addition random unique key is generated from server's private key on each session as part of Perfect Forward Secrecy to avoid possibility to decrypt all sessions derived from one private key in case this one is compromised. That means if you manage to get hold of the server's random private key - you are only able to decrypt one session but nothing else (sessions started before or after or with different clients have their own random keys).
This is our plaintext encryption "salt" that guarantees the password inside a HTTPS protocol login call is each time encrypted differently without the MITM attacker to be able to compromise it, and even if he does it's invalid in any other started session. The benefit is you have to do nothing at the application level. This is baked into another ISO/OSI layer and is fully transparent to higher protocols like L7 HTTP.
So please, do not try to reinvent the wheel!
And yes, our site has strict policy regarding HTTPS. We implement HSTS, CSP, we do not support HTTP connections at all.
Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
I tried to explain to you you don't ever need to hash passwords or any sensitive data if you're using lower level security which does secure shared secret negotiation followed by encryption of payload in transit.
If you don't care why Google sends cleartext passwords you're the one that's missing something.
Please, go and study that topic to understand it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi,
thank you for your feedback.
Let me tell you (certainly almost) nobody uses passwords encrypted on the frontend. Not Google, not Microsoft, not your Bank.
And there is a reason for this.
Even if you encrypt a password and send it as a hash instead of plaintext, you need to accept username/hash combination on the backend. The Man-In-The-Middle attacker can take your hash instead and make authentication attempt the same way as he would do with plaintext password. You added no security.
You could try to solve this problem by encrypting your password on the frontend with random salt that the MITM does not know, generated for each login attempt. But for this you have to first send the user the random salt to the login form which MITM can read anyway so he has the salt and a hash - no added security...
All this has already been solved. It's called TLS (previously SSL) that is the lower part of the HTTPS protocol that does this during TLS session establishment where the very first part is to securely agree between the client and the server on random pre-shared key in a way, that MITM is not able to guess it - using Diffie-Hellman key exchange.
In addition random unique key is generated from server's private key on each session as part of Perfect Forward Secrecy to avoid possibility to decrypt all sessions derived from one private key in case this one is compromised. That means if you manage to get hold of the server's random private key - you are only able to decrypt one session but nothing else (sessions started before or after or with different clients have their own random keys).
This is our plaintext encryption "salt" that guarantees the password inside a HTTPS protocol login call is each time encrypted differently without the MITM attacker to be able to compromise it, and even if he does it's invalid in any other started session. The benefit is you have to do nothing at the application level. This is baked into another ISO/OSI layer and is fully transparent to higher protocols like L7 HTTP.
So please, do not try to reinvent the wheel!
And yes, our site has strict policy regarding HTTPS. We implement HSTS, CSP, we do not support HTTP connections at all.
Please stop being rude.
I tried to explain to you you don't ever need to hash passwords or any sensitive data if you're using lower level security which does secure shared secret negotiation followed by encryption of payload in transit.
If you don't care why Google sends cleartext passwords you're the one that's missing something.
Please, go and study that topic to understand it.