Hi Nico,

thanks for your comments.

I agree several alternative authentication methods make sense, in addition to ZKPP. But for now, I'd rather concentrate on passwords since they make the most sense in the consumer context. If we do it right, we can migrate to PSK later on - if the user doesn't enter the password, they might as well use long binary strings. And maybe Kerberos as well.

But apparently I wasn't clear on the implementation, and that's a critical part. It looks like secure scripts are an impossibility right now (although people are trying: http://en.wikipedia.org/wiki/Caja_project" rel="nofollow">http://en.wikipedia.org/wiki/Caja_project). So I expect the browser internals to take care of authentication, with no scripting and no user interface involved. This is also why I'm avoiding the term "browser chrome" which smells of GUI: if you allow users into the loop, they will always make the rational decision and press Yes.

So here's my amended proposal again:

1. Users are authenticated to Facebook with a password, using a zero-knowledge password protocol (ZKPP), with authentication at the TLS or the HTTP layer.
2. In the future this can be extended to support other strong mutual auth schemes, like PSK or enterprise server+client certificates.
3. In any case, authentication is crypto-bound into the TLS-protected session (OK, let's assume Facebook sessions are TLS-protected...).
4. Passwords are stored in the browser's password manager. The browser doesn't "paste" the password into a form; rather, the browser only uses the password to run the client side of the ZKPP. This is done behind the scenes, the user doesn't get to see the plaintext password or even a row of asterisks. The browser implements ZKPP internally, with no scripts taking part in the process. In particular, browser-based scripts never get to see the password.
5. This is further hardened with an HSTS-like mechanism: only use this site if you can perform mutual authentication with it.
6. As a result of this scheme, users are trained *not* to enter their passwords explicitly, and will be suspicious when the see a "please enter your password" page. More importantly, they will have to work hard to get access to their password, which would discourage them from revealing the password to any arbitrary Web site.

Thanks,
    Yaron


On 06/12/2011 01:42 AM, Nico Williams wrote:

On Sat, Jun 11, 2011 at 10:08 AM, Yaron Sheffer <yaronf@gmx.com> wrote:

Let's assume the following:
1. Users are authenticated to Facebook with a password, using a
zero-knowledge password protocol (ZKPP), with authentication at the TLS or
the HTTP layer.

So, mutual authentication.  The specific mechanism doesn't matter, as
long as it gives us mutual authentication in a way such that it
doesn't suffer from the problems that the TLS server PKI does when it
comes to authenticating the service.

2. In any case, authentication is crypto-bound into the TLS-protected
session (OK, let's assume Facebook sessions are TLS-protected...).

So, channel binding.  (Because we're not going to throw away our
investment in TLS for transport protection, but we need to make sure
there's no MITM there.)

3. Passwords are stored in the browser's password manager. The browser
doesn't "paste" the password into a form; rather, the browser only releases
the password when going through the ZKPP. This is done behind the scenes,
the user doesn't get to see the plaintext password or even a row of
asterisks.

Browser chrome, a TCB.  What does "releases" here mean?  Does it give
the password plaintext to an untrusted script that implements the
ZKPP?

4. This is further hardened with an HSTS-like mechanism: only use this site
if you can perform mutual authentication with it.

Indeed!

5. Also, users are trained *not* to enter their passwords explicitly, and
will be suspicious when the see a "please enter your password" page.

Right: death to echo-off text input elements in HTML!

I suggest that this combination is well protected against phishing attacks,
without having to rely on trusted JavaScript code or on fancy user interface
elements.

This (mutual auth + channel binding) is pretty much what some of us
proposed at the W3C IDBROWSER workshop three weeks ago.  (Instead of a
ZKPP I propose we allow multiple different mechanisms, because there
are different mechanisms that people will want to use depending on the
context; Kerberos in the enterprise, GSS-EAP in the .edu cases and
many others, etcetera.)

But here's the gotcha: this can't be implemented in a script served by
the site, because there's no way to know what the script intends to do
with the password, and we haven't really authenticated the site yet,
and if you think the TLS server PKI is enough, then why ask for mutual
auth here?  We could add a script signing PKI, but chances are it'd
end up with the same faults as the TLS server PKI (namely: the CAs
don't have any responsibility to the RPs, the public at large).

This wouldn't eliminate all phishing attacks, but it would eliminate
the kinds of phishing attacks that involve theft of credential by
impersonating a service that a user wants to login to.  Well, assuming
the phisher can't trick the user into typing the password into an
echo-off (or simulated echo-off) prompt, which is why browser chrome
and things like SAS (secure attention sequence) matter, but still ,
we'd be making significant progress.

Nico
--