TLS isn't up to the job without better credential protection, says RFC

As part of the long process to make the Internet more secure, user credentials need better protection than the transaction layer security (TLS) standard.

A new experimental-level, RFC-7804, proposes applying a 2010 protocol called SCRAM for the purpose.

While TLS protects plaintext passwords handed to servers over HTTPS, the RFC's author Alexey Melnikov (also a co-author of the previous RFC) wants to see it made more robust with a challenge-response mechanism.

There is one, the HTTP Digest challenge-response mechanism, but Melnikov says it “failed widespread deployment and has had only limited success”. That complexity made it hard to protect “the whole authentication exchange”, Melnikov writes, leaving some exchanges vulnerable to some man-in-the-middle attacks.

Enter SCRAM, the Salted Challenge Response Authentication Mechanism. Originally developed in 2010 as RFC-5802, Melnikov's current document describes how it could be added to HTTP exchanges.

One thing on Melnikov's mind is to avoid the kinds of breaches that have been all-too-common this decade: with salting added to the client-server exchange, he says SCRAM can prevent user impersonation resulting from leaked credentials.

The client/server process looks like this:

A similar process lets the server compute the proof it sends to the client.

For user convenience, HTTP SCRAM includes a mechanism for users to re-authenticate with a single round-trip. A nonce counts the number of times the user re-authenticates, and if the same value is presented for the nonce, the server can recognise it as a replay attack. ®