The client should only use the hash if the hash is stored on that client. Otherwise send the pw over https and encrypt On the server.
Once the password is checked and valid, that should be it for that session. The server/backend should then generate a unique session token and return this to the client. From then in, until the token is expired, only the token should be used for authorisation.
The less you use and send around the pw the smaller the chance someone gets his fingers on it.
If it’s not happening in an app, do NOT encrypt the pw on the client. The wncryptiom key should ONLY be known by the server/environment and should NEVER be shared with any other system.
Check out some tutorials for JWT, they usually cover most of this, at least the logic part.
@just8littleBit there are other ways to do it and someone will attack me for this. But this is the basic and most common approach.
Also, make sure your encryption is a 1-way encryption.
And the key should be stored in a secure place (often as a env variable), never put it in any properties file. It’s a common thing I see with e.g spring boot noobs.
@just8littleBit thanks. My friend just explained me jwt in great detail. I kind of got it, its like making the password super irrecoverable . Like the password is just being stored fully encrypted and never used otherwise. He would use other details like email, first name last name etc , to create a jwt and instead of password being encrypted/decrypted, its the jwt that gets encrypted/decrypted.
I like that approach. But the difference between my approach and jwt approach is that in jwt approach mainly anyone can access the user account if the jwt encryption key is leaked. In my approach any account can be breached if my encryption/decryption algorithms got leaked. So yeah jwt wins.
Any other approach you know about being professionally used? I find these studies on system designing very interesting
@2Large yea, the jwt shouldn’t be generated from other data like email and stuff. It can just be a UUID, no one will ever guess or brute force a UUID.
Well, Anything you can imagine probably exists, all the way to IP whitelisting and mapping to user accounts. That mainly makes sense on a already secure, private network.
@just8littleBit hold on, so jwt , which is already an encrypted form of data should also be generated from a irrelevant data i.e uuid? Seems redundant to me? For my friends case, he is decrypting the jwt sent by client to get access to various user info, so that he could use those and run the user requested query.
What would the jwt generated via uuid be useful for? I guess you would have to maintain another table which has the mapping for entries to uuid (or an extra uuid column)
AvyChanna69718d@yowhatthefuck And what happens if someone steals the hash?
On another note, JWT is a nice and easy to understand option IMO.
You store input + hash of (input+secret). To verify, check if hash is correct, else reject. You can not fake hash because you don't know secret.
If hash is hmac sha*, only the signing party will be able to verify, because noone else knows your secret. If you use RSA/asymmetric cryptography, then ANYBODY can verify your secrets, given public key.
In any case, if you use a strong hash function and secret, nobody but you can sign. And by property of hashing, nobody can find out the secret or make a fake hash
AvyChanna69718dAnd, whatever you store in JWT is plaintext encoded, so make sure there is no personal identifiable information in JET token. That is why, associate UUID with some account, and use that to authenticate. Now nobody can get any information, even if token is stolen