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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 03 March 2009 18:19 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: saag@core3.amsl.com
Delivered-To: saag@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD13628C2B9 for <saag@core3.amsl.com>; Tue, 3 Mar 2009 10:19:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.099
X-Spam-Level:
X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZ7wyZAsa63Z for <saag@core3.amsl.com>; Tue, 3 Mar 2009 10:19:10 -0800 (PST)
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id C8C903A6C08 for <saag@ietf.org>; Tue, 3 Mar 2009 10:19:09 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id DEEAC1A6FE; Wed, 4 Mar 2009 07:19:33 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgs2Y+TaqYvI; Wed, 4 Mar 2009 07:19:33 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 745A919EA7; Wed, 4 Mar 2009 07:19:31 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id D049A1DE4001; Wed, 4 Mar 2009 07:19:30 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1LeZDG-0006FF-Os; Wed, 04 Mar 2009 07:19:30 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: ekr@networkresonance.com, pgut001@cs.auckland.ac.nz
In-Reply-To: <20090303175724.A169950822@romeo.rtfm.com>
Message-Id: <E1LeZDG-0006FF-Os@wintermute01.cs.auckland.ac.nz>
Sender: pgut001 <pgut001@cs.auckland.ac.nz>
Date: Wed, 04 Mar 2009 07:19:30 +1300
Cc: saag@ietf.org, mouse@Rodents-Montreal.ORG, Nicolas.Williams@sun.com
Subject: Re: [saag] SHA-1 to SHA-n transition
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2009 18:19:10 -0000

Eric Rescorla <ekr@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.