Identity/CryptoIdeas/03-ID-Attached-Data: Difference between revisions

Identity/CryptoIdeas/03-ID-Attached-Data (view source)

Revision as of 03:33, 6 February 2013

22 bytes removed , 6 February 2013

m

→‎Data Protection Classes

Warner

Confirmed users

471

edits

@@ Line 19: / Line 19: @@
 the data is in:
-* class-A "available": this key is available to anyone who can produce a
+* class-A "available": this key is available to anyone who can produce a valid BrowserID assertion, so includes the end user, their IdP, and anyone who can spoof whatever the IdP uses to identify the user (typically an email challenge, so this includes network attackers who can redirect or snoop on SMTP traffic). Any user who can still convince their IdP to let them log in will be able to recover their class-A data, without remembering any other secrets or having any devices remaining.
-  valid BrowserID assertion, so includes the end user, their IdP, and anyone
+* class-B "brute-forceable": this key is wrapped with a (derivative of a) user-memorized "master password". A limited set of parties (anyone who can read the class-A data) will have enough information to attempt a brute-force attack on the password, but storage servers and the rest of the world will not. The user must remember their master password and be able to log into their IdP to get this data back.
-  who can spoof whatever the IdP uses to identify the user (typically an
+* class-C "confidential": this key is created by the user's first client, and transferred to their other clients with a pairing protocol (PAKE), facilitated by a central server but not vulnerable to it. No external parties will be able to read this data. The user must have at least one functional paired device (or a manual key backup) to recover this data.
-  email challenge, so this includes network attackers who can redirect or
-  snoop on SMTP traffic). Any user who can still convince their IdP to let
-  them log in will be able to recover their class-A data, without remembering
-  any other secrets or having any devices remaining.
-* class-B "brute-forceable": this key is wrapped with a (derivative of a)
-  user-memorized "master password". A limited set of parties (anyone who can
-  read the class-A data) will have enough information to attempt a
-  brute-force attack on the password, but storage servers and the rest of the
-  world will not. The user must remember their master password and be able to
-  log into their IdP to get this data back.
-* class-C "confidential": this key is created by the user's first client, and
-  transferred to their other clients with a pairing protocol (PAKE),
-  facilitated by a central server but not vulnerable to it. No external
-  parties will be able to read this data. The user must have at least one
-  functional paired device (or a manual key backup) to recover this data.
 The idea is that users can choose which browser data goes into each class.
 Sensible defaults would probably put Password Manager data into class-B, and
 bookmarks into class-A, but users should have the option of putting
-everything into class-C if they like (to behave like FF Sync).
+everything into class-C if they like (to behave like current FF Sync).
 == User Options ==