3 ms·

I must warn against running only Sync server and relying on Mozilla-hosted Firefox Accounts as there is a way for Mozilla or whoever has access to their servers

I must warn against running only Sync server and relying on Mozilla-hosted Firefox Accounts as there is a way for Mozilla or whoever has access to their servers (served with NSL or whatever force they can't resist) to figure out your plaintext password when you log in to the service. The issue is, Firefox Accounts login page is served from the network, and you can only blindly trust that the password you type is only passed to a secure JavaScript KDF and not sent anywhere. I really don't know why Mozilla implemented it this way and login UI is not a part of the browser itself. --- Shameless plug follows. I didn't like how Mozilla implemented this (a mess of languages and servers, way too complicated to my tastes) and started my own project (Python/Django) that tries to implement standalone Accounts and Sync services in a single package, as small and as simple as it's possible. It's not usable yet - I didn't have time to work on this any seriously, and over the last year had only spent a few weekends. I can't vouch for its security - on the contrary, it looks somewhat fragile to me and whoever decides to try it must proceed with extreme caution. But I have Accounts part working and some parts of Sync too, so, I guess, someone may consider at least some pieces code useful: https://bitbucket.org/drdaeman/firesync https://bitbucket.org/drdaeman/firesync

vladikoff 11y ago
> I really don't know why Mozilla implemented it this way and login UI is not a part of the browser itself. How does making the login part of UI help, would you blindly trust part of native UI instead? the password is secured with JS locally on the client and you can clearly and easily inspect all the requests that firefox makes via dev tools.
- drdaeman 11y ago
  Why blindly? I can audit the browser's code, lock the updates and know it's reasonably secure against this kind of attack. With the current implementation, with the page served from the network, there's no reasonable way to check that I'm not suddenly served with something malicious. I mean, I could be served a different page next time. Well, of course, to be precise, after auditing the in-browser login dialog code I would also have to check the XUL and JS engines that it's using, the compiler that was used to produce Firefox, the system libraries, kernel, firmware and CPU microcode and so on. But that's another story.
  - tokenizerrr 11y ago
    Well, you could run a proxy locally, force all traffic through that and serve your own version of the page.
    - drdaeman 11y ago
      It's using HTTPS - and while I haven't actually tried to MitM it, I suspect that since it's served from Mozilla domain, the certificate must be pinned. But you're right - it may be not simple to do (or maybe I'm mistaken here) but it's certainly possible (Firefox is FOSS, so as a last resort measure it can be modified to ignore any pins). Thanks for the suggestion.
      - tokenizerrr 11y ago
        Browsers allow you to override pinned certificates with locally installed ones.
- wtbob 11y ago
  > How does making the login part of UI help, would you blindly trust part of native UI instead? Because Mozilla can — and can be compelled to — alter the UI they serve at any time, while your browser UI is static and can be verified. The current design is horribly, horribly untrustworthy. One simply cannot rely on Mozilla to stay honest; any government it is subject to may force it to snoop your password.
xorcist 11y ago
I understand the urge to write your own Accounts server, but I found Sync to be fairly simple and straightforward. It's just a small Python script using SQLAlchemy. Could anything built on Django really beat that? How well did you find the protocol to be documented?
- drdaeman 11y ago
  Yes, Sync is somewhat reasonable. I've started with Accounts and immediately decided on bundling Sync into the same project because I wanted it so a single server would be completely self-sufficient. The protocol is relatively well-documented when it comes to overall picture, but some nifty details are missing and have to be figured out by reading the source code and debugging. For example, usually keys and tokens in responses are hex-encoded but when issuing the token for sync server (/1.0/sync/1.5) you have to return the raw binary string. I've struggled for a good hour before I figured out why I'm getting weird tokens and authentication fails. I believe most issues with documentation could be solved by having a full Accounts+Tokens+Sync session transcripts (annotated with internal state information and some comment about what's going on), which could both serve as a test vector and a good example of real-word use case. My overall impression is that Mozilla Services are awfully over-engineered, though. It could've been much simpler than this if only Mozilla wouldn't invent their own unique proprietary service, but try to reuse existing solutions as much as possible. Like, say, WebDAV - it'd probably fit and Sync could require literally zero lines of new code.

vladikoff 11y ago

> I really don't know why Mozilla implemented it this way and login UI is not a part of the browser itself. How does making the login part of UI help, would you blindly trust part of native UI instead? the password is secured with JS locally on the client and you can clearly and easily inspect all the requests that firefox makes via dev tools.

drdaeman 11y ago
Why blindly? I can audit the browser's code, lock the updates and know it's reasonably secure against this kind of attack. With the current implementation, with the page served from the network, there's no reasonable way to check that I'm not suddenly served with something malicious. I mean, I could be served a different page next time. Well, of course, to be precise, after auditing the in-browser login dialog code I would also have to check the XUL and JS engines that it's using, the compiler that was used to produce Firefox, the system libraries, kernel, firmware and CPU microcode and so on. But that's another story.
- tokenizerrr 11y ago
  Well, you could run a proxy locally, force all traffic through that and serve your own version of the page.
  - drdaeman 11y ago
    It's using HTTPS - and while I haven't actually tried to MitM it, I suspect that since it's served from Mozilla domain, the certificate must be pinned. But you're right - it may be not simple to do (or maybe I'm mistaken here) but it's certainly possible (Firefox is FOSS, so as a last resort measure it can be modified to ignore any pins). Thanks for the suggestion.
    - tokenizerrr 11y ago
      Browsers allow you to override pinned certificates with locally installed ones.
wtbob 11y ago
> How does making the login part of UI help, would you blindly trust part of native UI instead? Because Mozilla can — and can be compelled to — alter the UI they serve at any time, while your browser UI is static and can be verified. The current design is horribly, horribly untrustworthy. One simply cannot rely on Mozilla to stay honest; any government it is subject to may force it to snoop your password.

xorcist 11y ago

I understand the urge to write your own Accounts server, but I found Sync to be fairly simple and straightforward. It's just a small Python script using SQLAlchemy. Could anything built on Django really beat that? How well did you find the protocol to be documented?

drdaeman 11y ago
Yes, Sync is somewhat reasonable. I've started with Accounts and immediately decided on bundling Sync into the same project because I wanted it so a single server would be completely self-sufficient. The protocol is relatively well-documented when it comes to overall picture, but some nifty details are missing and have to be figured out by reading the source code and debugging. For example, usually keys and tokens in responses are hex-encoded but when issuing the token for sync server (/1.0/sync/1.5) you have to return the raw binary string. I've struggled for a good hour before I figured out why I'm getting weird tokens and authentication fails. I believe most issues with documentation could be solved by having a full Accounts+Tokens+Sync session transcripts (annotated with internal state information and some comment about what's going on), which could both serve as a test vector and a good example of real-word use case. My overall impression is that Mozilla Services are awfully over-engineered, though. It could've been much simpler than this if only Mozilla wouldn't invent their own unique proprietary service, but try to reuse existing solutions as much as possible. Like, say, WebDAV - it'd probably fit and Sync could require literally zero lines of new code.