[cryptography] Secure Remote Password (SRP) and Plaintext Emil Address

Jeffrey Walton noloader at gmail.com
Thu Oct 18 22:40:16 EDT 2012


On Thu, Oct 18, 2012 at 9:47 PM, Nico Williams <nico at cryptonector.com> wrote:
> On Thu, Oct 18, 2012 at 8:36 PM, Nico Williams <nico at cryptonector.com> wrote:
>> On Thu, Oct 18, 2012 at 7:52 PM, Jeffrey Walton <noloader at gmail.com> 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



More information about the cryptography mailing list