On Friday 19 Oct 2012 04:21:59 Jeffrey Walton wrote:
> On Thu, Oct 18, 2012 at 9:36 PM, Nico Williams <[email protected]> 
wrote:
> > On Thu, Oct 18, 2012 at 7:52 PM, Jeffrey Walton <[email protected]> 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:[email protected]>

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography

Reply via email to