rare drift
Hello guys,
when the user creates his account in your application, for example he will create it through email and password, the password will be encrypted in the database.
but my question is, how can secure it when making the post request, usually that password will be sent plain text in the request, so if a hacker manages to intercept it, he will literally know the password of that user.
So my question is how can secure it when making the post request?
marsh glen
The body of an HTTPS request should be encrypted. The only unencrypted part of the request, if I recall, is the domain
If that wasn't the case people wouldn't use local logins anywhere
north spruce
Hash the password before saving it. Then you can verify it when they login.
rare drift
The body of an HTTPS request should be encrypted. The only unencrypted part of t...
So no matter the http request sent to the backend, it’s body has to be encrypted ? What about the response requests, do I have to encrypt them too? This all makes sense, bcoz if hacker gets the hold of a valid jwt he can steal the sender identity and perform whatever request in his name
But it brings me the thought that this is extra work for the server, like a trade off, less performance for more security
rare drift
Hash the password before saving it. Then you can verify it when they login.
So the hashing algorithm must be agreed on from frontend n backend
marsh glen
Not sure you quite got it. You don't need to hash or encrypt the response, that's done via the protocol and the underlying https package from Node itself
north spruce
So the hashing algorithm must be agreed on from frontend n backend
Just backend before saving. Example:
POST /register
// step 7, hash password
marsh glen
Just backend before saving. Example:
POST /register
// step 7, hash password
This is only for saving the password to the database. Not required for encrypting the response to the client over HTTPS
north spruce
This is **only** for saving the password to the database. Not required for encry...
I see. Different question.
rare drift
Not sure you quite got it. You don't need to hash or encrypt the response, that'...
Oh I wasn’t aware of this, thanks for bringing it up, so I will encrypt data (the body) from every request in the frontend, and decrypt it in the backend.
And What if my frontend is a mobile app ?
marsh glen
HTTPS should be respected regardless of the client type. Again, if HTTPS didn't work in the first place, you wouldn't see HTTP being used for everything it is used for
By nature, when an HTTPS request is made, the client sends an SSL/TLS handshake request, and negotiates what the HTTPS certificate says the payload should do and who says the certificate is valid. The issuer, the domain, the cert length, all sorts of metadata. Based on all this, so long as the handshake succeeds, the server and client transmit codes that say "This is how the request will be encrypted" and then the client sends the encrypted request. The server receives the request, verifies its integrity, and decrypts it. Then the server starts to actually process the request, which is where our framework level code is executed.
What you're worrying about is all infrastructure that has been laid out and set up and is currently used by billions around the world today. You don't need to worry about re-inventing the wheel by adding encryption on top of a request that is going to be encrypted
lime bronze