8 ms·

Sadly, 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

by rauhl 8y ago

Sadly, 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&client_id=3a1f53aabe17ba32 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 from serving all users malicious JavaScript which sends the password in plaintext; there’s nothing stopping Mozilla from serving 1% of users, or even a single targeted user. They could be forced to do so by a government with control over them; presumably some number of their employees could likewise be suborned by a state or criminal enterprise. This should all be done by code compiled into the browser and triggered from the UI, rather than JavaScript run within a web page. Yes, Mozilla could also serve malicious Firefox binaries, or even publish malicious Firefox source, but the odds of someone in the world noticing that are significantly higher than a single targeted individual or small number of targeted individuals noticing. Or maybe I’m missing something? I don’t think I am, though: that Firefox Account page is just HTML served from accounts.firefox.com; it’d be easy enough to just make it a simple form submission and capture the user’s password. And with the password, the security of the system fails completely: it’s simplicity itself to decrypt all stored data with it.

riquito 8y ago
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
- nwah1 8y ago
  There was a substantive suggestion for improvement... to include the javascript calls to grab the authentication inside the source code, rather than a remote call. Maybe an intermediate solution would be to use integrity hashes on the remote calls.
  - vedantroy 8y ago
    I don't think the Javascript for authentication can be client-side. Authentication of passwords must be done on the server.
    - vesinisa 8y ago
      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 served by the server at log-in time renders most of the security architecture of the system rather moot, unless user has the time to verify the JavaScript they are served every time they log in.
      - maccard 8y ago
        > 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
        vesinisa 8y ago
        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..
- mmirate 8y ago
  On larger Linux distributions, the trust is less with Mozilla and more with the distro-package maintainers - use of dynamically remote-loaded JavaScript here shifts the trust back to Mozilla; if you trust your maintainers but not Mozilla, then this is a problem.
  - AsyncAwait 8y ago
    You really need to trust both. A browser vendor has so many layers to attack you, if they're malicious, that there's no way around it. Same for package maintainers.
- rauhl 8y ago
  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.
  - IshKebab 8y ago
    Most people download Firefox binaries directly from Mozilla. They can't verify the code (even if they knew how).
kbumsik 8y ago
So are you suggesting to use a private API to login to accounts.firefox.com? And what about using accounts.firefox.com in other browsers?
rfk 8y ago
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 in these bugs (and additional suggestions/feedback therein is definitely welcome): * https://bugzilla.mozilla.org/show_bug.cgi?id=1034526 * https://bugzilla.mozilla.org/show_bug.cgi?id=1447656
- garmaine 8y ago
  Why not ship the password handling logic in the Firefox binary?
- CoolGuySteve 8y ago
  This is very interesting and thanks for clarifying, but if you concede that there is a security trade-off here for the sake of usability, then isn't this, by definition, not "Private by Design". As in: you chose other principals to guide your design other than privacy?
  - Benjamin_Dobell 8y ago
    The privacy is at least verifiable. In the sense that users can at least look at the implementation themselves, and (granted with some difficult) potentially detect changes. This is much better than simply sending your password off to a third-party and having to trust that the company is doing what they say they're doing.
  - danShumway 8y ago
    Nobody purely chooses privacy or security to guide their design. An implementation of Firefox sync that was purely, 100% private by design would be airgapped, it wouldn't sync over a network. Arguably, a private by design implementation of Firefox sync wouldn't even exist. You significantly increase your number of attack vectors by making your session available on multiple devices. What happens if your Android phone is compromised? Better to only have your session on one device. Obviously I'm being hyperbolic here, but the point I'm getting at is that security isn't black and white, and you will always be making tradeoffs for usability, no matter what the context is. What that means for "private by design", I dunno. Maybe it's just a buzzword. Maybe it's just a matter of degree. Other people can debate that if they really want to. But I do know that the moment you put doors on your house, it's less secure than it used to be. The actual valuable question is, "is Mozilla's tradeoff good enough for usability that it justifies the decrease in security?" I'm not sure whether the answer to that is yes or no.
IshKebab 8y ago
If Mozilla wants your passwords there's nothing to stop them adding code to Firefox itself that detects when you are typing your password in and sends it to them. It could be limited to just you in that case too. This is really to protect against two things: 1. Legal requests for your data. It's actually not really been tested whether or not the government can force an entity to insert a backdoor for a specific user or not. I think everyone hopes that can't do that but does anyone really know? 2. Data breaches.
- rlpb 8y ago
  > If Mozilla wants your passwords there's nothing to stop them adding code to Firefox itself that detects when you are typing your password in and sends it to them. It could be limited to just you in that case too. Users who consume Firefox from distributions, rather than directly from Mozilla, are much better protected from this. "Nothing to stop" is not true in this case.
  - IshKebab 8y ago
    Sure but then you're just trusting a different party (the packagers). Now you have to trust two groups of people.
