Firefox to Warn When Saved Logins Are Found in Data Breaches | Hacker News Reader

Firefox to Warn When Saved Logins Are Found in Data Breaches

bleepingcomputer.com

312 pointsrahuldottech111 comments

Firefox is using the wonderful haveibeenpwned resource. There is also a public API for haveibeenpwned if you want to incorporate it into your own clients:

https://haveibeenpwned.com/API/v2

Please note rate limits/ abuse policy so everyone can use:

https://haveibeenpwned.com/API/v2#RateLimiting

(I am not affiliated)

1Password uses the HIBP API too [0] which has actually saved me a few times.

The mechanics behind the v2 API (using k-anonymity with hashes [1]) are pretty interesting too. Troy has clearly put a lot of thought and time into what started as a pet project a few years ago and should be infinitely commended!

[0] https://blog.1password.com/finding-pwned-passwords-with-1pas...

[1] https://www.troyhunt.com/ive-just-launched-pwned-passwords-v...

I just read through 1Password release notes [0], "Addressed a bug in the new popup where items were checked for vulnerable passwords even if you hadn't opted in to the Have I Been Pwned service." which also links to a KB article that talks about the security risks of HIBP [1]

I would be very concerned if my credentials are being shared in _any_ form with 3rd parties without my explicit permissions.

I hope this firefox feature is disabled by default.

[0] https://app-updates.agilebits.com/product_history/B5X [1] https://support.1password.com/kb/201907/

Disclaimer: I'm the Firefox sec engineer working on this feature.

Just to clear this up: The code for this is actually way simpler and sends no data to either Mozilla nor HIBP. To prevent Firefox from sending data update pings to HIBP, Firefox Monitor maintains a copy of publicly available HIBP breaches and their metadata [1] in the Firefox "Remote Settings" service. [2]

Using that data, Firefox simply checks for saved logins for breached sites where the saved password is older than the breach. [3]

[1] https://haveibeenpwned.com/api/v2/breaches [2] https://wiki.mozilla.org/Firefox/RemoteSettings [3] https://hg.mozilla.org/mozilla-central/file/6484c07ff8364991...

This explanation confused me, so let me rewrite it:

"Firefox downloads a list of breached domain names and the date they were breached, and merely checks if you have any stored logins on any breached domains that are older then the breach date."

Credentials are not shared under the hibp password system. the first five characters of the hex encoded md5 of the password is shared and the server responds with matching hashes. If 20 bits (2 and a half characters) of hashed entropy can compromise your password you have bigger problems.

Probably worth noting that Have I Been Pwned is now up for sale: https://www.troyhunt.com/project-svalbard-the-future-of-have...

I've always been a huge fan of the project (and Troy) and understand that it's gotten to a point where he can't keep running it as a spare-time project, but I'm still not very happy about seeing it being shopped around. I can't see how this type of service needing to find a way to become a business will be a good thing overall, especially when it keeps getting integrated into other programs and services like this. Troy pledges that nothing will change, but every company getting acquired does that, and then things change anyway.

The best result would probably be something like Mozilla buying it and/or paying Troy to just keep doing what he's doing.

> The best result would probably be something like Mozilla buying it and/or paying Troy to just keep doing what he's doing.

Mozilla could very well be one of the potential candidates for HIBP ownership.

Troy has spoken about that.

They are a known candidate, but they fall further down the list on some of his criteria than he would like. However, he doesn't provide any further details on this issue.

Meanwhile, he continues to look for other candidates.

I would even say that a project like this should be run by the government(s). I get that foreign politics would wreck havoc there, but governments have to deal with data breaches anyway.

The government seems like the party most likely to, and most able to, abuse being in control of a trusted security resource. Would you trust the API if it was operated by the USA (NSA), Russia, China, Australia, or the UK?

I was a fan of the project. But when it went up for sale, I contacted him to ask for my details to be removed from his db (re the auto-notification stuff), and didn't get any response.

I'm no longer a fan.

