- Issue created by @jay jangid
HTTPS is the usual approach. In what way is a plain text password a vulnerability inside a browser?
- 🇮🇳India jay jangid Jaipur
@cilefen Thank you for your response.
You're right that HTTPS is a critical part of secure transmission, and it ensures that data between the client and server is encrypted. However, the vulnerability I'm concerned about occurs inside the browser, before the password is transmitted.
Even though HTTPS encrypts the communication channel, the password is still present in clear text in the browser's developer tools (specifically in the request payload). This could be a risk under certain circumstances:
Local device compromise: If an attacker gains access to the user's device or browser session (via malware, browser vulnerabilities, or insecure environments), they could view sensitive data, including the plain-text password, in the network tab.
Shared or public devices: In scenarios where users are logging in from shared or public computers, the password may remain exposed in the network tab, even after they close the browser.
By implementing client-side encryption, the goal is to reduce the risk of exposing passwords in the browser before transmission. The encrypted password would only be decrypted by the server, adding an additional layer of protection in environments where HTTPS alone might not be sufficient.
Let me know if you'd like more details or clarifications.
So the proposal is to use asymmetric (or symmetric?) encryption on password input with JavaScript. Do I have that right?
If so, wouldn't the decryption key also be available in the console.
- 🇳🇿New Zealand quietone
Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to our policies.
