On Thu, Oct 18, 2012 at 7:52 PM, Jeffrey Walton <[email protected]> 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 pseudonymous. 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 > finding. 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). Nico -- _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