Guess I shouldn't have trusted him with my personal information.

This is why I never check passwords against haveibeenpwned. The idea of sending your passwords to a third party is pretty crazy. Even when I knew the owner and trusted him, there’s no way I’d know everyone with access. And now the site could be sold to someone like Google and God knows what they would do with all that traffic.

I used to download the whole file and check locally, but it’s too much of a pain to do consistently.

Wait, WHAT?

Troy’s site asks you to send passwords? Not just login identifiers like an email or username?

In that case, you should AT LEAST be sending a hash of a password, a very key-strengthened hash (like sha2 done 1000 times) and on his side Troy can see if it matches anything.

Yeah, that's what HIBP does. See here: https://www.troyhunt.com/ive-just-launched-pwned-passwords-v...

I really feel Troy has handled HIBP very, very carefully, honestly, and with the utmost transparency so far. He seems to have put in a lot of thought into everything - whether it is rolling out a feature or planning the future of HIBP.

To clarify for the GP: HIBP sends the first handful of characters of the password hash to the server, not the password itself or even the full hash. The server then returns all of the hashes matching that prefix, and the remainder of the comparison is done client side.

> The idea of sending your passwords to a third party is pretty crazy.

Thats not how it works. You hash your password first and then take the first 6 chars of the hash to query the api. The api then returns all of the hashes that begin with those 6 chars and you scan the results for your full hash.

https://blog.cloudflare.com/validating-leaked-passwords-with...

That is not a sound security policy. Reducing the attack range of my password from 1:72^8 (or greater with non alpha, more than 8 chars) to 1:500 is only a matter of time before I’m pwned. Should anyone ever want to pwn me (which I hope they don’t).

It only reduces the odds to such a tiny number if your password is in the list (otherwise, guessing the remaining 136 bits of the hash is infeasible). If that's the case, however, sending a part of the hash to the server is still the best idea, because you want to know that the password needs to be changed immediately. At this point, the 72^8 estimate no longer matters, both because the full list of HIBP passwords is much smaller than that and because you don't know if other information (such as the corresponding username) was leaked along with the password.

You don't send the password to him. Your browser hashes it, then sends the first few characters of the hash to the API. You can look at the network panel of you don't believe it. The protocol is fully documented on the site. I used it to make a React hook to check your user's password when they sign up. https://github.com/ascorbic/use-pwned-passwords

Thanks for the comment. It’s enough of the hash shared for me to be uncomfortable and for me to recommend not using it.

I applaud them for limiting the risk. But when the information shared with them let’s a bad guy know the 500 possible matches out of trillions, that’s not good.

It’s not literally clear text, which is nice. But it’s not without risk. And it’s not a good practice to share portions of password hashes with untrusted parties. Like a friendly hacker who runs a nonprofit site or whatever company buys it.

Why? I would be concerned only with the full hash (because people tend to use the same few passwords across many places), but given it's a partial hash, there's literally no info being sent around.

Keep in mind that your password may not be contained in the result set from HIBP (and if it is, you should likely change it anyway). So the attack space is only reduced to "any string whose hash begins with these characters", which should be considerably larger than 500 or however many results HIBP returns. It would be drastically smaller only if the attacker knew the hash was contained in HIBP.

Effectively, since HIBP asks for 5 characters of the hash, the space is the same as if the full hash were 5 characters shorter.

This is a good point as not all passwords will be in known set.

I guess it’s only a 1:500 if the password has been pwned. In which case, the owner should promptly change it and remove the risk.

Thanks, I didn’t think of that. For some reason I was stuck in thinking that all passwords have been pwned and in the file.

What you do with your own data is your decision, but if these details are enough for you to _recommend_ that other people not use it, then your advice needs to come with an "I ignore math in favor of uninformed prejudice" disclaimer, because you're making things worse with your security mysticism.

That wouldn’t be a disclaimer that is accurate, so I don’t think I would use it.

