My login for POST is over HTTPS. Therefore, I don't do anything to the provided password before submitting. And I don't see an issue there unless someone is watching your browser's developer console. (Tested the Google login. They also share the same approach.)

But I've received a concern asking "malicious user succeeds in session hijacking in someway will be able to access the end user credentials". Is this a valid argument? if so, how can I act?

  • See security.stackexchange.com/questions/110415/…
    – mti2935
    Commented Jun 25, 2020 at 11:20
  • 2
    "session hijacking" != "data stream hijacking" Their comment makes no sense or is missing crucial context. It IS possible (depending on your UI design) to hijack a session and set the password on the account using UI tools, but that has nothing to do with HTTPS, POST, or login.
    – schroeder
    Commented Jun 25, 2020 at 11:20
  • Aside from what has been discussed, could they maybe be referencing CSRF or maybe even XSS on the login form?
    – Elie Saad
    Commented Jun 25, 2020 at 11:54
  • session hijacking is a separate issue and is about how you tie your session to your authentication. (basically what does the client store to validate the session? If the client stores the password, you probably want to change that... and always have the user re-enter the password when changing their account details... i.e. password change, e-mail change... don't rely on session.) Commented Jun 25, 2020 at 18:24

4 Answers 4


Passing plain text passwords over HTTPS is absolutely fine. TLS makes sure it's not plaintext on the wire, so there is no issue. Client side hashing would do nothing to help here. The fact that you can get the password from the development console is expected and not an issue.

As for the concern about session hijacking, I don't get it at all. If an attacker that has hijacked a session could somehow get your password I would view that as a problem since it would allow an attacker to go from temporary access to permanent access. But sending your password untouched over HTTPS would on itself not lead to that. I think that either the person that told you this is misunderstanding something, or you misunderstood the concern. Is it perhaps related to some other wider issue?

Finally, a side note. You write that your "login for POST is over HTTPS". Are you using HTTPS just for the login? That is not enough. Your entire site - absolutely everything - needs to be over HTTPS. Just protecting the login endpoint makes you vulnerable to SSL-strip. If you use plain HTTP without TLS for parts of your website, you need to fix that.


Having the clear text on Developer Console is not an issue, it's part of how the browser works. TLS is designed to protect data between when it leaves your computer and reaches the end server. It's not to protect against hardware keyloggers, rubber-rose cryptanalysis, or developer consoles.

But I've received a concern asking "malicious user succeeds in session hijacking in someway will be able to access the end user credentials". Is this a valid argument? if so, how can I act?

If this is the concern, you must look somewhere else. The issue is not with TLS at all, the issue is at the application level, or database.

Do your application have any anti-XSS (cross site scripting) and anti-CSRF (Cross Site Request Forgery) protections in place? If not, an attacker may inject script on a client (XSS) or trick a client into accessing a crafted page while logged into your application (CSRF) and execute code as the user.

How are your application managing user input that is fed to databases? Is the application preventing SQL Injection? If not, an attacker may execute SQL on your database and leak data, specially passwords.

If the entire site is served over TLS, you don't have to care about that part. You need to make sure the application follows secure coding standards. That's what you can do. On the TLS side, it does not hurt to test the cyphers and modes enabled. SSL Labs have a good one.


You can avoid sending plaintext passwords over the wire, even if using TLS, but it won't be as easy to avoid sending something that is susceptible to a replay attack (i.e. a mangled password), even if that helps with protecting actual passwords.

But I've received a concern asking "malicious user succeeds in session hijacking in someway will be able to access the end user credentials". Is this a valid argument? if so, how can I act?

Session hijacking is an issue that is not directly affected by how he password is sent over the wire. A successful session hijacking attack lands the attacker on a valid authenticated session, as if they had just authenticated as a legitimate user, except they didn't. This does not reveal or leak information (including passwords) sent over the wire by the authenticated user (although the application itself could leak this information if it is poorly written).


It may be better if you compute some sort of hashed version of the password in the browser and pass that along to the server, that would eliminate the exposure of the plaintext password.

  • 1
    There are significant problems with hashing client-side and is only relevant ins certain contexts. security.stackexchange.com/…
    – schroeder
    Commented Jun 25, 2020 at 14:13
  • 3
    No, that's not how you do it. Using the hash of the password turns it into the password.
    – ThoriumBR
    Commented Jun 25, 2020 at 17:17
  • Of course there are, and also there are several advantages. security.stackexchange.com/search?q=advantages+client-side+hash It is given that you implement it correctly (salted hash with n iterations of a standard algorithm), so that may take care of some of them. Putting a control inside a control, like this one: encrypting (with TLS) an obfuscated version of the password (HASHED password) is called "defense in depth", the idea is not having a silver bullet (one unique perfect control), but several concentric controls to protect an asset. Commented Jun 25, 2020 at 18:36
  • 1
    It's not about how well you implement it. And it's not about defence in depth. You are making blanket claims about client-side hashing without mentioning the problems, implementation contexts, and threat contexts that would be important when suggesting unrecommended practices.
    – schroeder
    Commented Jun 25, 2020 at 20:18

You must log in to answer this question.

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