Password Authentication Protocol (PAP)

In the early days of digital authentication, password-based access felt like enough. If a user could recall the right credentials, they were in. But the simplicity of those early systems didn’t anticipate the modern security landscape or the scale of today’s SaaS platforms. One of the earliest authentication methods, Password Authentication Protocol (PAP), still lingers in some environments. And that’s a problem.

Let’s unpack what PAP is, why it’s outdated, and how forward-thinking teams are moving beyond it without burdening developers with yet another legacy clean-up.

What is Password Authentication Protocol?

Password Authentication Protocol (PAP) is a legacy protocol used in the initial link establishment phase of a network connection, particularly when using Point-to-Point Protocol (PPP). It’s a basic authentication method where a user’s credentials, e.g., username and password, are sent over the network to a server (and in plaintext!), which then validates them.

No encryption. No added protection. Just raw, easy-to-read, credentials crossing the digital highway.

That’s right. In an era of zero trust, MFA, and hardened identity perimeters, PAP still relies on cleartext, which makes it more of a vulnerability than a safeguard.

PAP vs. CHAP: A tale of two handshakes

If PAP is the primitive wooden shield of authentication, then the Challenge Handshake Authentication Protocol (CHAP) is its slightly more battle-ready metal-clad cousin. Both belong in a different era of authentication, but one at least blocks a few more arrows.

Let’s break down the difference.

PAP is blunt. It sends a username and password across the wire in plain text, during the initial link establishment process, before a connection has been established. Think of it like shouting your credentials across a room and hoping no one notices. It trusts the environment far too much (no one else in the room or no one is paying attention to you shouting your dog’s name and birthdate), which is a risk that can’t be afforded in today’s attack landscape.

CHAP, on the other hand, introduces a handshake process: a basic challenge-response mechanism designed to reduce that exposure. Instead of sending the actual password, CHAP works like this:

1. The server sends a challenge (a random, meaningless value) to the client.
2. The client responds with a cryptographic hash with a combination of the challenge and the user’s password.
3. The server uses the stored password to perform the same hash calculation and compares the result to the client’s response. If they match, authentication is successful.

PAP starts at step two with the client sending the cleartext credentials which the server then checks for a match. With CHAP, the additional preceding step (labeled step one above), makes it possible for the actual password to be sent in a non-plaintext for, greatly reducing the attack risk from exposure of credentials.

Instead, a hashed version is transmitted using the challenge as a mutually-known secret. The hash is a one-way fingerprint of the combined password and randomly created challenge. That means attackers can’t easily intercept and reuse real credentials without knowing or figuring out the hash and challenge (which isn’t a bullet-proof security method on its own!).

This makes CHAP a safer alternative to PAP. It helps defend against common threats like replay attacks, where an attacker captures authentication data and tries to reuse it later to gain access. CHAP’s strength lies in its use of a unique challenge with every login attempt. Even if someone manages to capture the hashed response, it can’t be reused.

Rather than blindly accepting credentials, CHAP forces each login attempt to prove its validity in real time.

But don’t mistake “better than PAP” for “good enough.”

• CHAP still has weaknesses. It’s susceptible to dictionary attacks if the password is weak.
• It doesn’t provide mutual authentication and only the client is authenticated.
• It’s outdated and often unsupported in modern cloud-native architectures.
• And most importantly, it doesn’t meet modern compliance requirements for strong authentication.

CHAP was a step forward. But it’s still a step behind today’s needs.

So, while CHAP improved on PAP’s glaring issues, it’s not a destination. It’s a mile marker on the journey toward modern, robust CIAM.

Should you still use PAP?

In a word: no.

Here’s why:

• Security risks are inherent. Any interception of credentials in transit grants an attacker immediate access.
• It offers no defense against replay attacks, man-in-the-middle attacks, or credential theft.
• It doesn’t scale for cloud-native or multi-tenant environments, where stronger identity protocols are required by compliance standards.

Still using PAP? That’s a signal your authentication architecture is stuck in the past. And modern security teams are right to raise a red flag.

The real cost of legacy identity: Dev teams are paying for it

Here’s the kicker: developers are often left holding the bag when it comes to cleaning up legacy identity protocols like PAP. Whether it’s replacing outdated auth flows, responding to support tickets for user access issues, or maintaining fragile identity integrations, it’s the devs who suffer under the weight of technical debt.

And this work isn’t just a productivity tax, it’s a risk. When identity becomes a bottleneck, it slows feature velocity and weakens security posture.

Where Frontegg fits in: Stop doing identity the hard way

Frontegg exists to eliminate this exact kind of problem.

Our platform replaces outdated authentication methods (like PAP) with secure, standards-compliant alternatives that don’t require your engineers to reinvent the wheel. Here’s how we do it differently:

• Modern authentication: SSO, MFA, and token-based authentication out of the box.
• Low-code configuration: Admins and security teams can configure auth without needing a developer.
• Distributed ownership: Product, customer success, and infosec can self-manage access control, without filing a dev ticket.

Need to retire PAP? You shouldn’t have to code your way out of it.

The old way says: “Let’s ask the dev team to fix our outdated identity stack.” The Frontegg way says: “Let’s make identity self-service so devs can focus on what only they can do.”

We’re here to end the suffering caused by outdated protocols like PAP. It’s not just about updating your authentication layer. It’s about rewriting the rules of ownership and giving time back to the people building your product.