Anyone who takes my security recommendations is already familiar enough of my math vs informed prejudices balance.

Apparently most of the SHA1 hashes of haveibeenpwned passwords were cracked about a year ago:

https://blog.cynosureprime.com/2017/08/320-million-hashes-ex...

I wonder if segments of the list are around to create a password-blacklist

edit: previous discussion https://news.ycombinator.com/item?id=16799826

Sure, the source they're referencing, with a plaintext torrent, is here: https://hashes.org/leaks.php?id=515 which was last updated yesterday.

However, this shouldn't be alarming.

1) Attackers already have the plaintext password of these hashes. That's why they're in HIBP's repository in the first place.

2) You should already assume most sites/apps don't have proper security hygiene. Password re-use is what will get you. If you wish to warn your users if they're reusing a password, then HIBP's API should already do well for that.

3) You have truly astronomical odds of generating the same password as one in a leaked database should yours contain enough bits of entropy. Remember that GPU's are making millions of guesses per second in the first place when cracking passwords, and significantly slower if the hashing algorithm protects against GPU attacks.

How sensitive are most of these passwords really though? What is a big company or Google going to do? Log into all your accounts and steal your data? That doesn't sound like a very realistic scenario or even a threat model you should be worried about.

Even less so with the strategy of just sending a small hashed part of the password to HIBP like others already explained.

One thing HIBP does is match a password against a list of half a billion leaked passwords without regard for the username portion of the credentials. They do it because of the NIST guidance to compare credentials to known data leaks. The same NIST who's previous guidance was a complicated password entropy algorithm, which they later dropped.

I've always questioned the logic making 500,000,000 passwords off limits when no connection is made to the username. Work-factor hashing algorithms, rate limiting account locking and 2FA are supposed to protect user from brute force attacks. I think they can handle an attack based on 500 million possibilities.

Now, if they matched the username/password pair, that would be great.

The results show how often it was breached so you could always just blacklist passwords leaked more then 100 times or so. The really dangerous ones are the "common" one word passwords used hundreds of thousands of times.

The thing is that all of the passwords in his database, are ones that the blackhats already know. As in, they not only have the hashes, but the full in-the-clear passwords. His sources for these lists are blackhats themselves, who happen to leak their copies of their password lists, one way or the other.

And all the major password cracking tools will typically try all the known bad passwords, before they try anything else. And they'll try all known likely variants, before making any potential brute-force attempts.

So, it doesn't matter if the password you want to use is on this list and you want to use it anyway, just because it has never been associated with your userid.

The simple fact that you're trying to use a known bad password that has ever been used before by anyone else, is enough to increase by many, many orders of magnitude the likelihood that someone will be able to crack your new favourite password.

Bad passwords are simply bad, regardless of who tries to use them. Some are worse than others, but they're all bad.

This aspect of HIBP helps you discover if any of your passwords have ever been cracked by anyone, and therefore now on the list of known bad passwords.

There are fundamental privacy risks to using the HIBP Pwned Passwords service which should be considered when implementing it. See my writeup here — https://cablej.io/blog/k-anonymity/. In short, despite claims of protecting privacy, a malicious server can recover user passwords in some cases even if they haven’t previously been compromised.

OK, enough is enough. I'm switching to Firefox now.

Protip to Firefox: Advertise this feature more. The other stuff I don't really care about, and didn't really convinced me to move to Firefox. Fear is an excellent motivator, however.

You will be happy with the move, if you're coming from Chrome, most extensions/add-ons are available on Firefox so the transition was not tough for me. There are some things like getting used to the dev tools but that shouldn't be too bad :)

I switched about two weeks ago. I had a few things I toggled in `about:config` but otherwise have been very happy. I appreciate how well Firefox works out of the box.

Can I use my own custom addons with Firefox? Or do I still need a developer/unstable version of Firefox for that?

I don’t know the _real_ answer but in the worst case scenario (“you can’t”) you can for sure use temporary add-ons in about:debug

