Re: [Cfrg] [saag] New draft: Hashed Password Exchange

Yaron Sheffer <yaronf.ietf@gmail.com> Wed, 08 February 2012 09:31 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA77E21F86EB for <cfrg@ietfa.amsl.com>; Wed, 8 Feb 2012 01:31:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.11
X-Spam-Level:
X-Spam-Status: No, score=-102.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99aJi4XmreMS for <cfrg@ietfa.amsl.com>; Wed, 8 Feb 2012 01:31:49 -0800 (PST)
Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6806621F86E4 for <cfrg@irtf.org>; Wed, 8 Feb 2012 01:31:49 -0800 (PST)
Received: by bkbzx1 with SMTP id zx1so349098bkb.13 for <cfrg@irtf.org>; Wed, 08 Feb 2012 01:31:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=OJ7KRZjQHQyNiU5kZdq7cHoc3px67h8zrszrx4GkEdg=; b=oJ8Q26/MpRi+Yr/R8huDQkqImVRVKEhe2SsxbUTsoUeIYWVI/vVdq8yeWwQSuSrGR4 eBRostFWUWSbI4BJj5g/CTeg7ZJ08jyZO/aZ4KFNUoStD+4Cs1UBZZM0Y3WQcfwWfj+Z IXJ8w4LVPQm4eHuPjkQVwZQ7Ja7GWjP0QSwMk=
Received: by 10.204.174.13 with SMTP id r13mr11793252bkz.122.1328693508373; Wed, 08 Feb 2012 01:31:48 -0800 (PST)
Received: from [10.0.0.6] (bzq-79-177-156-198.red.bezeqint.net. [79.177.156.198]) by mx.google.com with ESMTPS id d2sm2506863bky.11.2012.02.08.01.31.47 (version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 01:31:47 -0800 (PST)
Message-ID: <4F324101.6080202@gmail.com>
Date: Wed, 08 Feb 2012 11:31:45 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: cfrg@irtf.org
References: <mailman.99.1328299243.21949.cfrg@irtf.org>
In-Reply-To: <mailman.99.1328299243.21949.cfrg@irtf.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Cfrg] [saag] New draft: Hashed Password Exchange
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Feb 2012 09:31:50 -0000

Hi Steve,

to answer your parenthetical question, no, this scheme with a salt added 
would not fit well into IKEv2, because the user ID is sent along with 
the user-side authenticator. But then again, this scheme (with or 
without a salt) is not secure when used in IKEv2-PSK, for the same 
reasons that a plain password must not be used as an IKEv2 PSK, i.e. it 
is vulnerable to a dictionary attack by a MITM attacker.

Another alternative in IKEv2 is to use a password with one of the 
"secure EAP methods" listed in Sec. 4 of 
http://tools.ietf.org/html/rfc5998. These methods either use a long 
shared secret in lieu of a password, or are zero-knowledge password 
proof mechanisms. For the latter, storing a password hashed per your 
proposal may be valuable, and in fact a similar option is mentioned in 
http://tools.ietf.org/html/rfc6124#section-5.1.

Thanks,
	Yaron

>
> Message: 1
> Date: Thu, 2 Feb 2012 18:38:11 -0500
> From: Steven Bellovin<smb@cs.columbia.edu>
> To: Dan Harkins<dharkins@lounge.org>
> Cc: cfrg-bounces@irtf.org, "cfrg@irtf.org"<cfrg@irtf.org>
> Subject: Re: [Cfrg] ????: Re:  ????: Re:  [saag] New draft: Ha  shed
> 	Password Exchange
> Message-ID:<9E8EB80F-5D1E-4C68-8D52-4B2432DBF15D@cs.columbia.edu>
> Content-Type: text/plain; charset=iso-8859-1
>
> I'll be revising my draft soon.  For now, let me explain a few points.
>
> First -- the primary goal of the draft is avoiding storage of cleartext
> passwords, because even strong passwords are easily compromised if the
> device or server is hacked.  A second goal is to conceal that the same
> password is used for two different users or the same user on two different
> services.
>
> It's obviously true that attackers can still launch password-guessing attacks.
> This does increase their work factor.  While the difference in work factor
> may not be important for targeted attacks, it does help against broad-scale
> attacks: can any single password be retrieved?  The way I look at it is
> this: for a given effort, how many passwords can the attacker get?  If the
> iteration count is doubled, the yield per given effort is obviously halved.
>
> There are no large-scale precomputation attacks possible, because every
> hashed password is unique for a given<password,user,service>  triple.
>
> I do not see how a random salt would help at all -- it still requires
> about the same amount of computation per user per service per guess.
> The essential difference between a random salt and my scheme is that
> if I change my password to itself, with a random salt the hashed password
> would be different; with my scheme, it would be the same.  The attacker's
> effort would remain the same.  In addition, a random salt would hurt
> usability and/or security.  For the former, consider that I (and many
> other people) have many devices with stored passwords.  I personally
> use three or four computers and two iToys to read mail.  So -- I set a new
> password from one.  I now have to copy down that string and enter it
> on five other devices.  Not very user-friendly.  Assume, then, that
> the salt is sent as part of the protocol.  That not only hurts adoptability,
> since the protocol would now have to have a way to transmit it at the right
> point, after it knows the userid but before the authenticator is entered
> (quick -- what will that do to, say, IKEv2?), it means that the user's
> node would have to have the cleartext password available in order to
> hash it with the salt.  But that defeats the purpose of my scheme.
> HPW requires no changes to the protocol, and the only possible change
> to the implementation is a longer input buffer.
>
> Finally, I'm quite convinced that focusing on strong passwords is fighting
> the last war (and, I might add, a war we've lost).  *NO ONE* is using
> strong, unique, memorized passwords ubiquitously -- people have too many
> of them to remember.  By actual count, I have>100 web site passwords,
> plus login passwords, root passwords, mail passwords, ATM PINs, phone
> unlock codes, and more.  Sorry -- EBRAINFULL.  I think that far bigger
> dangers are password reuse and node compromise.  HPW is designed to deal
> with those threats.
>
> "In a world of smart cards, hand-held authenticators, and zero-
> knowledge proofs, it seems pointless to be worrying about poorly-
> chosen passwords.  Were the world like that, we might agree.  Today,
> it is not."  Mike Merritt and I wrote that about 20 years ago, in
> the original EKE paper.  Fortunately, passwords are no longer in use,
> since they've been replaced by better technology, right?  Oh, wait.
>
>