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

Yaron Sheffer <> Wed, 08 February 2012 09:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA77E21F86EB for <>; Wed, 8 Feb 2012 01:31:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.11
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 99aJi4XmreMS for <>; Wed, 8 Feb 2012 01:31:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6806621F86E4 for <>; Wed, 8 Feb 2012 01:31:49 -0800 (PST)
Received: by bkbzx1 with SMTP id zx1so349098bkb.13 for <>; Wed, 08 Feb 2012 01:31:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id r13mr11793252bkz.122.1328693508373; Wed, 08 Feb 2012 01:31:48 -0800 (PST)
Received: from [] ( []) by with ESMTPS id d2sm2506863bky.11.2012. (version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 01:31:47 -0800 (PST)
Message-ID: <>
Date: Wed, 08 Feb 2012 11:31:45 +0200
From: Yaron Sheffer <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Cfrg] [saag] New draft: Hashed Password Exchange
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 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


> Message: 1
> Date: Thu, 2 Feb 2012 18:38:11 -0500
> From: Steven Bellovin<>
> To: Dan Harkins<>
> Cc:, ""<>
> Subject: Re: [Cfrg] ????: Re:  ????: Re:  [saag] New draft: Ha  shed
> 	Password Exchange
> Message-ID:<>
> 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.