The new Sync protocol

(This wraps up a two-part series on recent changes in Firefox Sync, based on my presentation at RealWorldCrypto 2014. Part 1 was about problems we observed in the old Sync system. Part 2 is about the protocol which replaced it.)

Last time I described the user difficulties we observed with the pairing-based Sync we shipped in Firefox 4.0. In late April, we released Firefox 29, with a new password-based Sync setup process. In this post, I want to describe the protocol we use in the new system, and their security properties.

(For the cryptographic details, you can jump directly to the full technical definition of the protocol, which we’ve nicknamed “onepw”, since there is now just “one password” to protect both account access and your encrypted data)

Design Constraints

To recap the last post, the biggest frustration we saw with the old Sync setup process was that it didn’t “work like other systems”: users *thought* their email and password would be sufficient to get their data back, but in fact you need access to a device that was already attached to your account. This made it unsuitable for people with a single device, and made it mostly impossible to recover from the all-too-common case of losing your only browser. It also confused people who thought email+password was the standard way to set up a new browser.

In addition, we’ve been building a new system called Firefox Accounts, aka “FxA”, which will be used to manage access to Mozilla’s new server-based features like the application marketplace and FirefoxOS-specific services.

So our design constraints for the new Sync setup process were:

  • must work well with Firefox Accounts
  • must sign in with traditional email and password: no pre-connected device necessary
  • all Sync data must be end-to-end encrypted, just like before, using a key that is only available to you and your personal devices

Firefox Accounts: Login + Keys

To meet these constraints, we designed Firefox Accounts to both support the needs of basic login-only applications, *and* provide the secret keys necessary to safely encrypt your Sync data, while using traditional credentials (email+password) instead of pairing.

For login, FxA uses BrowserID-like certificates to affirm your control over a GUID-based account identifier. These are used to create a “Backed Identity Assertion”, which can be presented (as a bearer token) to a server. The Sync servers require one of these assertions before granting read/write access to the encrypted data they store.

Each account also manages a few encryption keys, one of which is used to encrypt your Sync data.

What Does It Look Like?

In Firefox 29, when you set up Sync for the first time, you’ll see a box that asks for an email address and a (new) password:

FF 29 Sync Account-Creation Dialog

You fill that out, hit the button, then the server sends you a confirmation email. Click on the link in the email, and your browser automatically creates an encryption key and starts uploading ciphertext.

Connecting a second device to your account is as simple as signing in with the same email and password:

FF 29 Sync Sign-In Dialog

The Gory Details

This section describes how the new Firefox Accounts login protocol protects your password, the Sync encryption key, and your data. For full documentation, take a look at the key-wrapping protocol specs and the server implementation.

This post only describes how the master “Sync Key” is managed. To learn about how the individual records are encrypted (which hasn’t changed), take a look at the storage format docs.

Encryption Keys

Each account has two full-strength 256-bit encryption keys, named “kA” and “kB”. These are used to protect two distinct categories of data: recoverable “class-A”, and password-protected “class-B”. Nothing uses class-A yet, so I’ll put that off until a future article.

Sync data falls into class B, and uses the kB key, which is protected by your account password. In technical terms, the FxA server holds a “wrapped copy” of kB, which requires your password to unwrap. Nobody knows your password but you and your browser, not even Mozilla’s servers. Not even for a moment during login. The same is true for kB.

To access any data encrypted under kB, you must remember your password. This means that anyone who doesn’t know the password can’t see your data.

If you forget the password, you’ll have to reset the account and create a new kB, which will erase both the old kB and the data it was protecting. This is a necessary consequence of properly protecting kB with the password: if there were any other way for you to recover the data without the password, then a bad guy could do the same thing.

kB is a “root” key: it isn’t used directly. Instead, we derive a distinct subkey for each application (like Sync) that wants to encrypt class-B data. That way, applications are prevented from decrypting data that wasn’t meant for them. Sync is the only application we have so far, but we may add more in the future.

Keeping your secrets safe

To make sure your Sync data is really end-to-end encrypted, we must prevent anyone else from figuring out your password, otherwise they could learn kB and decrypt your data. “End-to-end” means we even have to exclude our own server from learning your password. The server is usually on your side, but we’d like to maintain security even if it gets compromised. A compromised server is the most powerful kind of attack we can handle. So if we can keep your password away from our server, we can keep it away from any attackers too.

We use multiple layers of security to protect your password. To start with, the server is never told your raw password: you must prove that you know the password, but that’s not the same thing as revealing it. The client sends a hashed form of the password instead.

This hashed form uses “key-stretching” on the password before sending anything to the server, to make it hard for a compromised server to even attempt to guess your password. This stretching is pretty lightweight (1000 rounds of PBKDF2-SHA256), but only needs to protect against the attacker who gets to see the stretched password in-flight (either because they compromised the server, or they’ve somehow broken TLS).

Finally, the data stored on the server is stretched even further, to make a static compromise of the server’s database less useful to an attacker. This uses the “scrypt” algorithm, with parameters of (N=64k, r=8, p=1). At these settings, scrypt takes 64MB of memory, and about 250ms of CPU time.

This complicated diagram shows how the password is processed before sending anything to the server, and then used to unwrap the server’s response when it gets back:

FxA key handling diagram

Security Properties

Sync retains the same end-to-end security that it had before. The difference is that this security is now derived from your password, rather than pairing. So your security depends upon having a good password: if someone can guess it, they’ll be able to connect their own browser to your account and then see all the Sync data you’ve stored there.

