Sending password safely from the front-end to the back-end using MD5

Question

I've encrypted a password field in my DB by MD5, and I handle it encrypted in my back-end, but when user types their password in, it is in plain text.

Is there a safe way to pass the password from the front-end to the back-end? MD5 doesn´t have sense in this case...

NOTE: I'm using HTTPS and the POST Method.

Solution 1

You can think about the following steps to protect the password:

1. Use HTTPS preferably with HSTS to protect the passwords during transport;

2. Use a password hash such as bcrypt instead of MD5 to protect the password on the server.

   • HASH passwords with salt;
   • use a high work factor for bcrypt.

MD5 is not the best way to hash. MD5 is not considered secure anymore.

MD5 is not encryption; don't encrypt passwords, hash them, encryption can be decrypted, hashing cannot be reversed.

Solution 2

While the accepted answer correctly describes how you should STORE passwords on the server side, the question was actually on how to transmit password safely from client to server.

I just want to make clear that the salting and hashing is done at the server side. The client would just sent the clear text password over a secure connection (HTTPS) to the server.

Solution 3

Passwords in database must be hashed and kept to secure user's account in case of any unfortunate database leak or hack. But this does not secure the data passed on the network from frontend to backend. For the same using HTTPS helps to encrypt all data passing on the network.

Comments

[Elias MP]

Thanks Tom. Yep, I´m speaking about hearsay but I´m pretty sure I read something about MD5 was hacked in myspace... So I´m writting down... Bcrypt and if not hash... Cheers

[Tom]

Yes, MD5 not considered sure anymore. And using a salt is a good practice.

[Maarten Bodewes]

I've edited this answer substantially, adding a the term work factor. Otherwise it's the same content. Please edit or roll back if you're dissatisfied with my edits.

[Maarten Bodewes]

You could cheat a bit and let the client do most of the work, only to perform the last part of the hash on the server.

[MvdD]

@MaartenBodewes How would that work exactly? The client does not have access to the salt. Also, you want to have the hashing done at the server side as it prevents the client from distributing the work.

[Maarten Bodewes]

You can send the client the salt. The client distributing the work is not possible as bcrypt is sequential in nature. But even if it would be then the client distributing the work is not a problem; an attacker could distribute the work, but that's not the problem in the first place. If required you could keep a pepper at the server side (a secret value). But I must admit that these kind of schemes are not common (if only because it would be dog-slow in JavaScript).

[MvdD]

As are most things in JavaScript. :) You're correct on the hashing being sequential, so distributing is not an issue. However, if the hashing doesn't happen on the server side, the hash becomes the password. An attacker can try to brute force the system by trying out all possible hashes as there's no slow down at the server side anymore.

[Maarten Bodewes]

You would still have to generate all the hashes first given the salt, and send each one over to the server to verify them. You cannot just iterate over, say, 2^160 hashes. That's kind of the point.

[MvdD]

True, but if you have the salt, you can take a password dictionary and generate hashes for them. This is something you can distribute. Then, you take the generated hashes and try them against the server. As there's no delay, this is a significant advantage over having to try the password dictionary against the server itself, not?