3 ms·
What attack vector would be mitigated by switching to a stronger hashing scheme for this specific use case? And are there other mitigations that exist for this
by delroth 9y ago
What attack vector would be mitigated by switching to a stronger hashing scheme for this specific use case? And are there other mitigations that exist for this attack vector that would be more appropriate?
To me is seems that this feature of browsers is really only meant as a protection against non-advanced attackers accessing an unlocked computer. For this scenario, having a stronger hash would do nothing.
Having a stronger hash would mitigate against exfiltration off the device by malware, but if malware can exfiltrate files off your device it's very likely they can e.g. read your passwords from memory, or keylog until the next time you input the password. It would also mitigate against someone being able to dump your password db off your filesystem if they get physical access to your computer, but full disk encryption does that better, and also protects all the rest of your personal data that's stored on the device.
Historically this is why Chrom{e,ium} has been resisting introducing this feature. Its uses are very limited against "real" attackers.
Mozilla spending time on cool tech rather than dumb migrations between password schemes that provide no value seems like a good tradeoff.
- staticassertion 9y agoA lot of people have problems modeling threats. For example, in the article: > Anybody who ever designed a login function on a website will likely see the red flag here A login function on a website and a master password for your local system have very different threat models. Applying one to the other is a helpful heuristic but ultimately leads you in the wrong direction. If we ask 'who is the attacker in the situation' the answer for both is very different. The attacker we worry about in web logins is generally remote. The attacks we are primarily concerned with are: a) They can dump hashes, often through SQL injection b) They can attempt to bruteforce passwords remotely With a local attacker for a local password db we have to assume that the attacker is executing locally on the system. Our threat model generally does not include the ability to exfiltrate the db in an encrypted state - at least, that isn't where you start. Threat modeling is critical to security - there are a billion things like this that Could Be Better but we use threat modeling to prioritize. At some point someone asked "who are we protecting against?" and the answer was "a very, very specific type of attacker that we do not see often". And so yes, they focused elsewhere. edit: To be clear, I don't work for Mozilla and actually have no idea if my "at some point" comment is accurate! I'm just saying that's generally how it goes. It could easily be the case that this just slipped through the cracks or some such thing. I do not know Mozilla's internal threat model, I can only guess.
- joveian 9y agoFor someone without disk encryption (many people, maybe most?), the encrypted database can be acquired if the machine is stolen while off. I would very much expect setting a master password to protect against that (at least unless other unencrypted personal information is used to take over accounts). With remote compromise of the system it is presumably possible to access the key if the browser is running via debuggers, it is at least a bit more work.
- staticassertion 9y ago> For someone without disk encryption (many people, maybe most?), I would say they should really use FDE. An attacker with that level of control can do a lot - FDE is designed for this type of attacker. But yes, that is one attacker that this would protect against. > With remote compromise of the system it is presumably possible to access the key if the browser is running via debuggers, it is at least a bit more work. No need for debuggers, though that would certainly be one way to do it. This is not hard at all for an attacker, we see attackers hijacking processes all the time. Forcing the attacker to do 'a little more work' is not really the best place to spend time. Firefox's threat is, in my opinion, malicious web pages, malicious extensions, or malicious use of/ abuse of their services etc (can't even imagine what abuse they see for their recent file sharing system). These probably take a significant amount of time and resources - these are the attackers they are probably dealing most days, if I had to guess. An attacker with unlimited offline access to an unencrypted hard drive seems pretty out of scope and better solved by the OS (I believe modern Windows and OSX systems actually FDE by default now). An attacker with full execution on the system also seems out of scope. They could probably fix this master password thing pretty easily, it sounds simple enough and they might just because it's been called out, but my expectation is that this would probably not be a high priority otherwise. I would also be concerned about users making the assumption that if they use a master password that they are safer from attackers - that it 'raises the bar', when it is unlikely to meaningfully for almost any attacker. A false sense of security is not a good thing. I'm not a browser developer so I could be totally off and this could all be stuff they're super concerned about.
- 9y ago
- yborg 9y agoThe argument that "security is pointless unless it can prevent <nation-state> from obtaining the data" is a really tiresome strawman. If you force an adversary to have to keylog for data of interest you already have substantially increased the complexity of bulk attacks, which is the real threat for most users - mass password farming sweeps that can provide easy access to people's entire digital presence in one go.
- deleted 9y ago[deleted]
- staticassertion 9y ago> The argument that "security is pointless unless it can prevent <nation-state> from obtaining the data" is a really tiresome strawman. This sentence is a strawman as you've invented the opponent's argument (literally no one has mentioned the NSA), just for what it's worth. Your assertions that: a) An attacker would have to rely on keylogging b) Keylogging is a substantial barrier for attacker are unfounded.
- palant 9y agoYes, it is stupid to leave your computer unlocked but it happens all the time in every workplace. If spending a minute pulling two files from an unlocked system is all it takes to get access to all of person's passwords - that's scary. And this would be trivial to mitigate, NSS already has everything necessary. Note that full disk encryption offers exactly no protection if you forgot to lock your computer. Not that full disk encryption is common, almost nobody does that.