On the flip side, by using passwords, you can connect a new browser to your account without having an existing device nearby to pair with, and you can even access your Sync data after losing your last device, neither of which was possible with the old pairing process.

How Hard Is It For Someone To Guess My Password?

The main factor is how well you generate the password. The best passwords are randomly generated by your own computer. The process you use (or rather the process that an attacker thinks you used) determines a set of possible passwords, which an attacker would need to try, one at a time, until they find the right one. Hopefully this set is very very large: billions or trillions at least.

The difficulty of testing each guess depends upon what the attacker has managed to steal. Regular attackers out on the internet are limited to “online guessing”, which means they just try to sign in with your email address and their guessed password, as if they were a regular user, and see whether it works or not. This is rate-limited by the server, so they’ll only get dozens or maybe hundreds of guesses before the server cuts them off.

An attacker who gets a copy of the server’s database (perhaps through an SQL injection attack, the sort you read about every month or two) have to spend about a second of computer time for each guess, which adds up when they must try a lot of them. The most serious kind of attack, where the bad guy gets full control of the server and can eavesdrop on login requests, yields an easier offline guessing attack (PBKDF rather than scrypt) which could be made cheaper with specialized hardware.

The security of old Sync didn’t depend upon a password, because the pairing protocol it used meant there were no passwords.

Can I Change My Password?

Of course! From the Preferences menu, choose the Sync tab, and hit the “Manage” link. That will take you to the “Manage account” page, which has a “Change password” link, where you can just type your old and new passwords. Changing your password will automatically disconnect any other browsers that were syncing with your account. You’ll need to re-sign-in on those browsers before they’ll be able to resume syncing. All of your server-side data will be retained.

What Happens If I Forget My Password?

If you can’t remember your password, you’ll have to reset your account (by using the “Forgot password?” link from the login screen). This will send you a password-reset confirmation email with a link in it. Click on the link, and you’ll be taken to a page where you can set up a new password. As with changing your password, this will disconnect all browsers from your account, so once you’ve finished the reset process, you’ll need to sign back into each browser with your new password.

Resetting the account will necessarily erase any data stored on the server. To be precise, the old data is irretrievable (it was encrypted by a key that was wrapped by your now-forgotten password; and since you can’t recover that key, you can’t recover the data either), and the Sync storage server will erase the old data when it learns that you’re using a new encryption key.

If you reset your account from a browser that was already syncing and up-to-date, then after you reconnect, your browser will simply repopulate the server with your bookmarks/etc, and nothing will be lost. It’s also fine to reset your account from one (empty) browser, then reconnect a second (full) browser: your data will be merged, and everything will eventually be available on both devices.

The one case where you can’t recover your old data is if you lose or break your only device and also forget your password. In this case, when you reset your account from a new (empty) browser, then your old Sync data is lost, and you’ll have to start again from a blank slate. You may want to write down your password in a safe place at home to avoid this, sort of like leaving a spare housekey with a trusted neighbor in case you lose your own.

What If I’m Already Running Sync?

If you’ve been using Sync for a while now, you probably set up Sync with the pairing scheme from Firefox 28 or earlier. Never fear! Your browsers will continue to sync with each other even after you upgrade some or all of them to FF29.

If you’re still running FF28, the FF24 ESR (Extended Support Release), or another pre-FF29 browser, you can still use the pairing flow to connect additional old browsers. We’ll support this flow until at least the end of the ESR maintenance period (14-Oct-2014), maybe a bit longer, but eventually we’ll shut down the servers necessary to support the old pairing flow, and pairing will stop working. We hope to have a new pairing system in place by then: see below.

Likewise, after most users have migrated to New Sync, and everyone has been given fair notice to upgrade, the old-style Sync storage servers will eventually be shut down. But for now, existing Sync users don’t need to make any changes.

However, pairing-based Old Sync and password-based FxA-powered New Sync don’t mix: if you used pairing to connect two FF28 browsers together, you won’t be able to connect a third FF29 browser to them, even if you upgrade them all to FF29. You’ll need to move everything to FxA to connect all three:

  • upgrade everything to FF29
  • disconnect both old browsers from Sync
  • create a Firefox Account
  • sign all three browsers into your new account with the same email and password

This process won’t lose any data: everything will be merged together in the new account.

Future Directions

We’re working on adding two-factor authentication (“2FA”) to Firefox Accounts. If you enable this, you’ll need to type in an additional code (generally provided by your mobile phone) when you log in. The two main options we’re investigating are TOTP one-time passwords (e.g. the Google Authenticator app), and SMS codes.

We are also looking for ways to re-introduce pairing as an optional feature, after the main login. This might use an additional key “kC”, which is only transferred via pairing. Once enabled, to set up Sync on a new device, you would need grant it permission from an old device that is already connected. We think we can make the pairing experience better than it was before, because we’ll have more information to work with (you’ve already logged in, so we know which other devices might be available for pairing).

Conclusion

The new Sync sign-up process is now live and adding thousands of users every day. The password-based login makes it possible to use Sync with just a single device: as long as you can remember the password, you can get back to your Sync data. It still encrypts your data end-to-end like before, but it’s important to generate a good random password to protect your data completely.

To set up Sync, just upgrade to Firefox 29, and follow the “Get started with Sync” prompts on the welcome screen or the Tools menu.

Happy Syncing!

(Thanks to Karl Thiessen, Ryan Kelly, Chris Karlof, and Daniel Kahn Gillmor for their invaluable feedback. Cross-posted to my home blog.)

