Subject: [http-auth] Zero-Knowledge Password Proof Migration [was Re: Anyone on mailing list working for browser vendor]

From: Cameron Jones <[email-masked]>
Date: Wed, 6 Feb 2013 16:42:56 +0000

Branching to new topic.

On Wed, Feb 6, 2013 at 1:18 PM, Cameron Jones <[email-masked]> wrote:

> On Tue, Feb 5, 2013 at 10:26 PM, Stephen Farrell <
> [email-masked]> wrote:
>
>>
>> Hi Cameron,
>>
>> On 02/05/2013 06:40 PM, Cameron Jones wrote:
>> > I think largely what is in demand, based on other input to the HTML
>> group,
>> > is a SRP-style protocol to protect against server password leaks.
>>
>> I don't think that works quite as you stated above.
>>
>> Passwords leak from databases or keyboards and not via sniffing in
>> afaik pretty much all cases and strong password protocols still
>> have dictionary attackable password verifier databases.
>>
>> There may still be good reasons to use a strong password protocol
>> like SRP or EKE or whatever of course and I've nothing against
>> 'em, (some are really elegant), but we'd want to be clear about
>> what problems they do and don't address.
>>
>> But that's getting ahead of ourselves probably.
>>
>> S.
>>
>>
> Hey Stephen,
>
> Yes, I wasn't trying to overstate a demand for SRP or other zero-knowledge
> password protocols above all else, more that there was a vocal demand for
> such. The requests were triggered by the various unsalted password database
> leaks\hack & grabs last year.
>
> Personally i too find the mechanism elegant and potentially highly
> valuable for some scenarios, but the migration for existing
> password-knowledgable systems seems to be a significant hurdle in achieving
> that utopian ideal.
>
>
>

With a bit more thinking, and not being a cryptography expert, but would it
be possible to employ SRP-style algorithm for the user on the server-side
both for password migration and legacy scheme support?

So, standard SRP would work as normal, but legacy schemes (such as BASIC),
would have raw passwords SRP applied on the server-side for authorization
and storage?

The benefits to service providers of all this is that they would eliminate
their risk from password harvesters since the only useful information they
would store would be that which relates to their own service, instead of
being a point-of-failure for any email\password combination. SRP, if
achievable, would largely eliminate the need for people to have multiple
passwords.

Thanks,
Cameron Jones

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 Feb 2013 12:05:37 -0500

On Wed, Feb 6, 2013 at 11:42 AM, Cameron Jones <[email-masked]> wrote:

>> Yes, I wasn't trying to overstate a demand for SRP or other
>> zero-knowledge password protocols above all else, more that there was a
>> vocal demand for such. The requests were triggered by the various unsalted
>> password database leaks\hack & grabs last year.
>>
> With a bit more thinking, and not being a cryptography expert, but would
> it be possible to employ SRP-style algorithm for the user on the
> server-side both for password migration and legacy scheme support?
>

The big problem to avoid is the downgrade attack.

Digest was originally proposed to replace BASIC. It was a mistake that
should never have made it into the spec in my view and it would not have
made it into the spec had we actually had a conversation about it first.

That didn't happen and so DIGEST only got implemented three years later as
a checkbox requirement to get HTTP/1.1 approved. Every implementation
presents the same UI dialog for BASIC and DIGESt. This means there is no
additional security against a MITM attack as a malicious party can always
ask for the password using BASIC and the client has no way to know that it
should not sent the password enclair.

We should definitely look at the better password exchange schemes like EKE
which are not encumbered. That would be a much better approach in my view
than trying to patch DIGEST which was designed when DH was still encumbered
and is only designed to limit the consequences of stupidity as far as was
possible on the equipment of the day rather than eliminate all possible
forms of attack.

But there is no point in doing that either unless the downgrade attack
issue is also dealt with.

-- 
Website: http://hallambaker.com/

---

From: "Ahrens, David (David)" <[email-masked]>
Date: Wed, 6 Feb 2013 17:15:34 +0000

SIP (RFC 3261) doesn't allow Basic and only support Digest authentication so there's still a requirement for Digest authentication.

-David

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Wednesday, February 06, 2013 9:06 AM
To: Cameron Jones
Cc: [email-masked]
Subject: Re: [http-auth] Zero-Knowledge Password Proof Migration [was Re: Anyone on mailing list working for browser vendor]

On Wed, Feb 6, 2013 at 11:42 AM, Cameron Jones <[email-masked]<mailto:[email-masked]>> wrote:
Branching to new topic.

On Wed, Feb 6, 2013 at 1:18 PM, Cameron Jones <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Feb 5, 2013 at 10:26 PM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:

Hi Cameron,

On 02/05/2013 06:40 PM, Cameron Jones wrote:
> I think largely what is in demand, based on other input to the HTML group,

S.

Hey Stephen,

Yes, I wasn't trying to overstate a demand for SRP or other zero-knowledge password protocols above all else, more that there was a vocal demand for such. The requests were triggered by the various unsalted password database leaks\hack & grabs last year.

Personally i too find the mechanism elegant and potentially highly valuable for some scenarios, but the migration for existing password-knowledgable systems seems to be a significant hurdle in achieving that utopian ideal.

With a bit more thinking, and not being a cryptography expert, but would it be possible to employ SRP-style algorithm for the user on the server-side both for password migration and legacy scheme support?

So, standard SRP would work as normal, but legacy schemes (such as BASIC), would have raw passwords SRP applied on the server-side for authorization and storage?

The benefits to service providers of all this is that they would eliminate their risk from password harvesters since the only useful information they would store would be that which relates to their own service, instead of being a point-of-failure for any email\password combination. SRP, if achievable, would largely eliminate the need for people to have multiple passwords.

