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

[Nicolas Williams <[e-mail]>]

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

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.

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

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

Nico
--