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

2012-10-19 Thread Tim Brown
On Friday 19 Oct 2012 04:21:59 Jeffrey Walton wrote:
 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).

Speaking purely for myself (but as a UK pentester).  A pentest doesn't tell 
you what you *must* fix, it simply highlights places that might be leveraged by 
an attacker.  Pentesters don't own the risk.  It is up to the owner to employ 
a suitable risk management process and determine whether it is some that must 
be fixed, something that can be granted some kind of temporary waiver or 
something that can simply be documented as accepted.

As an aside unless you have explicitly asked for it, it's unlikely that the 
pentest is going to be alligned against any particular UK data security 
requirements.  (I'm don't even think there are any that are relevant in this 
context - unless maybe there is more that you're not saying.)

Tim
PS If this is considered off-topic feel free to discuss it with me off list.
-- 
Tim Brown
mailto:t...@65535.com


signature.asc
Description: This is a digitally signed message part.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


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

2012-10-19 Thread Jim Fenton
On 10/18/12 11:45 PM, James A. Donald wrote:
 On 2012-10-19 11:47 AM, Nico Williams wrote:
 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!

 If the attacker knows the email address, can identify the user - who
 is very likely using the same password for his porn account, etc.
 Attacker intercepts porn account using firesheep, and ... he is in.

That problem isn't limited to use of email address as an identifier.
People like to use the same identifiers (if they can get them), even if
they're not email addresses, in multiple places. If you're concerned
about identifier confidentiality or ability of sites to collude, you
probably need to be thinking about protocols that have directed identity
(unique identifier per site) properties.

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


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

2012-10-18 Thread Jeffrey Walton
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

2012-10-18 Thread James A. Donald

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

2012-10-18 Thread Jeffrey Walton
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

2012-10-18 Thread Nico Williams
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

2012-10-18 Thread Nico Williams
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

2012-10-18 Thread Jeffrey Walton
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

2012-10-18 Thread Jeffrey Walton
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

2012-10-18 Thread Nico Williams
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