Try and give Firefox Containers a test too. It's a Firefox extension made by Mozilla that creates separate environments where cookies and session data are not shared. It's a great feature I never want to do without. I use it to create a wall between work and personal web browsing.

Handy link: https://addons.mozilla.org/en-US/firefox/addon/multi-account...

(+endorsement: it's a really great feature for power users)

The Facebook Container is very usable for non power users so long as they're already uncomfortable enough with the all-consuming nature of Facebook to not use Login with Facebook type features (which can't work from a container by definition)

I'm not going to get my mother to use containers to keep her banking separate from her knitted craft forums, the same way I'm not going to get her to use a password manager, but I can install the Facebook Container and buy her a book to write passwords in so she uses more than two different ones.

Disclaimer: Firefox sec eng who works on both this feature and Facebook Container ...

The new 2.x release of Facebook Container allows people to use "Log in with Facebook". To do so, it adds the site into the Facebook Container so sub-resources and 3rd-party cookies are available to the Facebook SDK js.

It warns the user before they enable this on any site.

Thanks for your work! When I said Multi-Account Containers are great for Power Users, I had in the back of my mind that Facebook Containers are great for everyone who does not use MAC - it really is a pretty seamless experience, and as opposed to MAC, does not require manual container selection.

Thanks, I did not know that and I will update my advice to users I know concerned about Facebook.

Thanks, I'm going to try set this up after work.

The functionality is part of every decent password manager, which takes care of basically all your passwords, not the ones stored in your browser. So I don't understand the enthusiasm.

these are the reasons a browser built-in password manager is ideal for many people:

1. most people don't need many passwords outside of the browser.

2. in-browser password managers can offer a better user-experience than standalone password managers. (although, so far, firefox's built-in password manager is lagging behind in this regard.)

3. password managers integrated into the core of the browser have a smaller attack surface than those implemented as plugins.

4. users of a particular browser already trust the browser vendor with their passwords, at least enough to let the browser see and transmit them every time the user logs in to a site.

FWIW This same functionality is available as a Chrome extension: https://security.googleblog.com/2019/02/protect-your-account...

(Disclosure: I work on Chrome, though on Developer Tools)

OK, back to Chrome it is. Thanks :)

why?

For non-tech users, privacy isn't a very good selling point.

Both my parents use Chrome because it's already installed on Android and works fine. My attempts to convince them to Firefox didn't work out even with multiple attempts.

What data does this send and who receives it?

Is money involved in this partnership? If so, who paid whom?

What was the motivation behind this? Is there any study that shows any benefit from haveibeenpwned.com? I.e. has there been a decrease in hijacked accounts, etc?

There's more about how Mozilla obtains the data here: https://www.troyhunt.com/were-baking-have-i-been-pwned-into-...

I don't think there's been studies, but it seems obvious to me that the goal here is to prevent re-use of leaked passwords, and I'd consider it a surprising result if this wouldn't help in that.

CCP Games integrated it into Eve Online and says that it significantly reduced the number of players using insecure passwords:

> When we first implemented the check, about 19% of logins were greeted with the message that their password was not safe enough. Today, this has dropped down to around 11-12% and hopefully will continue to go down.

From https://www.eveonline.com/article/pu2gdi/account-security-im...

Answered here: https://news.ycombinator.com/item?id=20465981

That sounds like a good reason to get your non-technical friends and relatives on Firefox.

(Edit: though I wonder whether the really non-technical ones will not interpret this as having to change the displayed saved password, rather than having to visit the website.)

How does Firefox compare your actual password to the leaked password without storing your passwords in plaintext?

It is storing your passwords in plaintext locally, since this is about passwords that are saved by the user in Firefox's password store (the Saved Logins feature). These can (and should) be protected with a master password, but you obviously need to unlock the store before logging into a website.

They're not storing your passwords remotely, though. They're asking haveibeenpwned which maintains a list of leaked login information from past breaches.

It looks like they're not doing this, but it is also possible to see if your exact password is in the breach using an algorithm called k-anonymity:

