Confirmed users
471
edits
Identity/AttachedServices/Architecture: Difference between revisions
Jump to navigation
Jump to search
Identity/AttachedServices/Architecture (view source)
Revision as of 18:42, 4 June 2013
, 4 June 2013→Data Security
(start to replace with our current design) |
|||
| Line 29: | Line 29: | ||
We are exploring various models for data security: https://wiki.mozilla.org/Identity/CryptoIdeas/03-ID-Attached-Data | We are exploring various models for data security: https://wiki.mozilla.org/Identity/CryptoIdeas/03-ID-Attached-Data | ||
The | The user will have a single "PICL Password", which they must type into the browser during the sign-in process. The user's browser proves (to the Key Server) that it knows this password. From this, it obtains data-encryption keys and a signed certificate that authorizes Storage Server reads and writes. No server learns this password directly: the closest they come is the Key Server, who receives a stretched "verifier" (which only enables a brute-force dictionary attack). | ||
User data is stored in one of two categories. Anything put in the "Class-A" category can be recovered as long as the user can still access their email (i.e. get a Persona assertion for it from their IdP), and consequently is also technically retrievable by the operators of that IdP and the Key Server (or someone who compromises either). Data put in the "Class-B" category requires the PICL password to retrieve: it cannot be recovered when the password is forgotten, but (if the password is well-chosen) cannot be retrieved by the IdP or any other server-side attackers. | |||
We do not yet know which data will be assigned to which category by default, but it is likely that saved-passwords will go into class-B, and many other datatypes will default to class-A. There will be an option to put all data into Class-B. | |||
== Service Interface == | == Service Interface == | ||