# POP3 Weak Authentication Testing

- **URL:** https://hackindex.io/services/pop3/vulnerability-discovery/pop3-weak-authentication
- **Path:** POP3 > Vulnerability Discovery
- **Up:** [Vulnerability Discovery](https://hackindex.io/services/pop3/vulnerability-discovery.md)
- **Published:** 2026-03-29
- **Updated:** 2026-03-29

POP3 authentication weaknesses expose credentials and mail content to network interception. The most common misconfiguration is SASL PLAIN or LOGIN available on port 110 without requiring STLS first: meaning credentials are sent base64-encoded but essentially in plaintext over the network. Each check below is an independent finding. Run these after [POP3 enumeration](https://hackindex.io/services/pop3/enumeration/pop3-enumeration) identifies the available capabilities and auth mechanisms.

- Plaintext AUTH on Port 110 Without STLS
- Confirm Whether STLS Is Enforced
- No TLS Available at All
- Weak Authentication Mechanisms

## Plaintext AUTH on Port 110 Without STLS

If PLAIN or LOGIN is in the CAPA output on port 110 and STLS is absent or not enforced before AUTH, credentials are transmitted in plaintext. Confirm the condition by attempting authentication without upgrading to TLS first:

```bash
echo -e 'CAPA\nQUIT' | nc -nv $TARGET_IP 110 | grep -iE 'sasl|stls'
# SASL PLAIN LOGIN
# STLS
```

```bash
echo -e "USER testuser\nPASS testpass\nQUIT" | nc -nv $TARGET_IP 110
# +OK Dovecot ready.
# -ERR [AUTH] Authentication failed.
```

The server accepted the USER and PASS commands without requiring STLS first: this confirms plaintext credential transmission is possible. An authentication failure here is expected since the credentials are wrong, but the server accepted the commands without enforcing TLS, which is the misconfiguration.

## Confirm Whether STLS Is Enforced

A correctly configured server rejects USER/PASS before STLS with a specific error. Check whether the server enforces it:

```bash
echo -e "CAPA\nUSER test\nQUIT" | nc -nv $TARGET_IP 110 | grep -iE 'stls|tls|secure|must'
```

A hardened server returns something like `-ERR TLS required` when USER is sent before STLS. No such error (and the server accepting USER) confirms TLS is not enforced before authentication.

## No TLS Available at All

When neither STLS nor port 995 is present, all POP3 traffic including credentials and message content is permanently plaintext:

```bash
nmap -sV -p 110,995 $TARGET_IP | grep -E 'open|closed|filtered'
# 110/tcp open  pop3
# 995/tcp closed pop3s
```

```bash
echo -e 'CAPA\nQUIT' | nc -nv $TARGET_IP 110 | grep -i stls
```

Port 995 closed and no STLS in CAPA confirms the server offers no TLS path. Any credential sent to this server and any mail content downloaded is visible to anyone with network access on the path.

## Weak Authentication Mechanisms

SASL PLAIN and LOGIN transmit credentials in base64: trivially decodable. Check whether stronger mechanisms like SCRAM-SHA or NTLM are available or whether only weak ones are offered:

```bash
echo -e 'CAPA\nQUIT' | nc -nv $TARGET_IP 110 | grep SASL
# SASL PLAIN LOGIN
```

```bash
echo -e 'CAPA\nQUIT' | openssl s_client -connect $TARGET_IP:995 -crlf -quiet 2>/dev/null | grep SASL
# SASL PLAIN LOGIN SCRAM-SHA-256
```

Only PLAIN and LOGIN on port 110 while port 995 also offers SCRAM-SHA-256 confirms the stronger mechanisms are available but the plaintext port is not hardened to require them. This is a configuration finding: the server should either disable AUTH on 110 entirely or enforce STLS before allowing AUTH commands.

## References

- [RFC 2595: Using TLS with IMAP, POP3 and ACAP](https://www.rfc-editor.org/rfc/rfc2595) - STLS requirement specification for plaintext mail protocols