https://blog.cloudflare.com/validating-leaked-passwords-with...

Mozilla are using k-anonymity in their FirefoxMonitor service[0]. This feature syncs from FirefoxMonitor to a local browser DB and checks against that DB. However, I'm not 100% sure what data it syncs from FirefoxMonitor (obviously a subset, but I don't know how that's chosen. I'm not sure if they're using k-anon for requests between the Firefox browser and their own service).

[0] https://github.com/mozilla/blurts-server/blob/master/hibp.js...

I believe the article is false.

As far as I understand [1] Firefox will notice you if the domain was breached and your password is older than the breach.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1559365

From that ticket, the comments discussing the domain and time of the breach are about adding that filtering to the existing feature, not about those being the only checks. The article is not false.

Answered here: https://news.ycombinator.com/item?id=20465981

https://hg.mozilla.org/mozilla-central/rev/6484c07ff836#l3.7...

Firefox has a built-in password manager, so plaintext passwords are necessarily stored in that database. The backend comparison service they're using supports a near-zero-knowledge protocol that allows clients to check for compromised passwords in the database efficiently without ever sending the password (or even a hash of the password) to the backend.

Also they can just query all the usernames (email addresses) of the accounts and get notifications if any of those usernames have appeared in breaches.

But... will mozilla or the people behind haveibeenpwned know I am using a pwned password? Basically, by checking if you are under risk, do you leak info to 3rd parties that can be used against you, before having the opportunity to protect yourself? Is there any info aobut the near-zero knowledge protocol somewhere? It's a fascinating topic for sure.

Search for Pwned Passwords k-anonymity for a description of how this works technically.

No, only you (well, your computer) knows if your password was found.

No they don't. The browser hashes the password, then sends the first 5 hex digits of the hash to haveibeenpwned. HIBP replies with all the hashes of leaked passwords that start with these 5 digits and the browser then checks to see if the hash is in the list.

Nope. Read the section on k-anonymity here: https://www.troyhunt.com/were-baking-have-i-been-pwned-into-...

Essentially, the client hashes the password and then only sends the first 5 characters of the hash to HIBP. HIBP then returns the hashes of every password whose hash begins with the same characters (approx 477 matches, according to the article), and then it's up to the client to determine if there's a match.

I like the approach reduces the risk, but this isn’t sufficient for me to actually trust a third party. The article calls out an example where the five character hash prefix has 477 matches in the password file.

That’s a ridiculously small number of possible values for a powerful actor trying to crack a password.

But your password is NOT one of just 477 known passwords. It is one of 2^(8*11) possible passwords that share the same first 5 bytes of a 16 byte hash.

The way I understand their implementation [0] is that the client sha256s their password and sends the first 5 characters, not bytes. The server then responds with all the matching hashes. In the article the example was 477 matching hashes.

So it’s not all possible hashes with that prefix, it’s only the hashes of entries in the known passwords.

If the server was compromised, it would be able to know which users requested which hash prefixes and compare that to the “known hashes” that match that prefix. Not all passwords submitted are matches, but some are. And it’s likely that a users pattern of testing particular hash prefixes could make it much easier to crack a password.

[0] https://blog.cloudflare.com/validating-leaked-passwords-with...

The password isn’t necessarily in the list, and if it is it should be changed. The service just returns the list and you check locally. The server only gets the first few characters of the hash.

Knowing the hash prefix of someone’s password doesn’t help you guess it. You can’t plan your guesses to have a matching prefix or anything. If your password is in the list, then the full hash is already out there and you should stop using it, because it’s probably been brute forced by someone or people are trying to guess it somewhere.

I'm pretty sure that it is just usernames/emails that are queried.

Answered here: https://news.ycombinator.com/item?id=20465981

That’s a nice feature, and I hope other browsers will adopt something similar soon. Also looking forward to the password generator that’s finally coming in Firefox 69. On a slight tangent, I wish the major browsers would agree on an interoperability standard for their built-in password managers.

