Re: [http-auth] Tunisian/Syrian phishing attacks

[Nico Williams <[e-mail]>]

On Sat, Jun 11, 2011 at 10:08 AM, Yaron Sheffer <[e-mail]> 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
--