User:Fmarier/FxASyncPairing: Difference between revisions
Jump to navigation
Jump to search
(→Out of scope: add Class A data storage) |
(→Out of scope: make it clear that some of these things are interesting) |
||
| Line 10: | Line 10: | ||
== Out of scope == | == Out of scope == | ||
Some of the following things are interesting but currently out of scope: | |||
* removing the need for a password in Firefox Accounts | * removing the need for a password in Firefox Accounts | ||
Revision as of 23:18, 16 July 2014
User stories / audience
Here are the reasons why users want pairing:
- As a forgetful user, I want to sync my things without having to pick a password.
- As an impatient user, I want to connect my phone to my laptop without having to go through email verification or having to type anything on my phone.
- As a user of many FxA-backed services, I do not use a very strong password for my account and would like to secure my data on Mozilla's servers with something stronger.
- As a privacy nerd, I only want to store my data on Mozilla's servers if it's encrypted using a full-strength key that never transits through an intermediate service, even if it means jumping through a few hoops.
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
- escrow of full strength keys to protect against device loss and improper backup practices
- moving Content Server payloads to the client or validating these payloads
Pairing mechanisms
Here are the 4 key exchange mechanisms that have been considered to copy the full-strength key 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.
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 |
| 3D barcode | no | YES! | meh [5] | no | YES! | meh [5] | no | YES! | meh [5] | yes | no |
- requires time shifting since devices may not be in physical proximity
- typing on mobile is not fun
- securely copying files out of a mobile is hard
- using the "kB channel" to copy kC reduces the strength of the key
- using a laptop camera to scan a QR code is hard
- user can recover their data after losing all devices
- users lose their data if they forget their password & lose all devices
User flows
The following flow shows all of the proposed pairing mechanisms:
whereas this one shows the 0-bit pairing mechanism: