[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Eric Rescorla <ekr at networkresonance.com> writes:

>While I think this general class of solutions has some utility, but the
>difficulty is that it requires some UI mechanism to stop the phisher from
>convincing the user to type their password into a dialog which goes directly
>to the phisher rather than being hashed.

Uhh, read my original message again, it doesn't matter if the phisher gets the
password or not (obviously it'd be better if they didn't, but if they do then
it's not serious because they still need to get the 128-bit salt, and the only
way to get that is via malware on the victim's PC at which point any measure
at all is going to fail).  That's the beauty of it, as Jeff pointed out you're
never going to stop users from giving out their password to anything that asks
for it so the solution is to create a mechanism where this isn't an issue any
more.  OTPs are one example of this, but that one's a lot more work than a
simple password diversifier.

(There's a whole pile of other problems that this addresses as well, for
example the user only has to remember a single password, recovery can be
handled via standard backup mechanisms like the Windows password reset disk
(PRD) via DPAPI, and so on.  The full run-down gets quite complicated because
there's a pile of carry-on effects that address a lot of other problems with
password-based authentication).

Peter.

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.