[cryptography] Secure Remote Password (SRP) and Plaintext Emil Address
Hi All, 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. 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. 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. Any ideas? Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Secure Remote Password (SRP) and Plaintext Emil Address
On 2012-10-19 10:52 AM, Jeffrey Walton wrote: Hi All, 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. 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. 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. Any ideas? Jeff ___ Please describe protocol I conjecture that it works as username and password, and the email addresses are the username. If so, why not make a one way hash of the email address the username, rather than the plaintext email address? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Secure Remote Password (SRP) and Plaintext Emil Address
On Thu, Oct 18, 2012 at 9:03 PM, James A. Donald jam...@echeque.com wrote:
On 2012-10-19 10:52 AM, Jeffrey Walton wrote:
Hi All,
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.
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.
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.
Any ideas?
Please describe protocol
With lots of hand waiving, SRP is a PAKE that utilizes Diffie-Hellman.
Rather than g^ab, SRP uses g^password, plus random values from client
and server for each instance of the protocol. On the server, the
server stores a {email, salt, Hash(password)} tuple - it looks a lot
like a Unix password file.
The IETF specifications are available at
http://www.ietf.org/rfc/rfc2945.txt (SRP-3) and
http://tools.ietf.org/rfc/rfc5054.txt (SRP-6). SRP-3 is similar to
Thomas Wu's original specification while at Stanford. SRP-6 is
hammering SRP into the SSL/TLS hole.
I conjecture that it works as username and password, and the email addresses
are the username. If so, why not make a one way hash of the email address
the username, rather than the plaintext email address?
Yes, your intuition is correct.
Jeff
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Secure Remote Password (SRP) and Plaintext Emil Address
On Thu, Oct 18, 2012 at 7:52 PM, Jeffrey Walton noloa...@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 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 cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Secure Remote Password (SRP) and Plaintext Emil Address
On Thu, Oct 18, 2012 at 8:36 PM, Nico Williams n...@cryptonector.com wrote: On Thu, Oct 18, 2012 at 7:52 PM, Jeffrey Walton noloa...@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) Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Secure Remote Password (SRP) and Plaintext Emil Address
On Thu, Oct 18, 2012 at 9:47 PM, Nico Williams n...@cryptonector.com wrote: On Thu, Oct 18, 2012 at 8:36 PM, Nico Williams n...@cryptonector.com wrote: On Thu, Oct 18, 2012 at 7:52 PM, Jeffrey Walton noloa...@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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Secure Remote Password (SRP) and Plaintext Emil Address
On Thu, Oct 18, 2012 at 9:36 PM, Nico Williams n...@cryptonector.com wrote: On Thu, Oct 18, 2012 at 7:52 PM, Jeffrey Walton noloa...@gmail.com wrote: [SNIP] 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. Its probably worth mentioning The organization is from the UK, and the penetration testing firm is from the UK. I'm US based, and it could be the case that I am ignorant to UK data security requirements. I attempted to get a copy of the standard used (with no joy). Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Secure Remote Password (SRP) and Plaintext Emil Address
On Thu, Oct 18, 2012 at 9:40 PM, Jeffrey Walton noloa...@gmail.com wrote: I think Hash(email) or a UID (rather than email address) is the best course of action. UID doesn't work: the user must then remember it, and you don't want to burden them with that :( Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
