Hacker News new | past | comments | ask | show | jobs | submit login

I don't get it. If I check for a password I used before, presumably I want to keep using it if it's safe. Otherwise what's the point?



If you think a password has been compromised then change it.

HIBP offers you a way to validate a password has been compromised, HIBP does not offer you a way to determine it has not been compromised or is otherwise suitable for use. It’s a service for excluding compromised passwords from use.


> It’s a service for excluding compromised passwords from use.

How does this work?

2 cases:

1. I know password P is compromised. I check it in HIBP. If compromised, great, but I already know that. If not, well, too bad. I still can't use it because I know it's compromised. - decision doesn't depend on the result of HIBP.

2. I don't know if P is compromised. I check it in HIBP. If compromised, I don't use P. If not, I don't use P because I already put P in a text box connected to the internet. - decision doesn't depend on the result of HIBP.

Don't get me wrong, I'm well aware of the value of HIBP. I'm just arguing about this particular use case.


On haveIbeenpwned (at least last time I used it), you can either check the hash of your password, or the first N characters and it will return a list of leaked passwords that match


FWIW, I don't think the post you're responding to is correct? At least, I couldn't readily find a place where HIBP tells me not to fill in the form. And it bothers assuring me that it goes to great lengths not to make it obvious what password my client is checking.

Your question is on target--one I've wondered myself--but I've come to the conclusion that it isn't for people who already have the sense not to put their passwords in random forms on the internet.

I can only assume it has 2 main uses:

1. Poke (some) holes in the bubbles of people with dated password hygiene practices (and a poor sense of how good other humans are at helping attackers reduce the possibility space) by giving them a playground to make new passwords against for a while.

For example, I decided to enter "silverfish3" in the form because I know more than one person who still uses <noun><number> passwords that are multiple characters shorter than this one. It's still turned up in the database 40 times. "dichotomy14" hasn't been pwned yet, but "dichotomy7" has already been pwned 5 times.

You don't have to use a real password of your own to discover that your schema is well explored.

2. I can only hope HIBP password search has scared a few thousand of the kind of person naive enough to fill in the form with a real password straight.


Pop open dev tools and take a look at the network traffic when you put "silverfish3" into that form:

It sends a GET request for "https://api.pwnedpasswords.com/range/89F5D"

and gets back 548 rows of the form:

001F74CD3E241B7820C996DA4FB3BDF9FE7:2

...

54C7FB299EC06A0B979C5DE14F1AE61F653:40

...

FFE6FF5698CEC527CD18269D1B7697C8743:1

Note that middle example row with ":40" at the end? Prepend "89F5D" from that GET request the javascript generated to that row's contents "54C7FB299EC06A0B979C5DE14F1AE61F653"

Now compare that to what you get when you run this (This is a macOS specific invocation of the command, but something very similar should work pretty much anywhere):

$ echo -n "silverfish3" | openssl sha1

(stdin)= 89f5d54c7fb299ec06a0b979c5de14f1ae61f653

You might (perhaps rightly) not trust Troy's site to not switch out the javascript underneath you, but you _can_ trust the API, and could always run:

curl https://api.pwnedpasswords.com/range/89f5d

Or, if you're testing that "dichotomy7" password:

echo -n "dichotomy7" | openssl sha1

(to get (stdin)= 772be5bd14dc626ec7fa952b51ae28c482e92d39)

then:

curl -s https://api.pwnedpasswords.com/range/772be | grep -i '5bd14dc626ec7fa952b51ae28c482e92d39'

will show you your result of that dichotomy7 password having been seen 5 times.

You've only revealed the first 5 characters of the 40 character sha hash to the server. That might have been one of the ~500 passwords with that same hash, or any of the rest of the 150 bit space of other strings that hash to that prefix that are not part of their database.

I would be perfectly happy running echo -n "{{a real valuable password of mine}}" | openssl sha1 locally and then feeding the first 5 characters of that into "random apis on the internet".


I think maybe you've mis-read me. I'm well aware of how HIBP does this.

But it doesn't matter what you or I can prove the site does or doesn't do with our passwords; my dad or aunt shouldn't type their passwords into random forms on the internet. Whether it tells them it's using k-anonymization or not.

You still wouldn't pop your dev tools open but then type your real password into a random form on the internet before you'd kicked the API-tires with some fakes.

Anyone who isn't prepared to kick the tires and hasn't established a trust relationship has no business doing it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: