Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 15 Mar 2018 13:05:49 -0400
From: Matt Weir <>
Subject: Re: Submitting Partial Password Hashes to Pwned Password Lookup

Thanks for the reply Jeff!

> I have argued[1] that if you have a truly strong and unique password
> that is in HIBP, then that requires immediate action

That's a good point! Of course that action might be not to trust that
site.  I know I have some sites that I'm a member of that always seem
to be getting hacked that I give a throwaway password and accept the
risk of someone messing with my account.

> That will really matter to Alice’s well-being...

I agree. That's where I'm hesitant to offer blanket advice on
blacklists since different use-cases have different requirements. I'm
a fan of standards when it comes to back-end implementations that are
largely hidden from the users, such as password storage, but with
blacklists we're trying to protect the users from themselves which
gets complicated. Which is another way of saying I'd be horrified if
the Pwned Passwords lookup was performed by every site, but I can
certainly see it being useful for edge use-cases.


On Wed, Mar 14, 2018 at 6:04 PM, Jeffrey Goldberg <> wrote:
> I will just be commenting on a few of your points here
> On Mar 14, 2018, at 3:40 PM, Matt Weir <> wrote:
>> if the password was randomly generated, is there value in using
>> the service?
> Yes. Do not assume that cracking is the only way a password can be
> captured. There are plaintext offenders, passwords can be captured in
> transit, and they can be captured by local malware.
> One 1Password user reported[0] that “R9VvPHGoBmK64J” (long since changed)
> was found on the list. After a bit of digging, we found it to be from
> a plaintext breach.
> I have argued[1] that if you have a truly strong and unique password
> that is in HIBP, then that requires immediate action. It means that the
> listing in HIBP almost certainly is about your account as it is exceedingly
> unlikely that someone else has been using that same password.
>> For #3, I’ll admit I’m a bit blasé about the user frustration impact
>> of huge blacklists
> We need to remember the purpose of password choice constraints. We may want
> people to end up with passwords that aren’t like many other people’s
> passwords. We are trying to flatten the distribution of passwords. So
> a blacklist of the top 10,000 makes some sense in many contexts.
> But a blacklist of 500,000 is going to have a long tail. So it may not
> really be that useful in the typical context.
> However, in a different context I can see using the full set as a blacklist.
> Consider selection of a master password for a password manager. Suppose Alice
> uses a password manager and has 100 sets of credentials in it all protected by
> her master password. Now suppose that her encrypted password manager data
> is breached, perhaps her local machine was stolen.
> How long does Alice have to change those 100 passwords? Is it hours, days,
> weeks, months, or years? That will really matter to Alice’s well-being, and
> so is pretty much the opposite of the chasm of “don’t care”[2].
>> All the research I’ve seen has shown that blacklists have a noticeable
>> impact when protecting users against online password guessing attacks,
> Right. We need to try to be clear about what we are aiming to protect against.
>> but I’ll admit my blacklist creation advice is based as much, (if not more),
>> on gut feelings vs actual studies and experiments.
> Well, yeah. But my gut intuitions are always right, so who needs data?
> Cheers,
> -j
> –-
> Jeffrey Goldberg
> Chief Defender Against the Dark Arts @ AgileBits
> Notes
> [0]
> [1]
> [2]

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.