1
$\begingroup$

As far as I can tell from reading about SCRAM and OPAQUE is that Wikipedia puts both of them in the category of challenge-response authentication.

It's clear to me that SCRAM has an IETF RFC, whereas OPAQUE only has a draft.

However, what are some practical differences between them? For example, are both suitable for use in an SASL mechanism? What do each of them leak to the other party? What are their strengths and weaknesses?

$\endgroup$
5
$\begingroup$

The goal of SCRAM is to determine whether the two endpoints share a common secret. SCRAM achieves this by having both parties compare/exchange $\textrm{HMAC}(s,i)$ where $s$ is the secret and $i$ is a counter/nonce. There is more to it than this, but this is the main essence. If $s$ is a high-entropy cryptographic secret, then this is fine: seeing some HMAC outputs doesn't help an eavesdropper/impostor guess other HMAC outputs.

But if the shared secret is low-entropy like a password, I would say that SCRAM by itself is not suitable. The protocol transcript of a SCRAM interaction gives an eavesdropper enough information to test offline whether their guess for $s$ is correct. So SCRAM is susceptible to offline dictionary attacks. My understanding is that usually SCRAM is run inside of some encrypted tunnel, to protect from external eavesdroppers. But if I am a passive man-in-the-middle of that encrypted tunnel (which seems reasonable since there would be no need for SCRAM if we've already authenticated the endpoints!), I'll learn enough from the SCRAM transcript to allow offline dictionary attack.

SCRAM only does authentication, but OPAQUE is a full-fledged PAKE, which gives much more functionality:

  • key agreement: the endpoints establish a key in the presence of an eavesdropper, if their secrets match. Note that SCRAM uses a hash function (in HMAC) as its only cryptography. it is well known that secure key agreement is not possible from hash functions alone. This fact justifies why PAKEs are more expensive / use public-key crypto techniques.

  • designed for low-entropy secrets: a PAKE must resist offline dictionary attacks on the shared secret. The only way that an attacker can test a guess for $s$ is to interactively run the PAKE with one of the parties (online dictionary attack).

| improve this answer | |
$\endgroup$
  • $\begingroup$ Does this mean a PAKE like OPAQUE doesn't do anything if the server gets compromised (as this would give an attacker access to the password hashes anyway)? How do you keep the server from knowing the password while still being able to verify it? $\endgroup$ – SoniEx2 Jan 30 at 3:14
  • $\begingroup$ There are different variants of PAKE. In symmetric PAKE, both parties know the password in the clear. In asymmetric PAKE, one party just holds a "digest" of the password. OPAQUE is an asymmetric PAKE, so even after a server compromise it is necessary to mount a dictionary attack to recover passwords in the clear. $\endgroup$ – Mikero Jan 30 at 8:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.