Re: [saag] SHA-1 to SHA-n transition

[Eric Rescorla <ekr at networkresonance.com>]

At Mon, 2 Mar 2009 11:11:22 -0600,
Nicolas Williams wrote:
> 
> On Mon, Mar 02, 2009 at 09:21:35AM -0800, Eric Rescorla wrote:
> > At Mon, 2 Mar 2009 10:11:35 -0600,
> > Nicolas Williams wrote:
> > > In my scheme (b) is solved by letting apps prompt for identities,
> > > but not any passwords -- and training users not to enter passwords into
> > > non-secure dialogs (see SAS comment) -- and by having authentication
> > > mechanisms where the relying party does not get to impersonate the
> > > client just because the client authenticated itself (this, in turn,
> > > creates another problem in that lots of web services need delegation).
> > > 
> > > In particular I think the solution to (b) needs to go hand-in-hand with
> > > any solution to the mutual authentication problem.
> > 
> > I would characterize this as handwaving. 
> > 
> > As long as the user's credential provided to their client is a human
n> > readable password (and I think that's pretty clearly an invariant in a
> > large number of cases), then you have to worry about the user being
> > conned into typing their password into a dialog box controlled by the
> > attacker. Seeing as the available evidence suggests that there is
> > almost no UI chrome that can stop them from doing so, even when the
> > attacker only controls the ordinary browser interface.
> 
> It will be a long time before users can be trained not to type passwords
> into attacker-controlled dialogs -- that is definitely true.  And we'll
> also have passwords for a long time yet.  These are not reasons to throw
> our hands up and give up.
> 
> Deploy mutual authentication schemes first, then train users; training
> users first won't do since there's no way for the UI to distinguish
> password dialogs for web applications, since there's no mechanism other
> than sending the password in an HTML form.
> 
> DIGEST-MD5 exists, and I'd advocate its use, but currently that always
> results in a browser-controlled dialog that app designers hate (or, if
> you use XmlHttpRequest then the application can prompt for the password
> in a form and then use DIGEST-MD5 without a browser dialog, but this is
> still an attacker-controlled form).  The change that would make
> DIGEST-MD5 and friends more acceptable is to let the app provide a form
> where the user fills in a username, and then let the browser prompt for
> the password if it doesn't already have it.

And the attacker will just pop up a dialog that says "our cool new UI
system is broken. Type your password into the form for now." This is
quite clear from [SDO+07].


> That's not handwaving -- there are specific details here.  That it will
> take time to get there is not handwaving for that will be true of any
> solutions.

Except that you're handwaving about the UI, which is the critical
part that we have no idea how to solve. We already have plenty of
cryptographic protocols here. What we don't have is the UI. So,
no, I don't think it's particularly useful to put a new coat of paint
on the crypto.


> > Sure, you can imagine training users not to do that, but since
> > there's no evidence that you can in fact do so, that seems fairly
> > speculative.
> 
> Any solution will require training, if nothing else because otherwise
> everyone will continue doing what we all do today: typing passwords into
> HTML forms, so that servers get cleartext passwords, and MITMs get all
> our money.

"We must do something. This is something. We must do this."


> > P.S. I don't see how SAS is at all relevant here. SAS depends on the existence
> > of a trusted channel to carry the SAS, and that's precisely what we don't
> > have.
> 
> That's precisely what using a mutual authentication mechanism adds: a
> trusted channel.  Now, mechanism strength will vary, and use of weak
> passwords with mechanisms that don't do well when used with weak
> passwords is a problem, but I'd much rather have that problem to worry
> about than the current one.

Huh? If you already ahve mutual authentication, you don't need an SAS.
An SAS is about establishing a cryptographically trusted channel
from a low bandwidth non-cryptographic channel.

-Ekr


[SDO+07] S. Schechter, R. Dhajima, A. Ozment, I. Fischer, 
"The Emperor's New Security Indicators: An evaluation of website authentication
and the effect of role playing on usability studies", IEEE Oakland 2007.