[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Mar 2018 18:10:53 -0800
From: Royce Williams <royce@...hsolvency.com>
To: passwords@...ts.openwall.com
Subject: Re: Submitting Partial Password Hashes to Pwned Password Lookup
Agree 100% with Jim - and I believe that the "commonly" concept is indeed
being lost in context.
Royce
On Mon, Mar 12, 2018 at 2:01 PM, Jim Fenton <fenton@...epopcorn.net> wrote:
> On 3/12/18 1:19 PM, Matt Weir wrote:
>
> This e-mail has already grown too large as it is, but I’d be
> interested in other people’s thoughts on this subject. Am I
> misunderstanding the use of K-anonymity? How should we look at the
> security of this approach?
>
>
> Hi Matt,
>
> I have been looking for the appropriate venue to write something about
> Pwned Passwords, so thanks for the prompt.
>
> tl;dr: Whether you call this k-anonymity or not, I have concerns.
>
> The concern with this, of course, is that some attack (perhaps an attack
> on the web server or CDN) might give an attacker access to the queries and
> associated IP addresses. With the IP addresses, it might be possible to
> determine who the user (and their userID is). With a full hash, it would be
> possible to crack that hash to find the password.
>
> But these hashes also come with frequency statistics. So the attacker can
> just start with the most likely hash (the one with 47205 occurrences in
> your example) and work down the frequency list from there. There are 475
> hashes representing 53006 password instances in the page you cited, so it's
> likely that you'd only need to crack that one hash value and that's the
> right one. Your analogy with past use of Shannon entropy is indeed
> accurate.
>
> Another concern I have is with the API itself. Many web servers by default
> log the URLs of their requests, so with this API it might log the IP
> address of the requester and the prefix of the hash. I'm sure Troy has this
> all covered but it sounds like he has an elaborate CDN to handle the flood
> of requests he gets for this, and I hope they have this covered as well. A
> better approach would be to use a POST request and put the hash prefix in
> the body of the request (although I don't know what effect that might have
> on the CDN).
>
> My other concern has to do with the effects of using such a large
> blacklist. This has the potential to frustrate users: "Every password I try
> is already taken!" when in fact if the password only appears only a few
> times in such a large corpus it's probably pretty good. When users get
> frustrated like this, they tend to do predicable things, akin to appending
> ! to a password to meet composition rules. A good reference on this:
>
> Habib, Hana, Jessica Colnago, William Melicher, Blase Ur, Sean Segreti,
> Lujo Bauer, Nicolas Christin, and Lorrie Cranor. “Password Creation in the
> Presence of Blacklists,” 2017. https://www.ece.cmu.edu/~
> lbauer/papers/2017/usec2017-blacklists.pdf.
>
> If a pattern emerges, attackers don't have far to go from the passwords in
> this corpus to find the right answer. When the offline attack gets the
> attacker close enough to enable an online attack, we have a problem.
>
> I played with this a bit for PasswordsCon LV 2016 using Mark Burnett's
> corpus of 10 million breached passwords, and formed the opinion that a list
> of about 100,000 passwords (representing those appearing 3 or more times in
> the corpus) was reasonable, both from a security and lack-of-frustration
> perspective:
>
> https://www.slideshare.net/jim_fenton/toward-better-password-requirements
> (see slides 17-22)
>
> I haven't seen whether Troy has published any frequency statistics for
> this set. If not, I should ask him (or just do it myself).
>
> I'm a little concerned that people are interpreting the following wording
> in NIST 800-63B as a requirement that the list has to be as comprehensive
> as possible:
>
> When processing requests to establish and change memorized secrets,
> verifiers SHALL compare the prospective secrets against a list that
> contains values known to be commonly-used, expected, or compromised.
>
> I wrote that sentence, and that wasn't my intent (the key word here is
> "commonly"). There's a balance, and making it harder to choose an
> acceptable password isn't always good for security.
>
> -Jim
> (personal opinions, not NIST's, of course)
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
