Hiding Password of the user

Support
#1

Hi,

On login screen when i enter username and password to login if in scenario i press backspace in password field internally listener is called by default on backspace and password is getting captured in the security tool.

Below json request is getting captured in which password is visible in clear text in mSync value how to hide this listner or password value for security reasons.


{"csrfToken":"7edf2ff3-5757-43dd-8e74-296f5b6400ef","rpc":[{"type":"event","node":43,"event":"validated","data":{"event.detail.valid":true}},{"type":"mSync","node":43,"feature":1,"property":"value","value":"adm"},{"type":"event","node":43,"event":"change","data":{}},{"type":"event","node":43,"event":"validated","data":{"event.detail.valid":true}}],"syncId":7,"clientId":7}
#2

Hi,

just to clarify: in any login flow — whether it’s a traditional form-based login (e.g., HTML + Spring Security), a React frontend calling a REST or OAuth endpoint, or a Vaadin-based UI — the password needs to be transmitted to a server at some point, typically when the user clicks the “Login” button.

In Vaadin, depending on how components are configured, the client might send additional input events (like pressing Backspace) to the server, but that’s unrelated to the actual login process. Even without those interactions, the full password is always transmitted when the login is triggered.

The crucial part is that this transmission happens securely — and that’s why using HTTPS is essential. HTTPS ensures that the communication between browser and server is encrypted on the transport layer, so that sensitive data like passwords cannot be intercepted or read by third parties (e.g., on public Wi-Fi or corporate proxies).

Even when using OpenID Connect (OIDC), the password is still transmitted — not to your application, but to the identity provider (e.g., Keycloak, Google, etc.). So an HTTP-based interaction involving the password still takes place — just outside your app.

If you want to go a step further and avoid transmitting passwords altogether, some identity providers support WebAuthn, a browser standard for passwordless login based on asymmetric cryptography. With WebAuthn, authentication is performed using a private key stored securely on the user’s device (e.g., via Face ID, fingerprint, or a hardware token like YubiKey). Only a signed challenge is sent to the server — the password never leaves the device, and in fact, there is no password at all.

However, this also means adopting a different authentication paradigm: instead of identifying users by their credentials, the system identifies them based on registered public keys. So yes — it’s possible to avoid sending passwords, but it requires support for passwordless login and a proper public/private key infrastructure, either through something like WebAuthn or mutual TLS.

In short: if you’re using passwords (even with OIDC), they must be transmitted — securely. If you’re not using passwords at all (e.g., with WebAuthn), then transmission of secrets can be avoided entirely — but that also shifts the identity model and comes with different requirements.

Best regards,

Mario

3 Likes
Getting visible data in response
mSync Request Capturing
Sensitive data is visible in the request and response
Text Field Data Capturing the request when clicking outside of text field
Server Side Encryption and Client side Decryption
#4

@mario
Thanks for the reply.

Can we restrict or obfuscate the username and password from the request so that even that details are unrelated to the actual login process these details are not human readable or hidden.

#5

Hi @adnan.khan ,

just to make sure I understand your concern correctly:

Are you referring to the fact that someone might open DevTools in their own browser and inspect the network traffic during login? Or are you concerned about someone intercepting the traffic on the network level (e.g., via sniffing on a proxy or public Wi-Fi)?

If it’s the latter, then HTTPS is exactly what protects you here: the password (and all other traffic) is encrypted on the transport layer, so nobody between the client and server can read it — not even with deep packet inspection.

If it’s the former (i.e., someone inspecting their own browser’s traffic), then we’re talking about a trusted user on their own machine. Since login already assumes the user is who they claim to be, there’s little added value in hiding password characters from the DevTools — especially considering that the user just typed the password moments milliseconds ago.

The only real concern here would be shared-user environments — e.g., if multiple people use the same session on the same physical machine. But in that case, you’d already have much deeper trust issues and security gaps, since everyone using that session would implicitly have access to the same resources — including the password field if someone types it.

That being said, yes — you could try to technically obfuscate or encrypt the value on the client before sending it over the wire. One possible (though advanced) way would be to create a custom HTML component that encrypts the password using a public key (fetched from the server), and then sends only the encrypted string back. On the server side, you’d decrypt it with the corresponding private key. That being said there is a common saying in security which goes like “never roll your own authentication” - this is mostly likely to go wrong or does not really help. Here is an immediate counter example of my above claim that something like public / private key solution might work:

  • The client-side encryption logic runs in the browser, and anything in the browser can be inspected or tampered with.
  • Replay attacks are still possible unless you introduce signed challenges or nonces.
  • If someone has access to the machine and wants to steal the password, they could just install a keylogger and bypass the entire mechanism.

So in short: obfuscating passwords inside your own browser’s DevTools offers very limited protection, and if you don’t trust the client environment, it’s nearly impossible to secure this without moving to something like WebAuthn, where the secret never leaves the device.

Probably it is easiest if you really want to have a bullet proof solution is to rely on open mature standard solutions like keycloak with passwordless authentication.

Cheers,
Mario

#6

Hi @mario,

It is related Unencrypted Sensitive Data Transmission related concern. Also were are using HTTPS urls .

Sensitive information such as Credentials or other confidential data is stored or transmitted in
an unencrypted format. Without encryption, this data is vulnerable to unauthorized access
and exploitation by attackers, who may intercept or retrieve it from databases,
communication channels, or storage locations.

image

I am able to Capture the login request in Burp Suite, Here the username is visible in plain text
without encryption.

image

Capture the login request in Burp Suite, Here the Password also visible in plain text
without encryption.

image

Since user details are easily visible in the burpsuite any person who has such access can gain user details

Impact:
●
Data Exposure: Sensitive information stored or transmitted without encryption can be
easily accessed by attackers in case of a breach, leading to identity theft, financial
fraud, or unauthorized access to systems.
●
Operational Disruption: Unencrypted sensitive data can be exploited by attackers to
disrupt business operations, leading to downtime, service outages, or unauthorized
actions that hinder normal system functions or processes.
●
Credential Theft: Attackers can steal user credentials or session tokens, which could
lead to account hijacking or unauthorized access.