When you login with a username and password in the Web UI, the password is sent as-is. Does Vault support logon with POST of the hash of the password, instead of the real thing? This is considered by some as a security issue even when using https.
Are you asking for security of the password? That’s a dawback of userpass but it’s a TLS tunnel and encrypted anyway.
Yes, I am asking about the security of the password. Any idea if there are plans for this behavior to change? Obviously under https it’s not a big deal that the whole password is sent, but this is a feature our security team would still love to see.
Your security team has no idea what they are talking about.
Say this change was implemented. The password typed by the user would be hashed before it was sent to the server. Your password was 123 it is now a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3 because you use SHA256 to hash it.
What you did is just change the password at runtime to antoher fixed value. If an attacker (running some password stealing malware on your computer) is able to steal your password, it can steal (or compute) the hash of it.
Sending hashed password brings no security but only complexity. You could argue that this change would actually decrease the overall security because of the increased complexity. That’s why web applications never do that.
The real problem with passwords is that a compromized server can save your password and impersonate you elsewhere, because most people use the same password everywhere. The answer to that is not hashing passwords sent via forms, but using a method that moves the password problem elsewhere (OIDC, Github, client side certificates).
I would ask your security team what is the attack scenario they are worried about and challenge how this security control would mitigate the risk.
1 Like
Another issue is that it would reduce accessibility. As no such functionality exists in browsers you’d have to use Javascript and custom forms, meaning you might exclude certain users (both those who have disabilities or who have disabled Javascript, but also probably those using older browsers, certain types of mobiles, etc.)
1 Like
Thank you for your replies and interest in the topic. The concern was (and I quote) “If the adversary accessed to
the system and dump the browser memory using task manager, an adversary can
view the username and password using winhex.”
Doing it client side means we authenticate with a hash, and the hash becomes our password. That could still be intercepted using the same attack and be reused. Seems we wouldn’t be solving anything, exactly as you said. This article explains it - validation - Send a form with a hashed password - Stack Overflow.
So case closed, thanks again!
1 Like
I really hate this type of thinking by security teams. If an adversary has access to the system to do this in the first place, it’s game over. Hashing my password isn’t gonna save us. The advisory already owns the machine. They can just pull the keystrokes and call it a day.
This type of concern is addressed by short-lived secrets such as tokens. That way, if an adversary does own the machine and dump secrets, the window of attack is reduced. This is one of the use-cases Vault addresses!
2 Likes