Press reports that this is shipping in Fx69 were incorrect.

No? That’s a bummer. What’s the correct EVA (estimated version of arrival)?

> On a slight tangent, I wish the major browsers would agree on an interoperability standard for their built-in password managers.

Are you talking about an interop standard for storing/sharing passwords, or for generating them?

Because the latter is hobbled significantly by a twisting maze of password requirements and login form implementations by sites (banks, webmail, etc).

> an interop standard for storing/sharing passwords

Is what we need. You can export from Chrome to a CSV, and you can import that CSV into 1Password, but no way to get those passwords into or out of Firefox that I've found (please tell me if you have a method..).

> You can export from Chrome to a CSV, and you can import that CSV into 1Password, but no way to get those passwords into or out of Firefox that I've found (please tell me if you have a method..).*

https://github.com/kspearrin/ff-password-exporter/blob/maste... :)

> "You can export from Chrome to a CSV, and you can import that CSV into 1Password, "

It would be nice if there was a way to do this without touching the file system, although I suppose a ram backed filesystem would be a bit better, provided it didn't get swapped. But letting my passwords get stored in plain text on my spinning rust, even for just a minute or two, seems less than ideal.

There is also this: https://wicg.github.io/change-password-url/index.html

which is an interop standard for websites to expose a "Change your password" page, which is a good place to start. It lets the password manager link directly to "your password for foo.com is expired/known to be leaked/weak, [change it here]"

Is Firefox trying to replicate all behavior of password managers?

Browsers that offer to save your passwords are password managers. They've just been downright abhorrent at it for years. Improving that seems worth doing?

they certainly aren't as bad as they used to be, but the UX hasn't improved much. in-browser password managers these days have acceptable security and features like the one in the article are starting to surpass other password managers. but gawd, the UX.

my biggest qualm with the UX of firefox's password manager is the "master password" feature. it's a password you must enter to unlock your keychain. that's a must-have for me.

what firefox does wrong:

* it's rendered as a simple dialog prompt, identical to javascript's window.prompt. could be faked by a site for phishing.

