On Thu, Oct 18, 2012 at 9:47 PM, Nico Williams <[email protected]> wrote: > On Thu, Oct 18, 2012 at 8:36 PM, Nico Williams <[email protected]> wrote: >> On Thu, Oct 18, 2012 at 7:52 PM, Jeffrey Walton <[email protected]> wrote: >>> 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. > > I should have added that this sort of finding from a pen tester (or > any type of audit) is just that. You generally get to decide that you > don't need the missing feature (privacy prot. for the client ID) in > this or that case. > > That said, my advice would be to hash IDs if you can: it gets you a > modicum of privacy protection, and if it's cheap enough then > additional protection is worth having. > > Lack of client ID privacy protection can lead to some attacks such as > password guesses based on the ID or knowledge of the person that ID is > for. If you were working for a spy agency (say), you'd definitely > want priv. prot. for the client ID! > > So you get to decide what level of protection you want for the client ID: > > - none > - pseudonymous (hash the IDs) > - privacy protection relative to passive attackers (run over a TLS > channel with anon DH cipher suites) > - privacy protection relative to passive and active attackers (run > over a TLS channel with server cert) Thanks Nico. That sums it up nicely.
I think Hash(email) or a UID (rather than email address) is the best course of action. I will talk with the system's owner and present the choices. Jeff _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
