1000 is a very low number for PBKDF2 iterations. OWASP recommends 10 000, and also recommends using Argon2 instead. Apple does 10 million.
Private by Design: How We Built Firefox Sync
111–120 of 180 posts
Re: Private by Design: How We Built Firefox Sync
#112Cool but there is a lot more that can be done to improve a browser privacy by fighting fingerprinting. I.e. provide standardized sets of data about the host system via JS APIs: only list a standard set of fonts (+ those a user consciously chooses to expose), a most common display resolution that is less or equal to the real display resolution of the machine, obfuscate canvas/webgl/cache response time etc.
Extensions API should also get optimized in a way so privacy-enchancing extensions (like Ghostery, Adblock Plus and NoScript) would work faster.
And there is a favourite extension of mine called "self destroying cookies" that currently is blocked for sending user data to remote servers unnecessarily, and potential for remote code execution - I believe it's actual functionality (not sending user data to remote servers but what it is meant for - one-click whitelisting particular domains and only keeping cookies for these while deleting cookies for others as you close them) should be built into the browser.
Re: Private by Design: How We Built Firefox Sync
#113Earlier quoted context omitted.
You can verify hash with others or compile it yourself.
Did you personally, and at least one other trusted party, sign off on every single commit, or are you trusting Mozilla? Where did you get the hash you're comparing against? Firstly, no matter what you're trusting the developers of the software you're running on your computer. Secondly, the software (and/or its hash), just like this JavaScript, is delivered to you in a verifiably secure fashion i.e. SSL. What's the di…
> Do you have automatic updates running for Firefox …
No.
> … or any piece of software on your computer?
Also, no. But even did I, there’s a world of difference between automatic updates from e.g. Debian and automatic updates from Mozilla.
Re: Private by Design: How We Built Firefox Sync
#114Earlier quoted context omitted.
Trusting the binary is a one-time effort. Here you have to trust the JS everytime you authenticate.
For this use case, authenticating is a one-time effort as well, per browser. If you're authenticating again, you're almost certainly doing it on a different device/browser, at which point you'd have to verify the new browser binary anyways.
Sign-ins to Firefox Accounts (used to access Mozilla services as web pages) don’t expire after some time? I didn’t know that.
Re: Private by Design: How We Built Firefox Sync
#115> Another interesting wrinkle is that Brave does not keep track of how many or what types of devices you have. This is a nuanced security trade-off: having less information about the user is always desirable… The downside is that Brave can’t allow you to detect when a new device begins receiving your sync data or allow you to deauthorize it. We respect Brave’s decision. In Firefox, however, we have chosen to provide this additional security feature for users (at the cost of knowing more about their devices).
Why not store a hash of the user's devices instead?
Re: Private by Design: How We Built Firefox Sync
#116Sadly, I believe that Firefox Accounts — upon which Firefox Sync is built — are insecure in execution. The security of the whole system relies on keeping your password secret from Mozilla, but as you can see when accessing https://accounts.firefox.com/oauth/signin?scope=profile&clie... your browser downloads the JavaScript it will use to derive your authentication token from Mozilla. There’s nothing stopping Mozilla…
If you have that much distrust you shouldn't run Firefox at all since every page you load would be at risk. I doubt that any browser would match such an high bar
Not really, since one can verify the Firefox code oneself, or hire others to do it, or rely on the fact that it’s a matter of public record and do forensics analysis after the fact should one be compromised.
But a target JavaScript file sent only to oneself a single time … that’s practically impossible to validate or prove.
Re: Private by Design: How We Built Firefox Sync
#117People who still use Chrome nowadays probably haven't heard of Firefox' tree style tabs plugin.
That's nice for those who use a lot of tabs, yes. But what I really appreciate is reader view (F9). What I long for is Chrome's page translation.
Re: Private by Design: How We Built Firefox Sync
#118Earlier quoted context omitted.
Did you read the article? The system is designed so that an authentication token is derived from the password, and this token, rather than the password itself, is authenticated against on the server. Since the encryption key can not be derived from the authentication token, this shields the content of the encrypted data the server stores from itself. GP rightly noted that deriving the authentication token with code s…
> unless user has the time to verify the JavaScript they are served every time they log in. Which is once per install, the same amount of times then user would have to verify the native code
There's actually a great difference, because for binary distribution it simply suffices that the user verify the cryptographic hash of the binary they downloaded. Then they can be confident that they were served the correct publicly distributed binary, and not a subverted version.
JavaScript by its very nature can not be easily, if at all, verified. Even if you verify that you are being served the same code as other users and the code is not subverted at one point in time, it's very much expected that the code may change at any time at the web developer's discretion. This is also probably the very reason why Mozilla implemented it like this (so that they can update the Sync experience branding without updating the browser.)
Even if you hard-coded the signature of the JavaScript library file responsible for the cryptographic operations in the binary, browser DOM by itself would require modifications so that any other UI logic script in the page would not be able to sniff your password as you enter it..
Re: Private by Design: How We Built Firefox Sync
#119Earlier quoted context omitted.
How could this even possibly be mitigated, though? At some point you have to trust something , right? This argument could extend all the way down to your OS, chipset, whatever. Unless you've built every part of your machine from scratch it's always going to rely on trusting a component you know nothing about.
Trusting the binary is a one-time effort. Here you have to trust the JS everytime you authenticate.
Even one-time, comparing the hash of a git commit or an installer is annoying but practically doable. I'd have no idea how to safely do something like this for a website. And I for sure ain't able to audit those ~200kb js by myself.
Re: Private by Design: How We Built Firefox Sync
#120Earlier quoted context omitted.
Hi, Firefox Accounts developer here. You're correct in your understanding that that login flow is ultimately driven by a webpage, and this is a deliberate trade-off that we made in the interests of reach and usability of the system. It's certainly a trade-off that not everyone is comfortable with, but we're confident it's the right one for the majority of our users. You can read some previous discussions on the topic…
>The reason the login form is delivered as web content is to increase development speed and agility You saved some sprints but invalidated the purpose of the project. Very agile. >Ultimately I think we can have web content from accounts.firefox.com be just as trustworthy as, say, a Mozilla-developed addon which might ship in the browser by default, which is a pretty high bar. We're not there yet, but it seems worth p…
A more complete comment from rfk on the bug tracker:
> The reason the login form is delivered as web content is to increase development speed and agility. You're right that web content has a larger potential attack surface than code that's built into the browser, but using web content also brings other kinds of security benefit that may not be obvious. That agility meant that during the incident in [1] we were able to respond quickly and effectively to protect users data, and to roll out an updated login flow containing an email confirmation loop. It means that when we ship two-factor authentication over the coming weeks, it will be immediately available to all users on all platforms. It means we can address Bug 1320222 in a single place and be confident we won't lock out older devices. And it means we can easily bring new Firefox apps like Lockbox into the Firefox Accounts ecosystem.
> Our approach has been to embrace the benefits of web content while trying to reduce the potential attack surface as much as possible. That includes some simple things like hosting the web content on its own server to reduce exposure to application server bugs, and shipping default HSTS and HPKP settings for the accounts.firefox.com domain. It also includes some in-browser measures to prevent interference with FxA web content, such as (the currently private) Bug 1415644. As a future step I'd like to see us implement content-signing for accounts.firefox.com and have it enforced by the browser, following the example of things like Bug 1437671.
> Ultimately I think we can have web content from accounts.firefox.com be just as trustworthy as, say, a Mozilla-developed addon which might ship in the browser by default, which is a pretty high bar. We're not there yet, but it seems worth pursuing to try to get the best of both worlds.