0

Is client-side password hashing still necessary / useful when using TLS? What about TLS protocols with PFS (perfect forward secrecy) like Diffie-Hellman?

Let’s say that I’m running a web application which uses authentication (like most websites). Let's say that I'm already doing server-side hashing. As a developer, I am concerned about sending raw passwords from web clients over the internet to my servers, even if the traffic is encrypted with TLS.

In short, I am concerned that an attacker could eavesdrop on these encrypted conversations and eventually crack them. I understand that client-side hashing may still allow rogue clients to impersonate a compromised user, but my customers are most likely re-using their password for my website on other websites. I could at least keep their passwords safe.

As far as I can tell, the attackers have all the time in the world to crack these communications. The attackers don’t need to act fast, as is the case for a replay attack or man-in-the-middle attack. Even if I force my users to change their passwords to a new password every month, that doesn’t force them to stop using their old passwords on different websites. Even if the attacker sits around for a decade with a recorded conversation before cracking it, I’d hedge my bet that a good portion of the passwords are still being used on other sites.

How easy is it to crack even a single packet in a TLS exchange today? What about ten years from now? Will a TLS conversation recorded today be much more crackable ten years from now?

How does the answer change with PFS? As I understand it, each packet would need to be cracked independently, but how difficult is it to guess which packet in a conversation contains a password?

And if this is an issue, how much added protection will client-side hashing add? Hashing when done well is pretty damn irreversable, right? Harder to do than cracking TLS?

Also, as I understand it, certs / private keys are used only for authentication and not encryption with TLS, so leaking my private keys won’t allow attackers to decrypt old conversations, right?

I understand if you think that it isn’t necessarily my responsibility, but in any case, I don’t think that client-side hashing will take much effort. That being said, I’d like to know that it’s worth my while before jumping in.

marked as duplicate by Conor Mancone, Xander, Steffen Ullrich tls Aug 8 at 2:16

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • "I am concerned that an attacker could eavesdrop on these encrypted conversations and eventually crack them." how, if TLS is properly implemented and used on both sides? – Patrick Mevzek Aug 7 at 22:51
  • These are multiple questions at once, i.e. how secure is HTTPS, is it secure enough to transfer passwords in plain, how easy is MITM, do you understand PFS correctly ... I find this too broad and marked as duplicate of questions about client side hashing in the context of TLS which seems to be the main point of the question. If not all points are addressed by these answers please ask more focused (i.e. less broad) new questions. But in short: with a properly setup TLS using PFS you should be safe against passive sniffing (but not active MITM) even if the private key gets compromised. – Steffen Ullrich Aug 8 at 2:19