Services/Sync/WEP/100

	THIS PAGE IS A WORKING DRAFT
	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 100 - Password generation from passphrase

• Champions: Dan Mills <thunder at mozilla dot com>
• Status: Draft
• Type: ?
• Created: 17 Jul 2009
• Reference Implementation: None
• WEP Index

Introduction and Rationale

This WEP describes a way of deriving the Weave password from the passphrase, so users will not need to come up with (and remember) two password-like fields to use Weave.

The main thrust of this proposal is to improve the usability of Weave. Users generally don't understand the differences between the two, will attempt to make them the same (or very similar), or forget/confuse them. The net effect is that users find Weave harder to use, annoying, and in some cases (depending on their password/passphrase choices) not actually much more secure.

This WEP uses one-way hashing and salts to reuse the passphrase. At this time it is in need of a thorough security review to highlight areas of increased risk and determine any appropriate measures to mitigate said risk.

Proposal

The basic process for calculating the Weave password shall be:

1. Request passphrase from the user
2. Obtain or generate a random salt
3. Create a digest of the passphrase and salt
4. Repeat step 3 for a set number of iterations

The resulting message digest (of a digest...) is the password.

The premise is that reversing the digest function is quite difficult, thus the hosting provider (Mozilla in this case) will not realistically be able to reconstruct the passphrase from the password and salt.

Those paying close attention may have noticed that the second step is "Obtain or generate..." The typical use-case of Weave presents a difficulty: Users are expected to be able to set-up Weave on several devices without needing to carry any data from one to the next. Thus, the salt must be accessible before authentication so that new devices can generate the password using the above recipe. The proposal is to add an API call to the server for this purpose, and mitigate any added risk by periodically rotating the salt.

The Hashing Function

The harder it is to generate the digest, the better. The current proposal is to use SHA-2, and repeat it for as many iterations as we can. We are limited by CPU and memory constraints on small devices (like phones), so some experimentation may be required. Currently the proposed iteration count is 1024.

The Salt

It is important that the salt be as random as possible, since otherwise an attacker would be able to predict the next salt to come after a salt rotation.

It is also important that the salt be large enough that an attacker would not be able to gain any significant advantage from pre-generating tables (e.g. rainbow tables) for several salts. Given the potentially large Weave userbase, salt collisions between two users should be kept to an absolute minimum.

The proposal is to use 16 bytes for the salt.

Obtaining/Updating The Salt

At account creation, a new random salt will be generated by the client. The server will store the salt and a new API call will be created to query the server for the salt, and API calls to change the password will be modified to include the salt as well.

After account creation, the behavior for obtaining and using the salt will be as follows:

1. If a salt is cached, use it to generate the password using the steps above.
2. Attempt to log into the server using the generated password.
3. If login fails, query the server for the salt. If there is a new salt, retry steps 1 and 2.
4. If login still fails, abort.

Thus, any client may change the salt and password, and other clients can detect the error condition and automatically (and invisibly to the user) update to use the new salt.

The proposal is for the server to warn clients that the salt is stale and in need of updating, and for clients to go through the above procedure automatically. The server may also disable an account that has not had its salt+password updated in a long time (possibly several months).

Why Rotate The Salt

The idea is to reach a balance between convenience and security. Having the salt be publicly accessible opens users up to additional risk:

1. An attacker could use the salt and do a brute-force attack by hashing likely (or all possible) passwords.
2. In hypothetical scenario where Mozilla's password database is leaked, an attacker would have the additional advantage of having the final digest (so the passphrases could be cracked without needing to repeatedly attempt to login to Weave.

Periodically changing the salt makes these attacks more difficult. How often to rotate is an open question, but we hope we can do it as infrequently as once every few months.

There is a lower bound on how often the server can require a salt+password rotation. Most users will occasionally go on vacation, etc. and cannot be expected to keep one device on so it can rotate the salt, even if it is automatic.