Services/Sync/WEP/112: Difference between revisions

< Services‎ | Sync‎ | WEP
(email-only account creation)
 
 
(31 intermediate revisions by one other user not shown)
Line 1: Line 1:
{{draft}}
{{draft}}


== WEP 112 - Email-only Account Creation ==
= WEP 112 - Email-only Account Creation =


* Champions: Edward Lee <edilee@mozilla.com>
* Champions: Edward Lee <edilee@mozilla.com>
Line 10: Line 10:
* [[Labs/Weave/WEPs|WEP Index]]
* [[Labs/Weave/WEPs|WEP Index]]


=== Introduction and Rationale ===
== Introduction and Rationale ==


Account creation currently requires picking a username, password, secret phrase and providing an email address. Asking and validating these pieces of information lengthens the account creation process and confuses the users especially when asking for a secret phrase. This can result in the user giving up.
Account creation currently requires picking a username, password, secret phrase and providing an email address. Asking and validating these pieces of information lengthens the account creation process and confuses the users especially when asking for a secret phrase. This can result in the user giving up.


Setting up another machine requires the the user to remember the username, password, and secret phrase. Users tend to forget these 3 pieces of information especially the secret phrase as it's not frequently used. Users also confuse the password and secret phrase.
Setting up another client requires the the user to remember the username, password, and secret phrase. Users tend to forget these 3 pieces of information especially the secret phrase as it's not frequently used. Users also confuse the password and secret phrase.


=== Proposal ===
Configuring Sync can be as easy as just requesting an email address with other credentials randomly generated. Setting up another client would require remembering that email address and a temporary secret.