joekrill 8y ago
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.
- NewEntryHN 8y ago
  Trusting the binary is a one-time effort. Here you have to trust the JS everytime you authenticate.
  - fro0116 8y ago
    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.
    - eadmund 8y ago
      Sign-ins to Firefox Accounts (used to access Mozilla services as web pages) don’t expire after some time? I didn’t know that.
  - Faark 8y ago
    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.
  - IshKebab 8y ago
    So you never update Firefox? For most users it automatically updates itself.
  - joekrill 8y ago
    But my point is you also have to trust that your underlying OS, or chipset, or even some other software on your computer doesn't have some way to thwart the entire effort. If the thing you're using the do your verification is itself compromised, then you're just as screwed.
deleted 8y ago
[deleted]

by rauhl 8y ago

riquito 8y ago

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

nwah1 8y ago
There was a substantive suggestion for improvement... to include the javascript calls to grab the authentication inside the source code, rather than a remote call. Maybe an intermediate solution would be to use integrity hashes on the remote calls.
- vedantroy 8y ago
  I don't think the Javascript for authentication can be client-side. Authentication of passwords must be done on the server.
  - vesinisa 8y ago
    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 served by the server at log-in time renders most of the security architecture of the system rather moot, unless user has the time to verify the JavaScript they are served every time they log in.
    - maccard 8y ago
      > 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
      - vesinisa 8y ago
        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..
mmirate 8y ago
On larger Linux distributions, the trust is less with Mozilla and more with the distro-package maintainers - use of dynamically remote-loaded JavaScript here shifts the trust back to Mozilla; if you trust your maintainers but not Mozilla, then this is a problem.
- AsyncAwait 8y ago
  You really need to trust both. A browser vendor has so many layers to attack you, if they're malicious, that there's no way around it. Same for package maintainers.
rauhl 8y ago
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.
- IshKebab 8y ago
  Most people download Firefox binaries directly from Mozilla. They can't verify the code (even if they knew how).

kbumsik 8y ago

So are you suggesting to use a private API to login to accounts.firefox.com? And what about using accounts.firefox.com in other browsers?

rfk 8y ago

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 in these bugs (and additional suggestions/feedback therein is definitely welcome): * https://bugzilla.mozilla.org/show_bug.cgi?id=1034526 * https://bugzilla.mozilla.org/show_bug.cgi?id=1447656

garmaine 8y ago
Why not ship the password handling logic in the Firefox binary?
CoolGuySteve 8y ago
This is very interesting and thanks for clarifying, but if you concede that there is a security trade-off here for the sake of usability, then isn't this, by definition, not "Private by Design". As in: you chose other principals to guide your design other than privacy?
- Benjamin_Dobell 8y ago
  The privacy is at least verifiable. In the sense that users can at least look at the implementation themselves, and (granted with some difficult) potentially detect changes. This is much better than simply sending your password off to a third-party and having to trust that the company is doing what they say they're doing.
- danShumway 8y ago
  Nobody purely chooses privacy or security to guide their design. An implementation of Firefox sync that was purely, 100% private by design would be airgapped, it wouldn't sync over a network. Arguably, a private by design implementation of Firefox sync wouldn't even exist. You significantly increase your number of attack vectors by making your session available on multiple devices. What happens if your Android phone is compromised? Better to only have your session on one device. Obviously I'm being hyperbolic here, but the point I'm getting at is that security isn't black and white, and you will always be making tradeoffs for usability, no matter what the context is. What that means for "private by design", I dunno. Maybe it's just a buzzword. Maybe it's just a matter of degree. Other people can debate that if they really want to. But I do know that the moment you put doors on your house, it's less secure than it used to be. The actual valuable question is, "is Mozilla's tradeoff good enough for usability that it justifies the decrease in security?" I'm not sure whether the answer to that is yes or no.

IshKebab 8y ago

If Mozilla wants your passwords there's nothing to stop them adding code to Firefox itself that detects when you are typing your password in and sends it to them. It could be limited to just you in that case too. This is really to protect against two things: 1. Legal requests for your data. It's actually not really been tested whether or not the government can force an entity to insert a backdoor for a specific user or not. I think everyone hopes that can't do that but does anyone really know? 2. Data breaches.

rlpb 8y ago
> If Mozilla wants your passwords there's nothing to stop them adding code to Firefox itself that detects when you are typing your password in and sends it to them. It could be limited to just you in that case too. Users who consume Firefox from distributions, rather than directly from Mozilla, are much better protected from this. "Nothing to stop" is not true in this case.
- IshKebab 8y ago
  Sure but then you're just trusting a different party (the packagers). Now you have to trust two groups of people.

joekrill 8y ago

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.

NewEntryHN 8y ago
Trusting the binary is a one-time effort. Here you have to trust the JS everytime you authenticate.
- fro0116 8y ago
  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.
  - eadmund 8y ago
    Sign-ins to Firefox Accounts (used to access Mozilla services as web pages) don’t expire after some time? I didn’t know that.
- Faark 8y ago
  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.
- IshKebab 8y ago
  So you never update Firefox? For most users it automatically updates itself.
- joekrill 8y ago
  But my point is you also have to trust that your underlying OS, or chipset, or even some other software on your computer doesn't have some way to thwart the entire effort. If the thing you're using the do your verification is itself compromised, then you're just as screwed.

deleted 8y ago

[deleted]