[cryptography] Secure Remote Password (SRP) and Plaintext Emil Address
nico at cryptonector.com
Thu Oct 18 21:36:39 EDT 2012
On Thu, Oct 18, 2012 at 7:52 PM, Jeffrey Walton <noloader at gmail.com> wrote:
> I have a Secure Remote Password (SRP) implementation that went through
> a pen test. The testers provided a critical finding - the email
> address was sent in the plaintext. Noe that plaintext email addresses
> are part of the protocol.
That's just how SRP and any ZKPP protocol must work. The shared
secret or verifier for it must be identified somehow, and this has to
be done before the client and server have exchanged session keys as
part of the ZKPP, and that identification can at best be only
Now, you *could* run SRP in a TLS (or equivalent) tunnel. Then you'd
get privacy protection for the *client* ID from passive attackers, and
if you authenticate the server as well (in TLS) then you get privacy
protection relative to active attackers.
But if you'd run SRP over TLS with TLS authenticating the server...
then why bother with SRP or any ZKPP?
Privacy protection for the client ID can be worked into a ZKPP in such
a way as to save round trips relative to running a plain ZKPP over
some other channel, but it will add a round trip relative to a plain
ZKPP, and there are UI considerations: how do we authenticate the
server?? with PKI? PKI will generally imply a fallback on those
pesky give-it-away dialogs.
> I'm not really convinced that using an email address in the plaintext
> for the SRP protocol is finding-worthy, considering email addresses
> are public information. And I'm very skeptical that its a critical
It... depends. If you need privacy protection for the client ID then
you need it, no? I can't tell you if you do. You must decide this.
For most applications I think privacy protection for the client ID is
not really necessary.
> With that said, what are the options here? I was thinking a simple
> mask function, which would remove the "plaintext-ness" (but not add
> any security to the system). Heuristically, masking the email address
> is *not* less secure than sending the email in the plaintext.
A "mask"? Sounds like security through obscurity. You could hash the
address, but that just gets you pseudonymity (at best: the attackers
could mount a dictionary attack to recover the address, and they can
trivially check if a hash corresponds to a given address).
More information about the cryptography