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

> 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.

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.

Well, you could run a proxy locally, force all traffic through that and serve your own version of the page.

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.

Browsers allow you to override pinned certificates with locally installed ones.

> 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.

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?

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.

A lot of people don't realise but the weakest point in their setup (from a security POV) is things like the password used on their browser sync account. There is a huge amount of responsibility on the sync service providers. Firefox literally knows everything about me and my accounts. Hell it knows passwords for accounts I don't even remember opening.

Self hosting the sync server makes a lot of sense. I think I will spend some time doing this over the Christmas holiday.

Personally I never let my browser remember my passwords, synchronized or not, precisely because it's a huge point of failure. I still think it's valuable for my history to be securely synchronized, but my Firefox Sync account does not have my passwords. Even though I do trust Firefox Sync and I have a very secure password, so this has nothing to do with that. But imagine that you leave your laptop open, then somebody passing by can get any password just by going to any website in your browser. And of course, with an open laptop, you can argue that you can be compromised regardless, as that passerby could install a keylogger. But security is all about raising costs for potential attackers.

Lately I've been a 1Password user, so that has made things easier. But even before that I've had a system of generating unique passwords and I could tolerate the pain of a fresh browser instance, because "remember me" works just fine. The only account you should not lose access to is your email account, because that email account can be used to recover the passwords for every other account. It's also the one account for which you need a really strong password and preferably 2-factor authentication.

Personally, I find it more convenient (and possibly safer) to use blueproximity to auto-lock my laptop if I forget to manually do so.

In the post they state that Mozilla never sees your password and that content is encrypted locally, so Mozilla doesn't actually appear to know very much about you at all. See the link in the post: https://blog.mozilla.org/services/2014/05/08/firefox-account...

I meant in the context that if somebody gets your sync password they get everything.

Well to be honest, if somebody gets the password to your email service, they get everything as well.

That's exactly the issue multi-factor authentication was invented for.

Yes. Which is something Firefox doesn't offer.

It's weird for me that the article headline is "Self-hosting Firefox Sync 1.5" but the author basically just says, read the README and that's it. I had a really hard time setting it up https://jeena.net/firefox-sync-15 full of misunderstandings and misconceptions.

I have been using xmarks for years and switched to firefos-sync a while ago, so far so good. I did not know the code is open and I can self-host it until now, will try that. I do agree that we shall also own the firefox-sync login/password and it should have nothing to do with mozilla/firefox.

even better if it can support other browsers, but it seems I'm using firefox everywhere so I don't really care that much these days.

Chromium (and Chrome) also have option to self-host sync server. However, the architecture and encryption are significantly different so I believe it's impossible to create an "universal" sync service that'd accept both.