Re: [Cfrg] 答复: Re: ´ð¸´: Re: ´ð¸´: Re: [saag] New draft: Ha shed Password Exchange

Steven Bellovin <smb@cs.columbia.edu> Thu, 09 February 2012 12:32 UTC

Return-Path: <smb@cs.columbia.edu>
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 1E24621F8713 for <cfrg@ietfa.amsl.com>; Thu, 9 Feb 2012 04:32:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.821
X-Spam-Level:
X-Spam-Status: No, score=-3.821 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152]
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 4YKGmklCzqTu for <cfrg@ietfa.amsl.com>; Thu, 9 Feb 2012 04:32:11 -0800 (PST)
Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id DA38721F8703 for <cfrg@irtf.org>; Thu, 9 Feb 2012 04:32:10 -0800 (PST)
Received: from [192.168.2.47] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q19CW7jo008340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 9 Feb 2012 07:32:08 -0500 (EST)
References: <OF46D248F8.9BF13ADC-ON4825799F.00352221-4825799F.003600CD@zte.com.cn>
In-Reply-To: <OF46D248F8.9BF13ADC-ON4825799F.00352221-4825799F.003600CD@zte.com.cn>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary=Apple-Mail-B10CD237-99BA-480B-8D4A-4C9293C497F9
Message-Id: <B8C46953-151F-4EE4-B1C3-B7A5C6C535FC@cs.columbia.edu>
X-Mailer: iPad Mail (9A405)
From: Steven Bellovin <smb@cs.columbia.edu>
Date: Thu, 9 Feb 2012 07:32:07 -0500
To: "zhou.sujing@zte.com.cn" <zhou.sujing@zte.com.cn>
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] =?utf-8?b?562U5aSNOiBSZTogIMK0w7DCuMK0OiBSZTogIMK0w7DCuMK0?= =?utf-8?q?=3A_Re=3A__=5Bsaag=5D_New_draft=3A_Ha__shed_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: Thu, 09 Feb 2012 12:32:13 -0000

I dealt with that in my note: how do you deal with multiple devices?

Sent from my iPad

On Feb 9, 2012, at 4:49 AM, zhou.sujing@zte.com.cn wrote:

