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

zhou.sujing@zte.com.cn Wed, 01 February 2012 08:08 UTC

Return-Path: <zhou.sujing@zte.com.cn>
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 5C8EF11E80CC; Wed, 1 Feb 2012 00:08:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -92.59
X-Spam-Level:
X-Spam-Status: No, score=-92.59 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345, 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 YurmfJqzSwBl; Wed, 1 Feb 2012 00:08:45 -0800 (PST)
Received: from mx7.zte.com.cn (mx7.zte.com.cn [202.103.147.169]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0C711E80CA; Wed, 1 Feb 2012 00:08:43 -0800 (PST)
Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 5467.3618403124; Wed, 1 Feb 2012 16:08:39 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q1188TGR075131; Wed, 1 Feb 2012 16:08:30 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <1c680c52d4a354cdeda0a39e9cc47d32.squirrel@www.trepanning.net>
To: "Dan Harkins" <dharkins@lounge.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF82362B2B.25A281A6-ON48257997.002C4F98-48257997.002CAA3E@zte.com.cn>
From: zhou.sujing@zte.com.cn
Date: Wed, 1 Feb 2012 16:08:23 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-01 16:08:32, Serialize complete at 2012-02-01 16:08:32
Content-Type: multipart/alternative; boundary="=_alternative 002CAA3E48257997_="
X-MAIL: mse02.zte.com.cn q1188TGR075131
Cc: cfrg-bounces@irtf.org, cfrg@irtf.org, saag@ietf.org, Steven Bellovin <smb@cs.columbia.edu>
Subject: [Cfrg] =?gb2312?b?tPC4tDogUmU6ICBbc2FhZ10gTmV3IGRyYWZ0OiBIYXNo?= =?gb2312?b?ZWQgUGFzc3dvcmQgRXhjaGFuZ2U=?=
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, 01 Feb 2012 08:08:46 -0000

Hi, Steven,




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
>