Thanks,
Cameron Jones

Digest was originally proposed to replace BASIC. It was a mistake that should never have made it into the spec in my view and it would not have made it into the spec had we actually had a conversation about it first.

That didn't happen and so DIGEST only got implemented three years later as a checkbox requirement to get HTTP/1.1 approved. Every implementation presents the same UI dialog for BASIC and DIGESt. This means there is no additional security against a MITM attack as a malicious party can always ask for the password using BASIC and the client has no way to know that it should not sent the password enclair.

We should definitely look at the better password exchange schemes like EKE which are not encumbered. That would be a much better approach in my view than trying to patch DIGEST which was designed when DH was still encumbered and is only designed to limit the consequences of stupidity as far as was possible on the equipment of the day rather than eliminate all possible forms of attack.

But there is no point in doing that either unless the downgrade attack issue is also dealt with.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 06 Feb 2013 19:35:20 +0200

Hi Phillip,

we do have one more weapon today: HSTS can be used/modified to eliminate 
*some* of this issue. The first time I authenticate to www.example.com I 
get back a HTTP header that specifies that I should never use Basic or 
Digest with this domain, only SRP (or EKE or whatever).

And to answer Cameron's question: unfortunately SRP password databases 
are as vulnerable to password guessing attacks as other password 
databases. Not the cleartext ones (whose admins should be taken out and 
shot) but the salted databases.

Thanks,
	Yaron

On 02/06/2013 07:05 PM, Phillip Hallam-Baker wrote:
>         On Tue, Feb 5, 2013 at 10:26 PM, Stephen Farrell
>         <[email-masked] <mailto:[email-masked]>>
>         wrote:
>
>
>             Hi Cameron,
>
>         zero-knowledge password protocols above all else, more that
>         there was a vocal demand for such. The requests were triggered
>         by the various unsalted password database leaks\hack & grabs
>         last year.
>
>         Personally i too find the mechanism elegant and potentially
>         highly valuable for some scenarios, but the migration for
>         existing password-knowledgable systems seems to be a significant
>         hurdle in achieving that utopian ideal.
>
>
>
>
>     With a bit more thinking, and not being a cryptography expert, but
>     would it be possible to employ SRP-style algorithm for the user on
>     the server-side both for password migration and legacy scheme support?
>
>     So, standard SRP would work as normal, but legacy schemes (such as
>     BASIC), would have raw passwords SRP applied on the server-side for
>     authorization and storage?
>
>     The benefits to service providers of all this is that they would
>     eliminate their risk from password harvesters since the only useful
>     information they would store would be that which relates to their
>     own service, instead of being a point-of-failure for any
>     email\password combination. SRP, if achievable, would largely
>     eliminate the need for people to have multiple passwords.
>
>     Thanks,
>     Cameron Jones
>
>
> That didn't happen and so DIGEST only got implemented three years later
> as a checkbox requirement to get HTTP/1.1 approved. Every implementation
> additional security against a MITM attack as a malicious party can
> always ask for the password using BASIC and the client has no way to
> know that it should not sent the password enclair.
>
>
> We should definitely look at the better password exchange schemes like
> EKE which are not encumbered. That would be a much better approach in my
> view than trying to patch DIGEST which was designed when DH was still
> encumbered and is only designed to limit the consequences of stupidity
> as far as was possible on the equipment of the day rather than eliminate
> all possible forms of attack.
>
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 Feb 2013 12:40:42 -0500

There is certainly a need for out of band policy signalling.

What I would like to see is the ability to signal the policy in either the
HTTP header (for secure after first contact) and through a DNSSEC protected
DNS record (for secure on first contact).

So I see two separate questions

1) What is the information to be signaled?
2) What mechanisms are to be used to publish the information?

The first would be a combination of the HTTP AUTH group and WebSEC. The
second would be a WebSec thing and a DNS thing. Since DNSEXT is closed that
should probably be an Apps area discussion.

On Wed, Feb 6, 2013 at 12:35 PM, Yaron Sheffer <[email-masked]>wrote:

> And to answer Cameron's question: unfortunately SRP password databases are
> as vulnerable to password guessing attacks as other password databases. Not
> the cleartext ones (whose admins should be taken out and shot) but the
> salted databases.
>
> Thanks,
>         Yaron
>
>
>>         <[email-masked] <mailto:stephen.farrell@cs.**tcd.ie<[email-masked]>
>> >>
>>
>>         wrote:
>>
>>
>>             Hi Cameron,
>>
>> ______________________________**_________________
>> http-auth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/http-auth<https://www.ietf.org/mailman/listinfo/http-auth>
>>
>>

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Feb 2013 11:52:55 -0600

EKE leaks password information because DH public keys contain some
structure (all DH and ECDH.groups feature this problem, with the amount of
structure varying by group), usually a few bits with not fixed but probable
values, which allows off-line attackers to eliminate 2^(that many bits)
passwords from the password dictionary search space.

Use PACE, J-PAKE, SRP -, any other unencumbered ZKPP protocol known to not
suffer from this problem.

Nico
--

On Feb 6, 2013 12:05 PM, "Phillip Hallam-Baker" <[email-masked]> wrote:

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Feb 2013 11:53:35 -0600

Nico
--

---

From: Cameron Jones <[email-masked]>
Date: Wed, 6 Feb 2013 18:13:57 +0000

> the cleartext ones (whose admins should be taken out and shot) but the
Ahh thanks, i see that now. It is no magic bullet.

Thanks,
Cameron Jones