> 
> I understand the aim of your proposal, and similar ideas have also been proposed, such as pwdhash by Standford university, 
> a only  simple hash before sending passwoed can prevent more security loss when a server is broken, because it is human's weakness to have only a few sets of passwords, 
> even worse, the few passwords are often randomless for memory easiness. 
> 
> But only hashing password will not increase entropy, maybe an option can be added to your scheme that 
> another long and random key K can be stored exclusively in the user's device, 
> and the effective password equals hash of <password,user,service> and K? 
> 
> 
> 
> 
> Regards~~~
> 
> -Sujing Zhou 
> 
> Steven Bellovin <smb@cs.columbia.edu> 写于 2012-02-03 07:38:11:
> 
> > 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.
> > 
> > 
> > 
> > On Feb 2, 2012, at 1:46 PM, Dan Harkins wrote:
> > 
> > > 
> > >  The issue is that hashing a password doesn't make it "random"
> > > (while it might make it "long"). So no, an ordinary hash is not
> > > enough. As I suggested, I think a non-secret salt exchanged in
> > > the protocol can be used as a key to a HMAC and the password can
> > > be included in the data to be HMAC'd.
> > > 
> > >  Dan.
> > > 
> > > On Wed, February 1, 2012 5:22 pm, zhou.sujing@zte.com.cn wrote:
> > >> Well£¬ it is the requirement of the HMAC for key being long and random.
> > >> Then in the case of the draft, ordinary hash is enough I guess?
> > >> 
> > >> 
> > >> Regards~~~
> > >> 
> > >> 
> > >> cfrg-bounces@irtf.org дÓÚ 2012-02-01 23:49:13:
> > >> 
> > >>> My take on this is: if you believe that a hash-function is a good
> > >>> randomizer and can be used in cryptographic key generation process ¨C
> > >>> then  it does not matter whether what you feed as a "key" input to
> > >>> HMAC is uniformly distributed or not (because of HMAC internal "hash
> > >>> spins"). And if you are uneasy on how really random your hash output
> > >>> is ¨C then a lot of the currently used mechanisms and primitives need
> > >>> revisiting.
> > >>> --
> > >>> Regards,
> > >>> Uri Blumenthal                            Voice: (781) 981-1638
> > >>> Cyber Systems and Technology  Fax:    (781) 981-0186
> > >>> MIT Lincoln Laboratory
> > >>> 
> > >>> From: "zhou.sujing@zte.com.cn" <zhou.sujing@zte.com.cn>
> > >>> Date: Wed, 1 Feb 2012 03:13:07 -0500
> > >>> To: Dan Harkins <dharkins@lounge.org>
> > >>> Cc: "cfrg@irtf.org" <cfrg@irtf.org>rg>, Steven Bellovin
> > >> <smb@cs.columbia.edu>
> > >>> Subject: [Cfrg] ´ð¸´: Re: [saag] New draft: Hashed Password Exchange
> > >>> 
> > >>> 
> > >>> Hi,all
> > >>> 
> > >>> cfrg-bounces@irtf.org дÓÚ 2012-01-07 17:03:25:
> > >>> 
> > >>>> 
> > >>>> 
> > >>>> On Wed, January 4, 2012 2:56 pm, Steven Bellovin wrote:
> > >>>>> Good point; let me think about it for -01.  An obvious solution is
> > >> to send
> > >>>>> the hostname with the effective password.
> > >>>> 
> > >>>>  How is that different than using random salt then? If _something_
> > >>> is
> > >>>> going to be sent shouldn't it be a uniformly random bitstring instead
> > >> of
> > >>>> a hostname?
> > >>>> 
> > >>>>  A uniformly random bitstring would be more appropriate as a key to
> > >>>> HMAC than a highly structured string like a password too. Iterate
> > >>>> HMAC(salt, password | service-URI) instead of HMAC(password,
> > >> service-URI).
> > >>> 
> > >>> 
> > >>> 
> > >>> I think Dan's suggestion is reasonable, I checked the RFC 2104 and
> > >>> found the following section :
> > >>> 
> > >>> "3. Keys
> > >>> 
> > >>>   The key for HMAC can be of any length (keys longer than B bytes are
> > >>>   first hashed using H).  However, less than L bytes is strongly
> > >>>   discouraged as it would decrease the security strength of the
> > >>>   function.  Keys longer than L bytes are acceptable but the extra
> > >>>   length would not significantly increase the function strength. (A
> > >>>   longer key may be advisable if the randomness of the key is
> > >>>   considered weak.)
> > >>> 
> > >>>   Keys need to be chosen at random (or using a cryptographically
> > >>> strong
> > >>>   pseudo-random generator seeded with a random seed), and periodically
> > >>>   refreshed.  (Current attacks do not indicate a specific recommended
> > >>>   frequency for key changes as these attacks are practically
> > >>>   infeasible.  However, periodic key refreshment is a fundamental
> > >>>   security practice that helps against potential weaknesses of the
> > >>>   function and keys, and limits the damage of an exposed key.)"
> > >>> 
> > >>> 
> > >>> Since passwords are often not too long, and not so random, it is better
> > >>> to hash it before using it as a key in a HMAC.
> > >>> 
> > >>> 
> > >>> Regards~~~
> > >>> 
> > >>> -Sujing Zhou
> > >>>> 
> > >>>>  That said, goal 4 in the draft-- "By iterating a sufficient number
> > >> of
> > >>>> times, dictionary attacks can be made arbitrarily expensive"-- seems
> > >>> a
> > >>>> bit misguided. The Amazon cloud service has been used to launch an
> > >>>> off-line dictionary attack against the WPA-PSK protocol which uses
> > >> PBKDF2
> > >>>> (HMAC-SHA1) with 4096 iterations to obfuscate a password. This attack
> > >>>> checks 24,000,000 candidate passwords per minute at a cost of $0.28.
> > >>>> That's more than 1,600,000,000 iterations per second for about 1/2 a
> > >> cent.
> > >>>> So I don't think increased iteration makes dictionary attacks much
> > >> more
> > >>>> expensive.
> > >>>> 
> > >>>>  Which begs the question, how is this proposal different than
> > >>> PBKDF2?
> > >>>> That the "salt" is a service URI?
> > >>>> 
> > >>>>  regards,
> > >>>> 
> > >>>>  Dan.
> > >>>> 
> > >>>>> On Jan 4, 2012, at 5:21 01PM, Joe Touch wrote:
> > >>>>> 
> > >>>>>> Hi, Steve,
> > >>>>>> 
> > >>>>>> This doc doesn't appear to address the case where a host has
> > >> multiple
> > >>>>>> DNS names, which could make it difficult to incorporate the
> > >> hostname
> > >>>>>> into the transform. I.e., I could contact a mail server at an IP
> > >> address
> > >>>>>> that represents any of dozens of DNS names - how does the server
> > >> know
> > >>>>>> which one I used so it can match without exhaustively trying all
> > >> its
> > >>>>>> equivalent names?
> > >>>>>> 
> > >>>>>> Joe
> > >>>>>> 
> > >>>>>> On 1/4/2012 1:41 PM, Steven Bellovin wrote:
> > >>>>>>> I'd appreciate comments on my new draft,
> > >> draft-bellovin-hpw-00.txt:
> > >>>>>>> 
> > >>>>>>> Abstract
> > >>>>>>> 
> > >>>>>>>   Many systems (e.g., cryptographic protocols relying on
> > >> symmetric
> > >>>>>>>   cryptography) require that plaintext passwords be stored. Given
> > >> how
> > >>>>>>>   often people reuse passwords on different systems, this poses a
> > >> very
> > >>>>>>>   serious risk if a single machine is compromised.  We propose a
> > >>>>>>> scheme
> > >>>>>>>   to derive passwords limited to a single machine from a typed
> > >>>>>>>   password, and explain how a protocol definition can specify
> > >> this
> > >>>>>>>   scheme.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>>      --Steve Bellovin, https://www.cs.columbia.edu/~smb
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> _______________________________________________
> > >>>>>>> saag mailing list
> > >>>>>>> saag@ietf.org
> > >>>>>>> https://www.ietf.org/mailman/listinfo/saag
> > >>>>>> 
> > >>>>> 
> > >>>>> 
> > >>>>>      --Steve Bellovin, https://www.cs.columbia.edu/~smb
> > >>>>> 
> > >>>>> 
> > >>>>> 
> > >>>>> 
> > >>>>> 
> > >>>>> _______________________________________________
> > >>>>> saag mailing list
> > >>>>> saag@ietf.org
> > >>>>> https://www.ietf.org/mailman/listinfo/saag
> > >>>>> 
> > >>>> 
> > >>>> 
> > >>>> _______________________________________________
> > >>>> Cfrg mailing list
> > >>>> Cfrg@irtf.org
> > >>>> http://www.irtf.org/mailman/listinfo/cfrg
> > >>>> [¸½¼þ "smime.p7s" ±» ÖÜËÕ¾²00132831/user/zte_ltd ɾ³ý]
> > >>> _______________________________________________
> > >>> Cfrg mailing list
> > >>> Cfrg@irtf.org
> > >>> http://www.irtf.org/mailman/listinfo/cfrg
> > >> 
> > >> _______________________________________________
> > >> Cfrg mailing list
> > >> Cfrg@irtf.org
> > >> http://www.irtf.org/mailman/listinfo/cfrg
> > >> 
> > > 
> > > 
> > > _______________________________________________
> > > Cfrg mailing list
> > > Cfrg@irtf.org
> > > http://www.irtf.org/mailman/listinfo/cfrg
> > > 
> > 
> > 
> >       --Steve Bellovin, https://www.cs.columbia.edu/~smb
> > 
> > 
> > 
> > 
> > 
> >