Services/Sync1 5/FxASyncPairing

From MozillaWiki
Jump to: navigation, search


The initial target for this project is to produce a demo of pairing two devices using a full-strength key during new account setup.

This is so that:

  • we have flows to test with users
  • we have a better idea of what needs to happen from an engineering point of view
  • we can confirm that our approach can be implemented

It will not:

  • be deployed to production
  • be merged into the real repos
  • provide the security / privacy guarantees of the final product

Other planning resources

User stories / audience

Here are the reasons why users want pairing:

  1. As an enthusiast, I think that pairing is cool. After a simple ceremony, my things magically get copied from one device to the other.
  2. As a forgetful user, I want to sync my things without having to type a password.
  3. As a user, I am fed up with all of these companies requiring me to create accounts with them. I just want to sync my devices, I don't want a Firefox Account.
  4. As a user of Marketplace, I need to type my FxA password often on multiple devices and so my password may not be strong enough to protect my Sync data, which is a lot more personal than my purchase history.
  5. As a privacy wizard, I only want to store my data on Mozilla's servers if it's encrypted using a full-strength key and doesn't require trusting any intermediate servers, even if it means jumping through a few hoops.

The first two would likely involve big changes in how Firefox Accounts currently works and the assumptions it makes. A larger discussion needs to happen before we could prototype a solution for these stories. The last story would only address the needs of a small percentage of our users and so in the interest of increasing security for a large percentage of Firefox users, we will consider #4 to be our target audience.

Out of scope

Some of the following things are interesting but currently out of scope:

  • removing the need for a password in Firefox Accounts
  • allowing unverified emails in FxA
  • recovery of Sync data if one loses all devices and forgets password (i.e. class A data)
  • escrow of full strength keys to protect against device loss and improper backup practices (e.g. trusted third party or social escrow)
  • mitigating the delivery of tampered code to the browser (i.e validating the content server payload or moving it to the client)
  • migrating existing Sync 1.1 users onto Sync 1.5 + pairing

Pairing mechanisms

Here are the 4 key exchange mechanisms that have been considered to copy the full-strength key (required by the user story we selected) from the device that generated it to another:

  • 0-bit pairing: Once a user has logged into their Firefox account on both devices, the class-B keys are used to authenticate a key-agreement protocol. The old device must ask the user for approval, then the full-strength key is pushed to the new device.
  • Manual key entry: Users can view or download the key on one device and either type it back onto the second device or import it from a file.
  • J-PAKE: This is the pairing mechanism that was used in Sync 1.1. Pairing is initiated on the first device which displays an ephemeral code. That code must be entered on the second device. No need to type in an email address, all that's needed on the second device is the code.
  • Barcode: A way to exchange data from a device to a mobile phone equipped with a camera. There is no need to type anything since the barcode (most likely a 2D barcode or QR code) includes everything needed.
  • Bluetooth: Sending the Sync key to another device over Bluetooth. This potentially involves enabling Bluetooth devices, making them discoverable and doing Bluetooth pairing before transfering the key.

Here's a comparison of these mechanisms:

Pairing mechanism Desktop-to-Desktop [1] Desktop-to-Mobile Desktop-to-Laptop Mobile-to-Desktop Mobile-to-Mobile Mobile-to-Laptop Laptop-to-Desktop Laptop-to-Mobile Laptop-to-Laptop Fully kC compliant Fully backed up [6]
Current FxA Sync yes yes yes yes yes yes yes yes yes no yes [7]
0-bit pairing no yes yes yes yes yes yes yes yes meh [4] no
Manual key entry yes meh [2] yes meh [3] meh [2] meh [3] yes meh [2] yes yes yes
J-PAKE no yes yes yes yes yes yes yes yes yes no
Barcode no YES! meh [5] no YES! meh [5] no YES! meh [5] yes no
Bluetooth no meh [8] meh [8] meh [8] yes yes meh [8] yes yes yes [9] no

  1. requires time shifting since devices may not be in physical proximity
  2. typing on mobile is not fun
  3. securely copying files out of a mobile is hard
  4. using the "kB channel" to copy kC reduces the strength of the key
  5. using a laptop camera to scan a QR code is hard
  6. user can recover their data after losing all devices
  7. users lose their data if they forget their password & lose all devices
  8. desktop computers frequently don't have Bluetooth or have it disabled
  9. we're assuming that the Bluetooth channel is confidential and authenticated

In order to cover all different types of pairing and to simplify the most common pairing case (desktop/laptop to mobile), we propose implementing: J-PAKE, manual key entry and barcodes.

User flows

The following diagram shows all of the proposed pairing mechanisms:

Fxa-sync--full-strength key pairing.png

which excludes the 0-bit pairing mechanism.

This diagram expands on what opening the Sync settings on the second device would look like:

Sync settings on second device.png

This is how all of the different pairing possibilities would work in practice:

Desktop Laptop [1] Mobile [2] no 2nd device [3]
Desktop Desktop-to-Desktop Desktop-to-Laptop Desktop-to-Mobile Desktop-only
Laptop [4] Laptop-to-Desktop Laptop-to-Laptop Laptop-to-Mobile Laptop-only
Mobile [4] Mobile-to-Desktop Mobile-to-Laptop Mobile-to-Mobile [5] Mobile-only [6]

  1. also includes tablets without a camera
  2. also includes tablets with a camera
  3. this is not pairing, it's just a backup
  4. also includes tablets
  5. scanning the QR code displayed on a phone screen can be hard (reflections, changes in screen orientation, etc.) so J-PAKE might be better in this case
  6. it is unclear how users will get the backup out of the phone since copying or printing files securely is not a solved problem on mobile


We need to think about these flows, though they may not be part of the first prototype:

  • migrating an existing Sync 1.5 account from password-derived key (class B) to full-strength key (class C)
  • pairing with a third device
  • email notifications sent to confirm that new devices are paired
  • warnings shown when switching from a password-derived key to a full-strength key
  • warnings shown when users setup Sync with a single device and a full-strength key


Top 5 Pairing Pros

  1. No more typing long passwords
  2. Mobile users short passwords no longer an issue
  3. "Set it and forget it": no more repeated entries
  4. Anshin - the feeling of security: Users _feel_ like Mozilla protects their information and thus feel more comfortable using our (awesome) service
  5. Pairing increases the security of the data (failure point is no longer a low entropy, user created key
  6. Resetting your password doesn't render previous data inaccessible

Top 5 Pairing Cons

  1. Pairing is hard to understand - users might do it wrong (e.g pairing when they only have 1 device)
  2. Pairing is hard to understand - it's cognitively taxing: a minute spent on pairing is more taxing than a minute on Reddit
  3. Knowing when in the flow to introduce pairing is problematic
  4. Users may be frustrated at why the need a PW if there is pairing