Firefox To Warn When Saved Logins are Found in Data Breaches (bleepingcomputer.com) 134
Starting in Firefox 70, Mozilla aims to have the browser report when any of your saved logins were found in data breaches. This will be done through their partnership with the Have I Been Pwned data breach site. From a report: Mozilla is slowly integrating their independent Firefox Monitor service and the new Firefox Lockwise password manager directly into Firefox. Mozilla is also considering premium services based around these features in the future. As part of this integration, Firefox will scan the saved login names and passwords and see if they were exposed in a data breach listed on Have I been Pwned. If one is found, Firefox will alert the user and prompt them to change their password. This new feature will only work, though, for data breaches that exposed passwords and when the password was saved prior to an associated data breach.
In other words ... (Score:5, Insightful)
Does nobody realize that entering your login/password information into a third party website means your login/password information is being sent to a third party that you HOPE isn't gathering into a database of their own?
No, I guess it's ok. There has never been any company that takes such information and uses it for purposes other than what the user thought it would be. Can't happen.
Well it didn't used to be (Score:1)
Oh well, it's open source, I can go use one of the forks...
Re: (Score:3, Informative)
You're both failing to understand basic shit, it's comically sad. You store your pw hash in the client, it is only ever decrypted there. The server checks their hashes against your hashes. If there's a match, it gives you the data on that. Derp.
You are smarter than this, I guess everyone has brain farts when obfuscants obfuscate effectively with lies...
Re: (Score:1)
I was unclear, the server sends data and the CLIENT checks the client's hashes against the server's. The way I phrased it made it seem teh server was doing that, it is obviously not. Mozilla isn't complete no-skill morons, Obfuscant...
Undetermined at best. Lying in public about something checkable as if fact? Go fuck yourself, your name suits you perfectly.
Re: (Score:3)
I was unclear, the server sends data and the CLIENT checks the client's hashes against the server's.
So the client will be downloading a few gigabytes of hashed data to compare against the stored password. Cool. I retract all objections. Thanks for clearing things up.
Mozilla isn't complete no-skill morons, Obfuscant...
No, the morons are those who trust completely every company that is handling their login/password data without thinking about how things might go wrong.
Go fuck yourself
Pot meet kettle.
Re:Well it didn't used to be (Score:4, Informative)
Instead of speculating why not just look at the API documentation [haveibeenpwned.com]?
As you can see, it's possible to send a partial hash (first 5 characters of an SHA-1 hash) and get all the matching hashes back, so you don't even need to send a hash of your actual password to them.
So even if HIBP is compromised at most they can match a partial hash query from an IP address against a list of possible passwords, which may be 0 to N long. Let's say they get lucky and find exactly 1 result. They have an SHA1 hash, possibly a password linked to it, and an IP address.
It's possible they could do something with that, but it's getting pretty far fetched, and why would they bother when they already have millions of compromised accounts in plaintext?
Re: (Score:2)
As you can see, it's possible to send a partial hash (first 5 characters of an SHA-1 hash) and get all the matching hashes back, so you don't even need to send a hash of your actual password to them
A truncated HASH is still a HASH.
The first 5 ASCII characters of hex string representation of SHA-1 digest equals 20 bits which is as much entropy as many crummy passwords in the first place.
Subtracting 20 bits from the average 40 bit password is itself a big deal because now you are left with a 20 bit password.
Re: (Score:2)
That's not how hashes work.
Re: (Score:2)
That's not how hashes work.
It's how basic math works.
I have a password with 40 bits of entropy.
I give 20 bits of entropy away to a complete stranger.
How many bits are no longer secret?
In fact the properties of hash algorithms are irrelevant. 40 bits of entropy is insufficient to withstand a brute force campaign anyway so whether I just lobbed off half of the actual password or hand out part of the hashed representation it makes no difference with regard to unknown remainder.
Here is another one:
I have a password with 20 bits of entro
Re: (Score:3)
Okay, so they have a partial hash of your password and an IP address. What is the threat model here?
Re: (Score:2)
Re: (Score:2)
Okay, so they have a partial hash of your password and an IP address. What is the threat model here?
I suspect the most likely threat is from hybrid online offline attack. You test your password and as a result an attacker with access to this information is automatically a million times better at related online password guessing of remote shells / vpn / email / service ...etc passwords.
Data might also be leveraged to accelerate offline attack. If an amplified hash of your password is in attackers possession partial data enables roughly million x amplification factor fold reduction of computing resources
Re: (Score:2)
How do they test your password... They have half a hash of it. Actually not even half, 12.5%.
And the IP address you submitted the request from. Which is probably not your server which hosts your shells / vpn / email etc. And most people don't have those things, and if you do you are probably not the target audience anyway and should be using certificates.
There is no practical attack from submitting 12.5% of a hash and an IP address. And if there was, you could easily mitigate it by sending a few honeypot ha
Re: (Score:2)
How do they test your password... They have half a hash of it. Actually not even half, 12.5%.
Basic idea is while conducting a brute force attack if truncated hash of a candidate password doesn't match the attacker knows its the wrong one and moves on to the next password.
When they find a match only then will they expend the effort to transmit password for offline attack or burn CPU cycles necessary to check amplified version they are attempting to compromise.
And the IP address you submitted the request from. Which is probably not your server which hosts your shells / vpn / email etc. And most people don't have those things, and if you do you are probably not the target audience anyway and should be using certificates.
Most residential users don't which I suspect is fine. They are not the ones with systems worth compromising in the first place. It's what ha
Re: (Score:2)
Removing bits from a hash of a password doesn't make a password easier to recover, it removes information you could have used to guess the password.
Yes. This is the thinking behind these schemes where only the first truncated 20 bits of hash are used and the rest is discarded to make it more difficult to obtain corresponding plaintexts.
Each bit removed doubles the number of incorrect strings that match the hash.
Sure does.
Remove 8 bits, and you'll get around 256 strings that match the hash, but as only one is the password you now have 255 incorrect answers and no way to know which is correct without testing each and every one.
In this case with only those first 20 bits (2^20 = 1048576) of the hash available to me I can test a candidate password against the truncated hash.
The chance of any given candidate password matching the truncated hash (those first 20 bits) therefore requiring further scrutiny (such as 'online' testing) is just
Re: (Score:1)
Hashes can be easily differentiated with salts in a system. It's actually trivial. Jesus Christ on a log, you're tumbling either way.
Re: (Score:2)
You store your pw hash in the client, it is only ever decrypted there. The server checks their hashes against your hashes.
I guess you missed the convenient button that shows stored passwords in the clear. The password that Firefox stores with your username is obviously an easily reversed hashing process, since it has to send that data in whatever clear-text entry field the relevant website uses.
I guess everyone has brain farts when obfuscants obfuscate effectively with lies...
Be careful about who you call a liar, coward. Data will be going to a third party, even if it is just an encoded form of a password, and that third party's own website asks for clear-text passwords. Anticipating that this is the API be
Re: (Score:3, Informative)
No. You can find matches without exposing the actual passwords. That's where cryptographic hash functions are normally used.
Re: (Score:2)
No. You can find matches without exposing the actual passwords. That's where cryptographic hash functions are normally used.
Cryptographic hash function? Like one way hash functions in password databases routinely reversed thru brute force?
Re: (Score:2)
So are you positing that salt can't be used / doesn't work
Whether salts are used or not is irrelevant.
or are you saying Mozilla is incompetent and doesn't know what salts are, or... ?
No. I'm making fun of parents commentary on cryptographic hash functions. I have no idea what Mozilla is actually doing nor do I feel like guessing.
Re: (Score:2)
Cryptographic hash function? Like one way hash functions in password databases routinely reversed thru brute force?
No, partial hashes can't be brute forced, you have nothing to verify it against that would match the original full hash.
As an example, using plaintext "12345" results in an sha1 of "8CB2237D0679CA88DB6464EAC60DA96345513964"
I send you just "8CB2237D0679CA88"
A, the above is not a valid sha1 hash to check "12345" against.
B, there are billions of plain text that will sha1 hash such that they begin with the above segment.
What method exactly do you propose to single it down to just the one correct match out of th
Re: (Score:2)
No, partial hashes can't be brute forced, you have nothing to verify it against that would match the original full hash.
Nonsense, of course it can.
Having full data hash means nothing given full hashes themselves are not even full representations of the underlying data.
As an example, using plaintext "12345" results in an sha1 of "8CB2237D0679CA88DB6464EAC60DA96345513964"
I send you just "8CB2237D0679CA88"
If I try 12345 and the first 8 bytes of the hash output matches what you sent me then I can take that match to the bank.
A, the above is not a valid sha1 hash to check "12345" against.
Irrelevant.
B, there are billions of plain text that will sha1 hash such that they begin with the above segment.
No, there are an infinite number of plain texts that will sha1 hash such that they collide with the entire non-truncated hash let alone truncated version.
However the number of plaintexts likely to be passwords people are likely to c
Re: (Score:2)
Re: (Score:2)
You can try it but it'll probably not be the password.
I provided figures to backup my claims. You are just guessing.
Brute forcing an attack like this is going to generate millions of false positives
Only in a universe where 2^20 to 2^40 is a higher number than 2^64.
And you know what even if we stipulate we are living in such a universe the fact that you've worked set of possible values of a password down to a ~20 bit search space is a massive win for the attacker.
and at the same time will take years, with current computers, to complete. So it's not a viable or sensible approach.
No more or less viable than current crop of password guessing tools which to date have proven to be EXTREMELY effective.
Cryptohashing is the best technology we have and there's a reason why it's recommended as the default way of storing passwords in an environment in which password recovery isn't required.
The only thing this has proven to be is completely useless a
Re: (Score:2)
Just responding in general to the claim that masking of a password with cryptographically secure truncate function e.g. hashing is easy to break by brute force when an attacker knows certain amount of bits of the password hash. This is false!
This is absolutely true. The average password has only 40 bits of entropy. Some passwords on either ends of the distribution have substantially less and others substantially more.
Checking your password in this way by handing a truncated hash to a complete stranger absolutely gives away 20 bits of entropy.
Let me first explain, that success of the attack depends on one primal factor: length of a password. If your password is anything less the 8 characters this is relatively easy to break today and if you're using password this short consider it has been already broken. In this case, there is no need for Firefox (or somebody else) to present to the attacker a truncated digest of the hash of your password in order for him to try to break it. An attacker probably already has all possible combination of your password in different hash algorithm digests. This is called rainbow table.
Welcome to reality where the AVERAGE password has 40 bits of entropy and despite all the policy, lectures and coddling people still use weak passwords. Weak in the sense they are completely incapable of w
Re: (Score:2)
Of course, if your partial on
Re:In other words ... (Score:5, Interesting)
The third party site in question, you don't enter your password, you only enter the login, and it tells you if that login has been compromised.
They have a separate service where you don't enter your login, you only enter the password, and it tells you if the password was ever included in a breach.
In the Firefox integration, it appears that Firefox is getting the lists of breached accounts and passwords from the third party site, and then comparing it locally within the browser.
The scary part isn't about the third party in this case, it is that the new Firefox password manager is something that Mozilla wants to add "premium features" to. Egads.
Re: (Score:3)
The third party site in question, you don't enter your password, you only enter the login, and it tells you if that login has been compromised.
Well. I just went to the website in question and saw two options. There may have been more, but the two I saw right away were 'enter a domain name' to get a report on breaches for that domain, and "enter a password" to get told how many times that password is in their breach database. To get the domain report, you have to prove that you own the domain, which almost certainly involves entering more data.
In the Firefox integration, it appears that Firefox is getting the lists of breached accounts and passwords from the third party site, and then comparing it locally within the browser.
The database of breached login/passwords is HUGE. Someone else reported trying to get it small and it was
Re: (Score:2)
You'll be leaking some minor metadata linking your browser info to the domain, but you are not asked directly for any PII. If you do that step, what you get back a few seconds after it's verified is a table of all the kno
Re: (Score:2)
The domain stuff has nothing to do with this story, though. So ignore that.
The two "things" are inputting an email address to see if it was included in a breach, or inputting a password to see if that password was included in a breach.
Re: (Score:2)
Only idiots are going to get bit by that, because the only reason to input a password is for research.
Don't reuse passwords. Done, now you have no reason to input a password to see if it was in the breach!
Re: (Score:2)
You can use their API to check your password without sending it to them. Instead you send just a hash.
For checking your domain the usual way of proving ownership is to deposit a text file with a random string in it on the web server, which the other site can then check.
Re: (Score:2)
Firefox will be sending all your saved login/password details off to a third party to be tested.
No, they will be sending a hash of the password to a third party.
HIBP has the non-salted password hashes next to the plain text password, because they download them from the darknet like anyone and everyone else can.
If your hash is in their database, you are fucked already so it doesn't matter.
If your hash isn't in the database, it won't matter that it was sent because it's a non-reversible hash function, and doesn't include enough data to reconstruct the original.
There is no risk of the password being comp
Re: (Score:2)
because it's a non-reversible hash function
Every hash function can be brute-forced. Some are much easier than others. Some will require advances in computing so it will be a few years. But all of them are sending data off to a third party site that was never intended to be sent there, and requires trusting that site not to use the data for something else.
Either /. readers are paranoid or they are not.
Re: (Score:2)
Re: (Score:2)
This means that the answer to "Is this hash in your database?" is probably correct - the odds are only 1/(2^128) that an individual stored hash will be matched by an arbitrary candidate partial hash.
However, it also means that if someone intercepts the query and tries to find hashes that match the partial hash, they'll end up with 2^128 possible candidates all of which hash to something that starts with the partial hash.
The list of possible candidates is not 2^128 it's INFINITE. SHA-1 digests can be generated over a completely unbounded field of inputs. Infinity / 2^128 is still INFINITY.
Re: (Score:2)
Re: (Score:2)
You should read up on how HaveIBeenPwned works:
I read up on how it works by looking at the code on their web site. I see no encryption function, no hash. I also see that the page works fine with no-script blocking scripts.
Now, it is possible, I suppose, that when the page posts the unhashed string 'fragglerock' because it can't hash it, and the server returns the answer "you're pwned" it is because one of their hashed passwords contains that string, but I seriously doubt it.
The important point that people seem to be missing in their haste to teach me
Falls back to original API (Score:2)
If you have enabled JavaScript for that page, the form uses the current k-Anonymity API. If you have disabled JavaScript for that page, the form ends up falling back to the original API. It also displays a message in the latter case: "You've disabled JavaScript! If you submit a password in the form below, it will not be anonymised first." I'm guessing that Obfuscant's complaint is that it allows noscript users to use the form in the first place.
Re: (Score:2)
This could be done safeish (Score:2)
Re:This could be done safeish (Score:4, Insightful)
to grab all passwords/hashes associated with your account names, the browser will have to send all your account names (and probably other details like email addresses) to the database site.
THAT alone is information that should be kept private.
It allows the remote site to establish a connection between ALL of your different accounts and email addresses: fred at example.com is the same person as joe at another.example.com
That's not only valuable (i.e. sellable) personal information, it directly undermines the fairly common strategy of providing different information (e.g. email addresses, names) to different web sites.
This will compromise the privacy and safety of those who make an effort to avert or subvert profiling (e.g. by using umatrix, ublock origin, decentraleyes, canvas blocker and many other plugins)
---
As long as this anti-feature can be turned off (or, better yet, is off by default - but that's unlikely given mozilla's history of stupid decisions) I don't really give a fuck. Anyway, I'm pretty sure that the debian package of firefox will have it disabled - they've done that for previous FF idiocies.
Re: (Score:2)
Re: (Score:2)
As soon as site X has a breach, Firefox can know about it.
Oh. How? Magic? Doesn't it take a release of the data from that breach to enter the HIBP database, and then Firefox can find out by asking HIBP? If I break into site X and steal all their account data but never put it up for public access, then HIBP won't know about it -- until X tells them, if ever.
It can have a list of all the sites that have been breached (that database is not large). It can then check, "oh, you just logged into site X," and give you a warning.
Well, it could do that. But that's not what the summary (and TFA) say right at the very start: "Starting in Firefox 70, Mozilla aims to have the browser report when any of your saved logins were found in data br
Re: This could be done safeish (Score:2)
Re: (Score:2)
Nope, all it needs to do is send the first 5 digits of the SHA-1 hash. The site then returns a list of all matching hashes and the client checks them locally.
about:config (Score:1)
Can I turn this off?