23 comments

  1. The suggestion that old sync required you to have access to device that was already connected to the account is, of course, completely untrue.

    Pairing was one way of connecting to old sync. The other was to enter the pass phrase used when setting it up. Indeed that was the only way at first – pairing was a later addition!

    I had about seven devices connected to old sync without ever using the pairing system.

    • > The suggestion that old sync required you to have access to device that was already connected to the account is, of course, completely untrue.

      Fair enough. But I’d argue that finding the “Sync Recovery Key” dialog was even harder than finding the place to type in the pairing code, and thus even less useable by the average user. Those of us who’ve been using Sync since the early days (back when it was called Weave) know how it all works, but for a new user who has been conditioned by other systems to expect “just type in your email and password”, it was really confusing at best, and unuseable at worst.

      • Actually, it was exceedingly simple provided one read the brief instructions and saved a printout with the sync key as instructed. To suggest that it was in any way ‘unusable’ is laughable. After all, it’s what we all used for the last several years!

        I suggest that in the future, before changes are made to a defining feature, a tool tip (or other public flag) should be attached to said feature to announce planned changes and allow for input and scrutiny from a larger audience. Understanding beforehand that users considered sync AND master password protection crucial (and a significant differentiator from other browsers) would have almost certainly suggested different communication about these changes, and may have altered the decision as well.

        It would also be reassuring to have more visibility to the data going into this sort of decision making. E.g., before deciding change was required, I would have wanted to know the fraction of actual users unable to understand or use sync, rather than extrapolating user frustration from a couple of hopeless help desk cases.

        • > To suggest that it was in any way ‘unusable’ is laughable. After all, it’s what we all used for the last several years!

          I hear you.. the number of people who successfully used it was definitely greater than zero, so “unusable” is hyperbole. But I saw reports that said the number of accounts with only one device was greater than the number of accounts with multiple devices, which suggests that less than half of the people were using it successfully. That’s a problem, even if you and I (and maybe most of the people reading this post) were able to follow the instructions.

          > I suggest that in the future, before changes are made to a defining feature, a tool tip (or other public flag) should be attached to said feature

          That’s a neat idea! I suspect it’d get a bit overwhelming if Firefox had a tooltip for every upcoming change (imagine what the Australis UI overhaul would have looked like with those notes).. I’m not enough of a UI person to figure out how to do that well.

          > Understanding beforehand that users considered sync AND master password protection crucial (and a significant differentiator from other browsers) would have almost certainly suggested different communication about these changes, and may have altered the decision as well.

          Yeah, I agree. I’m really sorry that we broke that. https://bugzilla.mozilla.org/show_bug.cgi?id=1013064 is tracking the fix.

          > I would have wanted to know the fraction of actual users unable to understand or use sync, rather than extrapolating user frustration from a couple of hopeless help desk cases.

          Me too. But apart from that how-many-devices-per-account metric, and the pitiful adoption rate (someone told me <1%, I think), I don't know how we'd go about measuring that, at least without invasive instrumentation (measuring how many people started the process but then didn't finish it), which would be doubly inappropriate in a feature that's supposed to help protect your privacy.

          BTW, we're trying to bring back pairing, with more energy spent on UX this time. https://wiki.mozilla.org/User:Fmarier/FxASyncPairing is the beginning of this work.

  2. Thanks for a great writeup. I’m still using the old sync (with master password) with my own server, and after reading this post, it’s now the first time I’m actually considering moving to the new sync. I’d appreciate some (many 😉 ) clarifications please. Link to a good answer elsewhere would be fine as well.

    – You mentioned that the old sync servers will shut down. Will Firefox still be able to use own hosted servers after that happens? If this code will be removed on the Firefox side, could it be implemented as an addon with relative ease? (e.g. maybe use similar API to access the data internally, etc, but without re-implementing or duplicating the whole of the old Firefox sync code). Would you be able to maintain such addon on such case?

    – What’s the Year of Birth field, and can one use the new sync without specifying one?

    – I’d appreciate if you could compare the cryptographic strength/weaknesses (only where they differ) between new sync and the old one (in layman’s terms – not more than 2-3 bullets, if possible).

    – Can Firefox generate the password for you, store it at the password manager, and hide it behind the master password? (I’m aware of bug 1013064). If yes, would that be as secure as the old sync? less? more? Can the master password be the only password to remember as long as not adding new devices (at which case I could show passwords and enter it on a new device, unless pairing will be added)?

    – You mentioned “Sync storage server will erase the old data when it learns that you’re using a new encryption key”. How can it know that kB changed if it’s never unwrapped at the server?

    – Are there any additional attack vectors during password change? Does password change happen in a web page with the server? or inside the browser chrome while securely (beyond https) communicating with the server?

    – The old sync is apparently simple enough to set up a hosted sync server relatively easily (about 5 php files – https://github.com/balu-/FSyncMS ). How much of a priority is it to make it easy to practically self host a server? For instance, the “official” old sync server was _not_ easy to set up, but since the system was simpler, 3rd parties could help. The new system looks considerably more complex.

    – If Mozilla is served with a court order for some unencrypted user’s data, and Mozilla even agrees that this data should be exposed, will it be able to comply with the order without compromising the user’s browser?

    Thanks in advance, and looking forward for answers to help me make the switch 😉

    • > – You mentioned that the old sync servers will shut down. Will Firefox still be able to use own hosted servers after that happens?

      Yup. There are two separate things which will eventually be shut down. The first is the relay server that conveys pairing messages between your multiple browsers. This is what allowed pairing to work without typing in an IP address or some other way to identify the other browser that you wanted to pair with. If we can manage to build a new pairing flow, we’ll need something like this again, and we’ll probably either leave it running or spin up a replacement. But there’s no guarantee that the new scheme will use the same protocol, so we want to set the expectation that old-style pairing will stop working at some point.

      The second is the Sync storage server for old-style accounts. As I understand it (I’m not a backend dev, so you should ask on the sync-dev mailing list for confirmation), each Sync account (whether old pairing-based or new FxA-based) is tied to a particular backend storage server. We have a new batch of servers for the new FxA-based accounts, so everyone who signs up with FF29 or later gets pointed at one of the new servers. We expect the number of users on the old servers to go down over time, as people upgrade and get assigned to the new batch. At some point, the ops folks want to shut down those old servers. We have some notification channels in the old Sync code, so I think we’ll be able to message those folks that they need to upgrade when the time comes.

      > – The old sync is apparently simple enough to set up a hosted sync server relatively easily (about 5 php files – https://github.com/balu-/FSyncMS ). How much of a priority is it to make it easy to practically self host a server?

      It’s still quite possible.. it’s not our top priority, but we’re still very eager to retain the ability. You can use about:config to point Sync at your own servers. There are more moving parts now than before, though. This blog post has more information: https://blog.mozilla.org/services/2014/05/08/firefox-accounts-sync-1-5-and-self-hosting/

      > – What’s the Year of Birth field, and can one use the new sync without specifying one?

      COPPA, see above. You’ll note that first option is “1990 or earlier” :).

      > – I’d appreciate if you could compare the cryptographic strength/weaknesses (only where they differ) between new sync and the old one (in layman’s terms – not more than 2-3 bullets, if possible).

      How’s this?:

      The only change is how the Sync Key is managed: everything past that is the same as before.
      In Old Sync, nobody (even the server) had any reasonable chance of figuring out your Sync Key.
      In New Sync, if you use a bad password, then an attacker who breaks into the fxa-auth-server (run by Mozilla) can spent a lot of CPU time (e.g. money) to guess your password and then get your Sync Key. If you use a good password, this is not feasible.

      > – Can Firefox generate the password for you, store it at the password manager, and hide it behind the master password? (I’m aware of bug 1013064). If yes, would that be as secure as the old sync? less? more?

      It can’t do that right now, unfortunately, but it’s a good idea.

      I’m not sure how that would compare security-wise: I need to learn more about how Old Sync managed its encryption key. Let me do some research and get back to you.

      > Can the master password be the only password to remember as long as not adding new devices (at which case I could show passwords and enter it on a new device, unless pairing will be added)?

      If/when we get Sync to play nicely with a master password, and if you aren’t worried about losing your only device (thus losing the only copy of the FxA password that you aren’t remembering), and if you’re willing to transcribe a large randomly-generated password each time you set up a new browser, then yes :).

      If you look at it from an availability point of view, then the general idea is that the FxA password is the only one you remember, and from a new computer, you can get back to all your stuff by just signing into FxA with that password.

      In my perfect world, the whole profile would be encrypted, the Sync server holds the ciphertext, the local device holds ciphertext until you unlock it with the FxA password, then it holds plaintext until you lock it again. The FxA password would be the master password. And you’d be able to switch between profiles easily. But there’s a tremendous amount of design/UI/UX/security/engineering work that would need to go into that, sooo many really difficult issues. So I don’t think it’s likely to happen soon :(.

      > – You mentioned “Sync storage server will erase the old data when it learns that you’re using a new encryption key”. How can it know that kB changed if it’s never unwrapped at the server?

      Good question! The Sync client code reveals the SHA256 hash of the key to the Sync Tokenserver, which remembers which hashes it’s seen for your account and watches for changes (the certificate it gets also has a generation field, so it can tell which one is newer). This is safe because kB is a full-strength random value (256 bits), and SHA256 is a cryptographically-secure hash function that’s resistant to “first preimage” attacks, so there’s no feasible way to get from hash(kB) back to kB.

      > – Are there any additional attack vectors during password change? Does password change happen in a web page with the server? or inside the browser chrome while securely (beyond https) communicating with the server?

      In FF29, both account setup and password change happen in a web page (served over TLS from accounts.firefox.com), so we’re dependent upon HTTPS doing it’s job, and upon the server delivering the right page. We’re hoping to move that into browser chrome to remove that dependency.

      > – If Mozilla is served with a court order for some unencrypted user’s data, and Mozilla even agrees that this data should be exposed, will it be able to comply with the order without compromising the user’s browser?

      That kind of thing is beyond my pay grade :). But I’ve tried to design this system so that nothing short of a browser compromise would work. We have some way to go still, but that’s my goal.

      Thanks for the questions!
      -Brian

      • Thanks for the great answers! 🙂

        > … In New Sync, if you use a bad password … If you use a good password, this is not feasible.

        So on one hand, if I understand correctly, you say/imply that cryptographically they’re equally or similarly strong, up to the strength derived from the FxA password compared to the strength derived from the old sync key, which implies that using a strong enough FxA password should make them equally/similarly strong.

        > I’m not sure how that would compare security-wise..

        But on the other hand, again – if I understand correctly, you say that even if we let Firefox (or some user tool) choose a password as strong you think it needs, you’re still not sure that it’s not less secure. Is the apparent discrepancy due to the difference between security and cryptographically? I.e. it’s cryptographically similarly strong (upto passwd strength), but there could be maybe different attack vectors etc, which you’d like to check?

        FWIW, My question was aimed at the protocol/system level. Not at possibly subpar/flawed/buggy implementations, if that helps. Though I wouldn’t object to other kinds of info you think could be interesting 😉

        > … The FxA password would be the master password …

        True, but there’s a big difference. The attack vector on the master password is only compromised user system, while the attack vector on the FxA password is a compromised server – so this allows the MP to be weaker than FxA password. Therefore in order to keep similar security levels, the FxA password will need to be strong in a similar way to which the old sync key is (I’m counting out the option that it can’t be attacked at the server, but.. maybe it’s possible?).

        Hence my questions above – is it practical to use the new system with a strong FxA password and keep it similarly secure to the old sync.

        > So I don’t think it’s likely to happen soon :(.

        That’s unfortunate… :/

        > … account setup and password change happen in a web page (served over TLS from accounts.firefox.com) …

        Hmm.. so in effect, right now, while this may be true: “Nobody knows your password but you and your browser, not even Mozilla’s servers. Not even for a moment during login. The same is true for kB.”, it’s still possible that during account setup or password change, an attacker or an IT guy who has control over the server could copy the account’s FxA password and use it to decrypt the user’s data?

        I’m willing to believe the “Nobody knows” part because I trust Mozilla – though only up to its compliance with state laws, but a compromised server wouldn’t be as trustworthy. Any planned schedule to change this?

        > Will Firefox still be able to use own hosted servers after that happens?

        > Yup. There are two separate things which will eventually be shut down. …

        I either wasn’t clear enough with my question, or the reply (“Yup”) was too good to believe 😉 yet I still managed to gain new insight from your answer.

        I assumed that the old pairing server is some global service which isn’t going away. I now understand that to be able to keep using the old sync would require:

        1. The relay/pairing service (for pairing new devices).
        2. the sync storage server (for day-to-day sync).
        3. And, what I originally wanted to ask about and couldn’t quite believe that the answer to is “Yup”: 3. The code inside Firefox that is able to use the sync storage server and possibly the pairing service.

        Right now old sync works in Firefox 29, and I can still pair new devices with Firefox29 if I have old sync setup, but I can’t setup old sync if I don’t already have it set up. Recently when I needed to pair a new device, I installed Firefox 28 only on the new device, made the pairing, then upgraded it to 29 – all while my “other device” has Firefox 29 on it.

        – Can one host an (old) pairing service? Is the code available someplace? (yes, I’ll need to setup some pref to use a custom pairing server).
        – Only if your “Yup” didn’t include this: Is it planned to keep the code in Firefox to support old-pairing (at a level which Firefox 29 supports it), and to keep Firefox’s ability to use old sync storage servers if old sync is already set up (e.g. using Firefox 28)?
        – If the above are planned to be removed, how easy/hard would it be to provide them via some addon without duplicating the whole code in firefox which does them (unless this “whole code” is very small, and depends mostly on APIs which are not planned to be removed, or maybe even are still used by the new sync, at which case, an proof of concept addon which does it would be appreciated).

        I guess you see where all this is getting to. I value Mozilla and I trust it. I’m even getting paid by Mozilla. But I don’t want to be forced to trust it, and right now I feel that the new sync forces me to.

        The old system (not UI) was simple enough to be able to set it up independently (and I entrusted it and Mozilla with my data – I only started hosting my server when Mozilla servers were temporarily down and I couldn’t afford to not sync). The new system is much more complex, integrated and less dedicated to one task – combining FxA and sync, which makes it considerably harder to set it up independently.

        Most will probably agree that syncing different devices is an extremely useful feature. Some may argue that backing up your data by the browser vendor and be able to retrieve it with a simple password (and email) is equally important. No one would argue against easier UX work flows. But the balance of those, especially where the new sync takes it to, is one which apparently worries privacy conscious users.

        Hence the questions about keep using the old sync in Firefox itself or via an addon, the questions on existing/stable internal APIs which allow third parties to offer other sync systems (e.g. using the old sync system) but without having to rewrite or duplicate meaningful chunks of the internal sync code, etc.

        I understand that for many users, quite possibly the majority of them, the new sync is better, but personally I find that it takes from me very important powers (e.g. much more meaningful that UI changes which some may dislike), without providing me with an alternative to retain those powers.

        (man, CAPTCHAS aren’t getting easier.. eh?)

        • > which implies that using a strong enough FxA password should make them equally/similarly strong.

          Yes, that’s right.

          > but there could be maybe different attack vectors etc, which you’d like to check?

          Right. What I don’t currently know is how the old system handled the Sync Key. My hunch is that it stored the Sync Key in the password manager between reboots, which means that you have type in your master password once when you start up the browser. My second hunch is that Old Sync then held that Sync Key in memory until browser shutdown, so you wouldn’t have to retype the MP to allow Sync to do its job. My third hunch is that Old Sync also remembered your MP in memory, or had some way to extract passwords from an MP-protected Password Manager without re-prompting you for the MP all the time. I’m the least confident about this last hunch, and either way there are clear security concerns (anyone who can access your computer could dump Firefox’s memory and learn the MP, so you’d only really be protected after you quit the browser).

          I’ve seen a handful of bugs and SUMO topics around this issue. I know the old system had a bunch of problems with MP and syncing passwords, and we didn’t solve any of them with New Sync (and probably introduced one or two). But I think they’ll get fixed eventually.

          > is it practical to use the new system with a strong FxA password and keep it similarly secure to the old sync.

          Yeah. With respect to a compromised auth server, the security metric is “how much money must the attacker spend to figure out your password”, which is basically the entropy of your password times their guessing costs, which should grow linearly with the amount of stretching you do. The scrypt stretch we do is a lot bigger than anything else I’ve seen in the industry. I have some hand-wavy cost models to explore these costs.

          You might approach the problem with a goal like “how good does my password need to be to achieve the same security as Old Sync’s fully-random key?”, in which case you might compare an attacker searching a 128-bit Sync Key space (with a cost function of one hash per guess) against them searching an N-bit New Sync password space (with a cost function of the scrypt stretch each), and solve for N. My hasty math suggests that N = 100 bits, but that’s completely overkill: the attacker’s cost in both cases is over 10^24 dollars (2.4 yottadollars, to be all precise and metric about it :-). It’s probably fair to say that my data isn’t worth more than a million bucks, in which case a 40-bit password is enough to drive the brute-force costs above the data’s value.

          And a 40-bit password is shorter than the 60-bit pairing code was.

          > it’s still possible that during account setup or password change, an attacker or an IT guy who has control over the server could copy the account’s FxA password and use it to decrypt the user’s data?

          Yes, someone who found a way to make the fxa-content-server deliver a bad page, while you were logging in, could use that ability to reveal your FxA password and then use it themselves later. That will be fixed when we move this login page into browser chrome (e.g. ship the about:accounts page in the browser bundle, rather than fetching it from fxa-content-server). We don’t have a schedule to change that, but we’re all in agreement that it needs to happen.

          It’s similar to the issue in both Old and New Sync (and in every piece of internet-delivered software) that someone who found a way to make the Firefox software-update server deliver a bad browser to you, would then be able to learn everything. The FxA attack surface is slightly larger because this page is delivered more frequently than a full browser upgrade (and since you can technically refrain from accepting a browser upgrade), but the basic attack is the same.

          > I either wasn’t clear enough with my question, or the reply (“Yup”) was too good to believe 😉 yet I still managed to gain new insight from your answer.

          Heh, I’m sorry and happy that I was confusing and enlightening :-). Hopefully I’ll do better this time..

          > I assumed that the old pairing server is some global service which isn’t going away.

          The relay/pairing service will be shut down eventually. My hope is that we’ll have figured out a new pairing flow before that happens, so folks who prefer pairing will not have to run their own relay servers or stick with FF28 forever. But we haven’t set a schedule for it yet.

          The code inside Firefox which knows how to present the pairing UI, and speak J-PAKE to the relay server, has either been removed or bypassed (I don’t know which, but a little digging in mercurial history should let us find out). I think it was removed completely from the android codebase. We decided it would be too error-prone and messy to try and retain both code paths.

          The code that encrypts bookmark/password/etc data, schedules database writes, and talks to the Sync storage server is exactly the same as before: nothing at this layer changed.

          As I understand it (again, the folks on sync-dev know more than I do here) each account gets tied to a specific database server. When we rolled out New Sync, we also rolled out a new cluster of servers, and everybody coming in through the FxA path gets assigned to a server in that new cluster. If you created an account in FF28 or earlier, you were assigned to something in the old cluster (and of course if you use FF28 or earlier to pair a new machine into such an account, you get assigned to the same old-cluster server). That old cluster will go away eventually.

          So to keep using your FF28-created sync environment forever, you’d need three things:

          1: make all your browsers talk to a Sync storage node that keeps running
          2: downgrade to FF28 each time you want to add a new machine
          3: have both pairing browsers talk to a Sync relay server

          #1 doesn’t require any new client-side code, but the old-cluster storage node you’re currently using will eventually be shut down. So either you need to upgrade to an FxA-based account (and use the new cluster), or you need to run your own server and make all your browsers use it.

          #3 requires a relay server, and the one we run will eventually be shut down. I think this runs https://hg.mozilla.org/services/server-key-exchange , so it’s possible to run your own. Both browsers participating in the pairing must use the same relay server, of course.

          If you just want to run your own servers, and aren’t trying to use pairing or keep your old account around forever, then you can use https://blog.mozilla.org/services/2014/05/08/firefox-accounts-sync-1-5-and-self-hosting/ as a starting point.

          > how easy/hard would it be to provide them via some addon without duplicating the whole code in firefox which does them

          It’d probably be feasible to write an addon which re-introduced the pairing code and over-wrote the stored “kB” value. The underlying J-PAKE crypto is still present in NSS. But whoever writes this addon will need to solve the same UI issues as we’ll be looking at for a new pairing flow (how do you know if a given account is using pairing? how does it interact with the optional “second password” that some folks want? how/when do you display the code-entry UI? how do you explain how it all works?), and will need to run a server. So I’m hoping that we can pool our energy and develop a new form of pairing that’s easy enough to be built-in, instead of relying on an addon.

          > I understand that for many users, quite possibly the majority of them, the new sync is better, but personally I find that it takes from me very important powers … without providing me with an alternative to retain those powers.

          Yeah, I hear you. Building features for a large audience is full of frustrating tradeoffs. I was very proud of the pairing design, and very sad to see how many people got confused by it. But I suspect that if you’re one of the small percentage of us who understood pairing, then you’re also capable of managing a decent password, and then (modulo the webpage-vs-chrome issue that should get fixed eventually) you can get a suitable level of security out of the new system. It won’t be as good a convenience-per-unit-security ratio as pairing provided, but it’s still pretty usable and pretty secure.

          • > Right. What I don’t currently know is how the old system handled the Sync Key. My hunch is that it stored the Sync Key in the password manager between reboots, which means that you have type in your master password once when you start up the browser. My second hunch is that Old Sync then held that Sync Key in memory until browser shutdown, so you wouldn’t have to retype the MP to allow Sync to do its job. My third hunch is that Old Sync also remembered your MP in memory, or had some way to extract passwords from an MP-protected Password Manager without re-prompting you for the MP all the time. I’m the least confident about this last hunch, and either way there are clear security concerns (anyone who can access your computer could dump Firefox’s memory and learn the MP, so you’d only really be protected after you quit the browser).

            Yup. I’m unfamiliar with the implementation details of neither the old sync nor the password manager + MP system and my observations do align with yours, though not my hunches, and yet my bottom line is the same – The system’s memory could probably lead to or reveal the sync key.

            From my years of using PM+MP and using the old sync, the passwd-mgr prompts for the master password at most once* per browsing session (when Firefox starts, _probably_ for sync – before sync it would have prompted later than browser startup), and until the browser closes all passwords stored at the PM could be reused (e.g. when visiting web pages for which it has stored passwords) or new passwords added without entering the master password again. I guess the old sync uses the same PM/MP system and doesn’t introduce new issues, therefore any issues the old model has at this level, are probably derived from the MP system. But your guess is as good as mine. Actually, yours is probably better 😉

            * An exception is when you want to display/expose your passwords (i.e. display them literally and not as *** when they’re used), at which case it prompts again for the MP. I’m guessing this is a UI measure more than anything else, though I wouldn’t mind at all being wrong on this. It could, for instance, keep some PKCS11 session open which is used to re-access passwords on demand from some secure storage without storing them in Firefox’s memory. Though since most people (myself included) probably don’t have PKCS11 HW, in practice the passwords probably could be accessed by looking at memory only, and if there’s a HW storage, the session could probably be reused by an attacker.

            It comes down to compromised system as the major attack vector, which is under the user’s control (even if, as we’ve seen in this post Snowden era, it doesn’t mean a lot, though online systems and communications are by far more exposed yet).

            And as an unrelated question, do you store your passwords in Firefox’s PM? do you use MP? and why 🙂

            > It’s similar to the issue in both Old and New Sync (and in every piece of internet-delivered software) that someone who found a way to make the Firefox software-update server deliver a bad browser to you.

            True. And even more so, signing up to FxA or changing password probably happens less frequently than browser updates. And yet, it’s another attack vector on top of browser updates and not instead of it.

            > Heh, I’m sorry and happy that I was confusing and enlightening :-). Hopefully I’ll do better this time..

            Now you did perfectly, thanks!

            > The code that encrypts bookmark/password/etc data, schedules database writes, and talks to the Sync storage server is exactly the same as before: nothing at this layer changed.

            Excellent!

            > So to keep using your FF28-created sync environment forever, you’d need three things:

            > #1 (make all your browsers talk to a Sync storage node that keeps running) doesn’t require any new client-side code, but the old-cluster storage node you’re currently using will eventually be shut down. So either you need to upgrade to an FxA-based account (and use the new cluster), or you need to run your own server and make all your browsers use it.

            Yup, though running your own (or your company’s) sync storage server is relatively easy. I was able to deploy one in about an hour without prior familiarity with it. Glad to hear that Firefox will retain the ability to sync with such servers.

            > 2: downgrade to FF28 each time …

            Cumbersome yet manageable.

            > #3 (have both pairing browsers talk to a Sync relay server) requires a relay server, and the one we run will eventually be shut down. I think this runs https://hg.mozilla.org/services/server-key-exchange , so it’s possible to run your own. Both browsers participating in the pairing must use the same relay server, of course.

            Yup, thanks, and at the worst case, old sync can still work without pairing and with more labour of copying the key between systems.

            > It’d probably be feasible to write an addon … But whoever writes this addon will need to solve the same UI issues …

            Very true. Though an addon has the luxury of being less user friendly than Firefox as a product, as long as it satisfies its users. Nevertheless, the story and UI are certainly challenging.

            > how does it interact with the optional “second password” that some folks want?

            You’re assuming they have a “first password” (which I believe you mean FxA?). Personally I’m not interested in FxA, and am interested in sync.

            > So I’m hoping that we can pool our energy and develop a new form of pairing that’s easy enough to be built-in, instead of relying on an addon.

            Agreed, though tying up a very useful feature with relatively small-ish dependencies like sync to a possibly less-useful/more-controversial and harder to setup independently feature as FxA takes independence from users who care about it. I hope to be able to keep both FxA for the greater community and also this independence potential for those who value it.

            > Yeah, I hear you. Building features for a large audience is full of frustrating tradeoffs. I was very proud of the pairing design, and very sad to see how many people got confused by it …

            Absolutely agreed, and FWIW, I do think the paring and sync (old and new) systems are beautiful – as much as I’m able to understand them, which is admittedly not too much. I’m also absolutely aware of the difficulties of satisfying “normal” and “advanced” users in one product, making tons of trade-offs all over the place, etc. It’s a great challenge though.

            And while I do think this specific subject does have meaningful weight to it, this is still mandatory here: http://xkcd.com/1172/ 😉

            Many thanks again for your excellent designs, patience, replies and honesty, and I do hope to use the new sync sooner rather than later, and maybe also be able to help reduce the dependencies such that it’s not as-tied-up to Mozilla as it is right now.

            Cheers.

  3. […] in zwei Blog-Beiträgen detailliert zunächst die Probleme des Pairings erklärt und dann über das neue Sync-Protokoll gesprochen. Beide Artikel seien allen als weiterführender Lesestoff empfohlen, welche der […]

  4. So what information about users does the service collect?
    And why does it ask for year of birth?
    One has to agree to the privacy notice by using the service,
    maybe that information is included there.
    But the link points at https://accounts-latest.dev.lcip.org/legal/privacy
    which seems to be down at the moment.

  5. I have read through dozens of such blogs on the support system. Can anybody give the novice an easy solution on how to get Bookmarks-on-the-go synced with firefox 29?

  6. Hi! Could you explain a bit more about how you do password changes? It looks like kB is wrapped with a password-derived key, so it seems like changing the password would necessitate re-wrapping (presumably all on the client, since the server isn’t supposed to know all that much about kB). That makes it seem like it’s effectively the same as the forgotten password case?

    And yes, this explanation indeed makes me happy to know that my data is (as of current plans) still irretrievable by the server. I do hope that anything that uses kA-style unencrypted keys are opt-in, but since nothing of the type exists yet that’s a bit putting the cart before the horse 🙂

    • Right, changing the password (from the old known value to a new known value) requires re-wrapping kB on the client, but the important thing is that it retains the same kB (so the stored encrypted data remains retrievable). In contrast, resetting the password (from the old unknown value to a new known value) causes a brand-new random kB to be created.

      This diagram shows more detail of the password-change protocol flow.

  7. Hi, how do I remove an android Firefox from the old sync mechanism, so I can switch to the new one? I don’t see an option to do this!

  8. > Nobody knows your password but you and your browser, not even Mozilla’s servers. Not even for a moment during login. The same is true for kB.

    Absent an active attack, yes. Unfortunately, your using unsigned server-supplied JavaScript for authentication so if someone breaks into your server or gets a fake accounts.firefox.com SSL certificate and performs a MITM attack, that someone could steal passwords at will.

  9. Before Firefox 29 I could tell my devices to copy all tabs, bookmarks, passwords,and history from Device A to Device B. That is what Sync used to be. Firefox 29 took away that functionality. I used to be able to flawlessly keep two other devices synced up with my main device. Now we have no control over our Sync accounts and it does nothing to Sync devices after you get the “Setup complete” graphic.

    So after years of flawless Sync functionality, now all Sync does is nothing and the developers are worried about key encryption and have forgotten the whole purpose of Sync!

    Mozilla took away functionality from their product. That is the issue I would like someone to address: bring back to Sync the ability to tell my devices to copy all tabs, bookmarks, passwords, and history from Device A to Device B.

    • > bring back to Sync the ability to tell my devices to copy all tabs, bookmarks, passwords, and history from Device A to Device B.

      That’s exactly what Sync is supposed to do: we didn’t intentionally remove that functionality. I’m sorry that something isn’t working for you.. it sounds like you’ve run into some sort of bug. You might try the migration process described in https://support.mozilla.org/en-US/kb/how-to-update-to-the-new-firefox-sync to see if it helps.

  10. Dear Mr Warner,

    I came across this blog post via Firefox OS and the idea of integrating Firefox Accounts (or Mozilla Persona).

    A few days ago, I’ve read another article by KDE developer Aaron Seigo (http://aseigo.blogspot.de/2014/07/one-singular-sensation-your-email.html) claiming the e-mail-address as ‘single point of failure’.

    His argumentation sounds valid.

    How does Firefox Accounts take intercepting of e-mails into consideration?

    I was thinking about using Mozilla Persona for a Firefox OS game as cross-device authentification, but I’m concerned about privacy (German mindset, you know ;-)).

    It would be great, if you could reply to the questions raised by Aaron.

    André Jaenisch

    • > How does Firefox Accounts take intercepting of e-mails into consideration?

      Good question! Basically, if an attacker can intercept your email, but doesn’t know your password, then they get to log into your Firefox Account, and they get the “class-A” encryption key, but they do *not* get the “class-B” encryption key that protects your Sync data.

      We decided to tie Firefox Accounts to email addresses to make them easy to use for folks who are already familiar with this pattern. As Aaron points out, nearly everybody does this, and the consequence is that your email provider (or the server sending out the emails) gets to control your account. But that’s not enough to get your Sync data.

      We chose to protect Sync data with your password, and the protocol prevents the server from learning your password, because we believe in end-to-end encryption for your personal data.

      Aaron’s article notes that banks tend to use 2FA or something beyond just email access. Sync is kind of like this, except it’s even stronger. Your bank always knows how much money you have: they’re only using a password (and/or the ability to receive email at some address) to decide whether to reveal that value to each browser that asks for it. The Sync server *doesn’t* know what your bookmarks or tabs or saved passwords are: your account password is protecting those, and none of the Mozilla servers learn it.

      • How does password reset work? (If the answer is “we send an email with a reset link” then, yes, whoever has your email account has your password ..)

        Or is it impossible to reset your password once it is created, and changing it implies re-syncing your data anew? Or is there some 2FA system in place for reset? Or ….?

        • Sorry, I skimmed the article far too quickly and you did indeed answer that in the article… there is no reset for the B key.

          That is indeed better than most everything else out there, but I do wonder how people will respond to having a backup system they can lose access to relatively easily. Or if it will impact what they use as a password to make it more memorable knowing they have to keep it (versus just count on a reset mechanism) …

Leave a Reply

Your email address will not be published. Required fields are marked *