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

From: Yaron Sheffer <[email-masked]>
Date: Sat, 11 Jun 2011 18:08:45 +0300

Hi Marsh,

a bit of a late response, but I'd like to offer that these two attacks 
could in fact have been countered by a combination of several ideas that 
we're already familiar with.

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.
2. In any case, authentication is crypto-bound into the TLS-protected 
session (OK, let's assume Facebook sessions are TLS-protected...).
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.
4. This is further hardened with an HSTS-like mechanism: only use this 
site if you can perform mutual authentication with it.
5. Also, users are trained *not* to enter their passwords explicitly, 
and will be suspicious when the see a "please enter your password" page.

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.

Thanks,
     Yaron

> From: Marsh Ray<[email-masked]>
> To: Nico Williams<[email-masked]>
> Cc: [email-masked]
> Subject: Re: [http-auth] [saag] re-call for IETF http-auth BoF
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 06/06/2011 04:44 PM, Nico Williams wrote:
>>   But I'm afraid
>> that the appearance of success will be enough to staunch progress in
>> any other areas, so it may be a now-or-never situation for any
>> alternatives other than JavaScript crypto APIs.
> Don't worry about it, they're not going to work even that well.
>
> They wouldn't have stopped the government of Tunisia from MitMing
> Facebook and inserting Javascript to modify the behavior of the page.
> They wouldn't have stopped the government of Syria from using a BlueCoat
> to perform SSL MitM on Facebook with a bogus self-signed cert either.
>
> Both governments were arresting and shooting their citizens and hacking
> their Facebook credentials. Interestingly, Tunisia controls a trusted
> root CA but didn't bother to use it. Syria doesn't control a widely
> trusted CA, but doesn't seem to need it either.
>
> Sooner or later, people will tire of security theater. We can just try
> to have the best options available when they do.
>
> - Marsh

---

From: Nico Williams <[email-masked]>
Date: Sat, 11 Jun 2011 17:42:05 -0500

On Sat, Jun 11, 2011 at 10:08 AM, Yaron Sheffer <[email-masked]> wrote:
> 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.

> 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.)

> 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
--

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 12 Jun 2011 09:50:17 +0300

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).
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:

Indeed!

Nico
--