Re: [http-auth] Tunisian/Syrian phishing attacks
Yaron Sheffer <email@example.com> Sun, 12 June 2011 06:50 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98A01F0C45 for <firstname.lastname@example.org>; Sat, 11 Jun 2011 23:50:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-1.57 tagged_above=-999 required=5 tests=[AWL=-1.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MIME_HTML_ONLY=1.457]
Received: from mail.ietf.org ([126.96.36.199]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJphqnckGAyo for <email@example.com>; Sat, 11 Jun 2011 23:50:23 -0700 (PDT)
Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [188.8.131.52]) by ietfa.amsl.com (Postfix) with SMTP id A0A351F0C35 for <firstname.lastname@example.org>; Sat, 11 Jun 2011 23:50:22 -0700 (PDT)
Received: (qmail invoked by alias); 12 Jun 2011 06:50:20 -0000
Received: from bzq-79-178-38-173.red.bezeqint.net (EHLO [10.0.0.2]) [184.108.40.206] by mail.gmx.com (mp-eu004) with SMTP; 12 Jun 2011 08:50:20 +0200
X-Provags-ID: V01U2FsdGVkX1+DxYpde4aD7T2569ACvCqHCCMocZ/4hlNLFXN6dE rn5z03MxcRMSfR
Date: Sun, 12 Jun 2011 09:50:17 +0300
From: Yaron Sheffer <email@example.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10
To: Nico Williams <firstname.lastname@example.org>
References: <email@example.com> <4DF384FD.firstname.lastname@example.org> <BANLkTin3Me6DxH+nG8LX8wKTiA735tiwjQ@mail.gmail.com>
Content-Type: text/html; charset=UTF-8
Subject: Re: [http-auth] Tunisian/Syrian phishing attacks
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Jun 2011 06:50:24 -0000
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.
On 06/12/2011 01:42 AM, Nico Williams wrote: