I dealt with that in my note: how do you deal with multiple devices?
Sent from my iPad
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 at 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 at 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 at 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 at zte.com.cn" <zhou.sujing at zte.com.cn>
> >>> Date: Wed, 1 Feb 2012 03:13:07 -0500
> >>> To: Dan Harkins <dharkins at lounge.org>
> >>> Cc: "cfrg at irtf.org" <cfrg at irtf.org>,
Steven Bellovin
> >> <smb at cs.columbia.edu>
> >>> Subject: [Cfrg] ÂÃÂÂ: Re: [saag] New draft: Hashed Password
Exchange
> >>>
> >>>
> >>> Hi,all
> >>>
> >>> cfrg-bounces at 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 at ietf.org
> >>>>>>> https://www.ietf.org/mailman/listinfo/saag
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --Steve Bellovin, https://www.cs.columbia.edu/~smb
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> saag mailing list
> >>>>> saag at ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/saag
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Cfrg mailing list
> >>>> Cfrg at irtf.org
> >>>> http://www.irtf.org/mailman/listinfo/cfrg
> >>>> [ÂÂÂÃ "smime.p7s" ÂÂ ÃÃÃÃÂÂ00132831/user/zte_ltd
ÃÂÂÃ]
> >>> _______________________________________________
> >>> Cfrg mailing list
> >>> Cfrg at irtf.org
> >>> http://www.irtf.org/mailman/listinfo/cfrg
> >>
> >> _______________________________________________
> >> Cfrg mailing list
> >> Cfrg at irtf.org
> >> http://www.irtf.org/mailman/listinfo/cfrg
> >>
> >
> >
> > _______________________________________________
> > Cfrg mailing list
> > Cfrg at irtf.org
> > http://www.irtf.org/mailman/listinfo/cfrg
> >
>
>
> --Steve Bellovin, https://www.cs.columbia.edu/~smb
>
>
>
>
>
>
|