Passwords in Plain Text: When a Login Form Fails to Protect Credentials

Aditya Dharpally

3 hours ago

3 min read

A routine security assessment uncovered a login form sending passwords over unencrypted HTTP, exposing credentials in network traffic and server responses.

Login form and security shield representing secure password transmission over HTTPS

The Discovery

During a routine security assessment, a serious issue was found in a login form: passwords were being transmitted over unencrypted HTTP.

A typical request looked like this:

POST /login.aspx HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

username=testuser&password=[TEST PASSWORD]

There was no HTTPS encryption protecting the connection. The password was being sent as plain text across the network.

Worse, the server also echoed the password back in the HTML response:

input name="password" type="password" value="[TEST PASSWORD]"

This meant the credential could potentially appear in multiple places, including:

Network traffic
Server logs
Browser cache
Proxy logs

What looked like a basic login form was therefore exposing sensitive authentication information in more than one way.

The Impact Sending passwords over an unencrypted connection can have serious consequences:

Credential Theft - Anyone able to observe the network traffic may be able to capture passwords.
Account Takeover - Stolen credentials can provide access to accounts and sensitive business data.
Password Reuse - If users reuse passwords across services, exposed credentials could be used to target other accounts.
Compliance - Insecure handling of credentials can create issues with security and compliance requirements such as PCI DSS, GDPR, and ISO 27001.

CVSS Score: 7.5 (High) - Easy to exploit, with potentially severe consequences.

How to Reproduce (Ethically)

This type of issue can be identified during an authorized security assessment using test accounts and controlled traffic.

Using cURL

curl -v "http://example.com/login.aspx" -X POST -d "username=test&password=test123"

The request can then be reviewed to determine whether the credentials are being sent over an unencrypted connection.

Using Burp Suite

Set up the proxy.
Intercept the login request.
Review the request and check whether the password is transmitted in plain text.

Using Network Analysis Tools

Traffic on an unencrypted HTTP connection can also be inspected with network-analysis tools such as Wireshark or tcpdump.

tcpdump -i eth0 -A -s 0 'tcp port 80'

These checks should only be performed against systems where you have explicit authorization to test.

The Fix

The good news is that the issue can be addressed with a few important security controls.

1. Enforce HTTPS

All login pages and authentication requests should use HTTPS.

For example, an Nginx server can redirect HTTP traffic to HTTPS:

server {
    listen 80;
    return 301 https://$server_name$request_uri;
}

For IIS, configure a redirect rule that sends HTTP requests to HTTPS.

2. Get a TLS Certificate

A valid TLS certificate is required to properly secure HTTPS connections.

For example, with Certbot:

sudo certbot --nginx -d example.com

3. Stop Echoing Passwords

Passwords should never be returned to the browser after submission.

Dangerous:

txtPassword.Text = Request.Form["password"];

Safe:

txtPassword.Text = "";

The application should never unnecessarily return sensitive credentials in its responses.

4. Secure Cookies

Authentication cookies should also be protected with appropriate security flags:

httpCookies requireSSL="true" httpOnlyCookies="true"

5. Add HSTS

HTTP Strict Transport Security (HSTS) helps ensure that browsers continue using HTTPS when accessing the application.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Prevention Checklist

To prevent similar issues:

Enforce HTTPS everywhere
Redirect HTTP traffic to HTTPS
Set Secure and HttpOnly cookie flags
Implement HSTS
Never echo passwords or other sensitive data
Perform regular security scans
Provide security training for developers

Common Misconceptions

“We use a VPN, so we're safe.”

A VPN protects the connection between the device and the VPN server. It does not automatically make an application's connection to its server secure.

If the application itself still uses HTTP, credentials can remain exposed within that connection.

“It's just an internal app.”

Internal applications can still be compromised.

Ransomware, insider threats, compromised devices, and lateral movement can all put internal networks at risk. Sensitive credentials should be protected regardless of whether an application is public or internal.

“We encrypt passwords client-side.”

Client-side encryption is not a substitute for TLS.

The correct approach is to use HTTPS to protect credentials while they are being transmitted between the user and the application.

Key Takeaway

Security isn't always about complicated defenses. Sometimes, it's about getting the basics right.

Passwords should never be sent over unencrypted HTTP, and applications should never echo sensitive credentials back to the browser.

HTTPS is widely available, straightforward to implement, and has been a standard security requirement for years. Protecting credentials in transit should be a basic part of every secure login system.

Stay curious. Stay secure.