For setting up the first computer, only an email address is required to start using Sync. For setting up additional computers, a PIN needs to be first registered from a client configured for Sync and then the email and PIN are needed to get Sync account access.
The premise is that we have a secure low-bandwidth channel (the user's memory) and an insecure high-bandwidth (temporary server storage). The temporary storage is basically a key-value hashtable API provided by the server to keep a "key" and "value" for a short time period, e.g., 1 day.


==== Account Creation ====
== Account Creation ==


All that is required for account creation is an email address. A random username and password pair (used to communicate with the server) are generated. The account can now be registered on the server with the username, password, and email address.
All that is required for account creation is an email address. A random username and password pair (used to communicate with the server) are generated. The account can now be registered on the server with the username, password, and email address.
Line 26: Line 26:
A random passphrase (used to encrypt the private key) is also generated. Data can now be encrypted and synced as usual.
A random passphrase (used to encrypt the private key) is also generated. Data can now be encrypted and synced as usual.


==== Preparing to add another computer ====
== 1-Roundtrip Additional Client Setup ==


When the user wants to add another computer, s/he indicates so in a configured client and is prompted to enter an 8-digit PIN. This PIN is used to encrypt the necessary Sync authentication pieces (username, password, passphrase) that is temporarily stored on the server.
Starting at the new client, Sync setup would display an 8-digit secret that needs to be remembered temporarily. After returning to an active client, the user enters the secret to setup the new client. The user then needs to return to the new client and confirm the setup to then be able to access and decrypt data.


A configured client will already have the email address, username, password, and passphrase available. The client needs to request an 8-digit PIN when the user wants to set up another computer.
=== Prepare setup from new client ===


A "key" is generated from the email address and PIN. This can be done by hashing (sha1) "<email>,<PIN>".
When the user wants to add a client to an existing Sync account, the email address is requested, and a 8-digit secret is shown that needs to be remembered.


A "value" is generated by encrypting a structure that contains the username, password, and passphrase.
The client generates a temporary public/private keypair, and the public key is stored on the server as the "value" with the hash of the email address as the "key".


A server is needed to register this "key" and "value" pair. The server should only keep this pair for 1 day. So there is only a window of 1 day to set up another machine.
sha1(email): public key


==== Setting up another computer ====
A random 4-digit number is generated to be the first half of the 8-digit secret. This number is used to calculate the second half of the secret.


Setting up another computer requires the email address and PIN. With those two pieces of information, the "key" can be regenerated to ask the server for the corresponding "value". The PIN is then used to decrypt "value" which then results in the username, password, and passphrase.
The second half is calculated using HMAC(public key, first half) and result condensed into 4 digits.
 
These two values are shown to the user as single 8-digit number.
 
=== Confirm setup from active client ===
 
After returning to an active client, the user is prompted for the 8-digit secret to activate the new client.
 
The client requests for the hash of the email address as the "key" to get the public key stored as the "value".
 
sha1(email): public key
 
The client verifies that the public key has not been modified by doing the same HMAC(public key, first half) computation and confirms that the result is the second half.
 
Once verified, the client generates an encrypted version of the account credentials (username, password, and passphrase) by encrypting the data with the public key.
 
These encrypted credentials are stored on the server as the "value" with the hash of the email address concatenated with the string "result" as the "key".
 
sha1(email, "result"): pub_encrypt(public key, [username, password, passphrase])
 
=== Setup new client ===
 
After returning to the new client, the user continues account creation and gets the credentials to access and decrypt data.
 
The client requests for the hash of the email address and "result" as the "key" to get the encrypted credentials stored as the "value".
 
sha1(email, "result"): encrypted credentials
 
With the encrypted credentials, the client decrypts them with its local private key, and then gets access to the username, password, and passphrase.
 
credentials = priv_decrypt(private key, encrypted credentials)
 
== 1-Trip Additional Client Setup ==
 
Starting at an active client, the user requests to setup a new client and is shown a token that needs to be remembered temporarily. After going to the new client, the user enters the token to then be able to access and decrypt data.
 
=== Prepare setup from active client ===
 
When the user wants to add another client from an active client, a random user-editable token is suggested. This token is used to encrypt the necessary account credentials (username, password, passphrase), so the token needs to be strong enough so that the server cannot easily brute-force it.
 
These encrypted credentials are stored on the server as the "value" with the hash of the email address as the "key".
 
sha1(email): sym_encrypt(token, [username, password, passphrase])
 
=== Setup new client ===
 
Setting up another client requires the email address and the token to get the credentials needed to access and decrypt data.
 
The client requests for the hash of the email address as the "key" to get the encrypted credentials stored as the "value".
 
sha1(email): encrypted credentials
 
With the encrypted credentials, the client decrypts them with the token and then gets access to the username, password, and passphrase.
 
credentials = sym_decrypt(token, encrypted credentials)
 
== Secure High-Bandwidth Channel ==
 
A user can skip additional client setup processes described above if there is a method to transfer securely more data than a user could remember. This is also useful for skipping the "prepare-to-setup" steps in cases of backup recovery in the situation where an active client is not available to "prepare."
 
An "export" functionality would be provided that saves the credentials: username, password, passphrase, and email address in a reversible format that needs to be separately stored and transferred to other clients.
 
To configure a new client, the credentials would need to be imported, perhaps by copy/pasting from the storage, and this regains full access to the account.

Latest revision as of 04:02, 12 July 2010

Draft-template-image.png THIS PAGE IS A WORKING DRAFT Pencil-emoji U270F-gray.png
The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly.
If you have any questions or ideas, please add them as a new topic on the discussion page.

WEP 112 - Email-only Account Creation

  • Champions: Edward Lee <edilee@mozilla.com>
  • Status: Draft
  • Type: ?
  • Created: May 20 2010
  • Reference Implementation: None
  • WEP Index

Introduction and Rationale

Account creation currently requires picking a username, password, secret phrase and providing an email address. Asking and validating these pieces of information lengthens the account creation process and confuses the users especially when asking for a secret phrase. This can result in the user giving up.

Setting up another client requires the the user to remember the username, password, and secret phrase. Users tend to forget these 3 pieces of information especially the secret phrase as it's not frequently used. Users also confuse the password and secret phrase.

Configuring Sync can be as easy as just requesting an email address with other credentials randomly generated. Setting up another client would require remembering that email address and a temporary secret.

The premise is that we have a secure low-bandwidth channel (the user's memory) and an insecure high-bandwidth (temporary server storage). The temporary storage is basically a key-value hashtable API provided by the server to keep a "key" and "value" for a short time period, e.g., 1 day.

Account Creation

All that is required for account creation is an email address. A random username and password pair (used to communicate with the server) are generated. The account can now be registered on the server with the username, password, and email address.

A random passphrase (used to encrypt the private key) is also generated. Data can now be encrypted and synced as usual.

1-Roundtrip Additional Client Setup

Starting at the new client, Sync setup would display an 8-digit secret that needs to be remembered temporarily. After returning to an active client, the user enters the secret to setup the new client. The user then needs to return to the new client and confirm the setup to then be able to access and decrypt data.

Prepare setup from new client

When the user wants to add a client to an existing Sync account, the email address is requested, and a 8-digit secret is shown that needs to be remembered.

The client generates a temporary public/private keypair, and the public key is stored on the server as the "value" with the hash of the email address as the "key".

sha1(email): public key

A random 4-digit number is generated to be the first half of the 8-digit secret. This number is used to calculate the second half of the secret.

The second half is calculated using HMAC(public key, first half) and result condensed into 4 digits.

These two values are shown to the user as single 8-digit number.

Confirm setup from active client

After returning to an active client, the user is prompted for the 8-digit secret to activate the new client.

The client requests for the hash of the email address as the "key" to get the public key stored as the "value".

sha1(email): public key

The client verifies that the public key has not been modified by doing the same HMAC(public key, first half) computation and confirms that the result is the second half.

Once verified, the client generates an encrypted version of the account credentials (username, password, and passphrase) by encrypting the data with the public key.

These encrypted credentials are stored on the server as the "value" with the hash of the email address concatenated with the string "result" as the "key".

sha1(email, "result"): pub_encrypt(public key, [username, password, passphrase])

Setup new client

After returning to the new client, the user continues account creation and gets the credentials to access and decrypt data.

The client requests for the hash of the email address and "result" as the "key" to get the encrypted credentials stored as the "value".

sha1(email, "result"): encrypted credentials

With the encrypted credentials, the client decrypts them with its local private key, and then gets access to the username, password, and passphrase.

credentials = priv_decrypt(private key, encrypted credentials)

1-Trip Additional Client Setup

Starting at an active client, the user requests to setup a new client and is shown a token that needs to be remembered temporarily. After going to the new client, the user enters the token to then be able to access and decrypt data.

Prepare setup from active client

When the user wants to add another client from an active client, a random user-editable token is suggested. This token is used to encrypt the necessary account credentials (username, password, passphrase), so the token needs to be strong enough so that the server cannot easily brute-force it.

These encrypted credentials are stored on the server as the "value" with the hash of the email address as the "key".

sha1(email): sym_encrypt(token, [username, password, passphrase])

Setup new client

Setting up another client requires the email address and the token to get the credentials needed to access and decrypt data.

The client requests for the hash of the email address as the "key" to get the encrypted credentials stored as the "value".

sha1(email): encrypted credentials

With the encrypted credentials, the client decrypts them with the token and then gets access to the username, password, and passphrase.

credentials = sym_decrypt(token, encrypted credentials)

Secure High-Bandwidth Channel

A user can skip additional client setup processes described above if there is a method to transfer securely more data than a user could remember. This is also useful for skipping the "prepare-to-setup" steps in cases of backup recovery in the situation where an active client is not available to "prepare."

An "export" functionality would be provided that saves the credentials: username, password, passphrase, and email address in a reversible format that needs to be separately stored and transferred to other clients.

To configure a new client, the credentials would need to be imported, perhaps by copy/pasting from the storage, and this regains full access to the account.