We have our web app / REST API getting tested by potential customer. In the report they came up with this issue:

Sensitive data like user credentials on login page, password reset, change password etc. are sent in clear text format. If sent in clear text format attacker can steal those from the browsers memory.

And I am wondering whether it is time to dispute this as - obviously, since this is year 2021 - the connection is over HTTPS. They can see the credentials in the network tab of the browser console but it is the same bloody password they entered one sec ago and sent.

The recommendation is:

It is recommended to use hashing to send the credentials over the network. Strong hashing like SHA-256 should be used.

It seems like some dated info or test method used from the old days when https was rare.

As security professionals - what would you recommend? Should we cope with the requirement or should we dispute that it is unnecessary layer over HTTPS that is in place?

I am aware of questions (*) dealing with the topic itself and I am also aware that this might lead to opinionated answers. Still trying my luck as it seems a bit over the top. Thx.


  • 1
    What's your question? You already have our technical recommendations in those other questions. If your question is client management, that's not a security concern. I'd get them to see if their google password is sent in clear text...
    – schroeder
    Oct 6, 2021 at 22:25
  • 1
    "It is recommended to use" -- simple, get them to cite the source of the recommendation
    – schroeder
    Oct 6, 2021 at 22:26
  • 2
    Your hunch is absolutely correct, and you linked all the relevant questions. The problem of insecure data transport is addressed with HTTPS. If that's up correctly, you don't need to be be concerned about secure data exchange between client and server. (Securely storing secrets would be a different story, as you certainly know.) Also, welcome!
    – Arminius
    Oct 6, 2021 at 23:05
  • 2
    @Arminius thx. We are storing credentials on the server hashed by bcrypt.js, I think that should be fine.
    – PeS
    Oct 7, 2021 at 0:19
  • 1
    What they recommend is a well known anti-pattern CWE-836: Use of Password Hash Instead of Password for Authentication (cwe.mitre.org/data/definitions/836.html), exposing you to CAPEC-644: Use of Captured Hashes (Pass The Hash) (capec.mitre.org/data/definitions/644.html). Whoever is testing isn't or shouldn't be a security professional. Oct 27, 2021 at 9:10

1 Answer 1


This is obvious malarkey, and whoever wrote that report has no idea what they are doing.

As all the linked answers state, it is perfectly fine to send plain passwords over TLS. I strongly suspect that whoever wrote this "recommendation" mixed up "Don't send passwords over plaintext" with "Don't store passwords in plain text."

But better than disputing their finding would be to ask them to actually attack your system and demonstrate how it supposedly is vulnerable. Since it's not, they'll have to admit that it's secure.

  • I disagree. Anyone on that system can see that password come in. It is not malarkey. Passwords should always be hashed client-side before being sent over any network, encrypted or not.
    – 8vtwo
    Oct 7, 2021 at 4:02
  • 5
    @8vtwo please have a look at the linked questions. If you send the hash, then the hash becomes the password, which means "Anyone on that system can see that password come in." Please provide an example of a major site that hashes passwords before sending over TLS. Or is this just your personal preference?
    – schroeder
    Oct 7, 2021 at 7:15
  • 2
    @8vtwo This is simply wrong. No major website implements that, no security professional recommends that.
    – user163495
    Oct 7, 2021 at 11:37
  • 1
    @8vtwo Congratulations you just made the system vulnerable to "pass the hash" attacks. Did you work at Microsoft in the nineties? Oct 27, 2021 at 8:54

Not the answer you're looking for? Browse other questions tagged .