12
I am in doubt if I should encrypt a password before sending it to the server, and on the server save the hash in the bank, or if I should encrypt only on the server...
2 answers
4
There is a difference between encrypting (protecting the communication between the client-server; example of algorithms: AES, Chacha20, Salsa20, DES, 3DES...) and deriving (prevent the discovery of the initial value and conversion of passwords to keys, examples: PBKDF2, Bcrypt, Scrypt, Argon2).
There are advantages between deriving on the client side. One of them is to avoid Dos on your server, you have not read wrong.
What happens is that the PBKDF (Password Based Key Derivation Function) algorithms are extremely dependent on the computational cost, the better. An offline cryptocurrency wallet can afford to take 10 seconds, using all processor cores and more than 8GB of RAM, just to derive a password. A password disk encryption (first converts the password into a key, using such a derivative, to then encrypt) can also take a few minutes to derive, taking the device to the extreme, since this should be done only once.
However, websites cannot afford this luxury. Your website should respond quickly, usually in less than 1 second. It should still respond to multiple users. So you can’t use 100% of the server capacity just for this activity, so you should reduce the computational difficulty.
That’s why you can combine both sides. Your client is part of the job and you do the other part. Your client can use PBKDF2 (natively available in the Webcrypto API) and your server uses this result and drift with Argon2, then compare. It is important to note that your server should derive the derived result, if you are not storing a password equally in plain-text.
The derivation requires a salt, which must be unique. In the case of the customer, salt may be the email, it will be unique, but deterministic, if the email is not changed. But if the password is changed it will use the same salt, then there will be two passwords for the same salt, which is not "perfect". The other way is to make a query of which user’s salt, but this can also reveal whether it is registered or not. Another problem is users with slow computers, or smartphones, which may take longer to log in.
Lastpass uses the customer side drift technique.
Already encrypting doesn’t make much sense. TLS already does that, so just use HTTPS.
2
Cryptography and hashing are different things. Usually when hashing a password, you add "Salts", which are extra items added to the password before hashing to have greater security.
For example you can save user password as data_cadastro + senha + id and hash it up. When validating the password, you take the registration date, id and concatenate with the password of the user who was informed, and compare the two hashes.
This provides an extra layer of security and no client knows what their hashing methods are.
If you do this on the front, it’s easy for the customer to find out how it’s done.
I believe you should stay in the back end anyway.
Remember that by HTTPS, the information is already sent to the encrypted server, through SSL. If this was one of the reasons for questioning, the HTTPS already covers ;)
Browser other questions tagged security-guard cryptography
You are not signed in. Login or sign up in order to post.
That’s a good question. I think the short answer would be, "Encrypt on the server, send over an HTTPS connection". I think that because everything on the client is insecure, then the encryption algorithm itself can be changed on the client. I did not create an answer on this because my opinion, without grounds or evidence, would only "pollute" the answers. I leave here for debate :D
– fernandosavio
I asked about it in the security SE., I have been given some answers. It is not a very trivial subject.
– Piovezan
TLS is safe, assuming the authorities are. You have Expected-CT and there was also the old HPKP that ensures even more security as to a corrupt CA. You should also use HSTS to prevent a downgrade to HTTP, so the site can only be accessed using HTTPS, including using Preload and sending the site to a list, so the new browsers already know that your site only goes through HTTPS. TLS guarantees "Perfect forward secrecy", since it uses unique keys to each connection and keys are destroyed after use, of course if you use ECDHE (or DHE).
– Inkeliz