* the unlock prompt launches once, about 30 seconds after the browser is launched (right while i'm in the middle of typing a URL) and grabs focus.

* if you don't provide a password, the prompt will show up again each time you visit a page that has a login form for which you have a saved password, even if the login form is hidden with CSS. many sites have login forms on every page.

* there's no way to unlock the keychain on a per-site basis or lock it again once you've unlocked it (besides closing the browser).

what i want is:

* when i'm about to log in to a site, i expect to provide my master password and have firefox autofill my saved password for this site only.

* if i need the password again later, or a password for a different site, i expect to have to provide my master password again.

* a dialogue that i can trust to have come from the browser itself rather than the webpage.

* not to be interrupted by the dialogue unless i need to access a saved password.

They seem to be working on the password manager in general lately(ish) e.g. https://lockwise.firefox.com/ , so I think there's a decent chance that side of things will improve. Because yeah, it has been an awful, nigh-unchanged experience for pretty much its whole existence.

i hope so! i've seen a lot of recent announcements related to saved passwords. but so far none of them have been about the UX.

Oh, I'm not opposed to Mozilla doing this.

I'm just curious if they intend to fully replace third-party password managers.

Mozilla is building a standalone password manager app for Android and iOS called "Lockwise" (formerly "Lockbox") that will also integrate with Firefox:

https://lockwise.firefox.com/

^ yea. My guess is that they're trying to improve the basics to the point where third party ones aren't necessary, which I'm fully in favor of. I don't really think there's any risk to them removing other managers, just competing.

Yeah, in fact they've launched a password manager app. https://lockwise.firefox.com/

How sending clear login and passwords to a third party website is ever a good idea?

It isn't doing this. It uses rough hash of the password to generate a bucket ID that could represent a large number of passwords. That information is the used to query a bucket for whether any passwords in the bucket exist.

For example, "password" hashes to "5DAA6", and the resulting bucket[1] lists secure hashes of several dozen passwords.

The client then generates another hash of the password (eg. "1E4C9B93F3F0682250B6CF8331B7EE68FD8"), and checks if that secure hash is in the bucket (it is, "password" has been compromised at least 3,730,471 known times).

[1]: https://api.pwnedpasswords.com/range/5BAA6

This is also false.

Why would it need to send the passwords?

Could it not download a list of a every site that has ever been hacked along with their domain list and the date of the hacking, then warn you if you have a saved password for one of those domains that was saved before the domain was hacked?

Because that's what it does.

Answered here: https://news.ycombinator.com/item?id=20465981

Does it mean your browser is going to leak your sites/account information to a third party?

Will this feature be enabled by default?

Can this be disabled?

https://blog.mozilla.org/security/2018/06/25/scanning-breach...

thank you.

haveibeenpwned doesn't accept plain-text passwords for checking, they use a k-anonymity model to protect both your passwords and the passwords in the database. the same goes for email addresses.

https://haveibeenpwned.com/API/v2#SearchingPwnedPasswordsByR...

HIBP doesn't work that way really. You don't query for a site breach + email combination, you basically give your email address and then it returns back a list of breaches your email address was part of.

As far as HIBP linking your email to specific breaches, well, it is essentially using public data sets so that disclosure exists already (before HIBP even enters the picture). They are a bit more reserved with certain cases (the Ashley Madison breach for example), but even then if someone wanted to locate email addresses in that breach, they'd just go get that data set.

As long as this functionality can be disabled.

This feature has a potential in connecting a browser (instance/session/ip) to an email (even in the form of abbreviated hash), which I would consider a security risk.

Answered here: https://news.ycombinator.com/item?id=20465981

They don't look at passwords

They look at breached sites and rather or not you saved a login for that site on a date before the site was breached.

So, Firefox operates with yet another third party. I've never used this ''Have I been PWNed?'' drivel and don't intend to start, but I don't usually find myself using a Firefox-brand Firefox, either.

What's so compelling about this website? To me, this looks like yet another silly idea people coalesce around and find important. In having a discussion about this, someone mentioned how it's not that different from Facebook and Cloudflare in managing something technical for those who don't care to, and I find this a rather decent comparison. This is yet another centralized and completely unnecessary entity.

I don't see the appeal and I don't like what I regard as a stupid idea receiving so much attention from so many groups. This isn't surprising coming from Troy Hunt, however, who I best remember as the person bitching about an ad blocker blocking an ad he found acceptable.

Do you maybe want to explain why you think it's a bad idea instead of spending three paragraphs dumping on it?

Answered here: https://news.ycombinator.com/item?id=20465981

So you're saying that the browser client will now be regularly sending secure information on a regular basis to a predictable IP, across HTTP (hopefully S, but I'm sure there will be a fallback), via dynamic path and across an unknown number of hops for transit. And this is supposed to be more secure.

I'm sure there's nothing to go wrong with that wonderful plan! Taking control away from the user is a great idea!

Except that it's not.

The haveibeenpwned API uses a k-anonymity model, so that the client can check a password in an efficient fashion (ie. without downloading the entire list of pwned hashes), without also revealing the hash you're trying to check.

Basically, it asks for all pwned hashes that start with the same 5 characters as your password's (hex-encoded) hash. So yes, there is an information leak (the first 5 characters of your hash), but it's an extremely unimportant one. Even knowing the first 5 characters, there's still 2^140 possible hashes it could be. And of course they would then need a pre-image attack on SHA1 to deduce your actual password from that.

More detail here: https://www.troyhunt.com/were-baking-have-i-been-pwned-into-...

Finally, I'm sure this option will be possible to disable, probably in settings but certainly in about:config.

Answered here: https://news.ycombinator.com/item?id=20465981

Why would it need to send the passwords?

Because that's what it does.

Reply on news.ycombinator.com