Services/Sync/KeyRecovery: Difference between revisions

Services/Sync/KeyRecovery (view source)

Revision as of 06:06, 26 September 2011

446 bytes added , 26 September 2011

no edit summary

Rfkelly

Confirmed users

358

edits

@@ Line 116: / Line 116: @@
 To access the recovery service, the user must provide an "auth token" to prove their credentials.  I see two possibilities: server-generated tokens and user-generated tokens.
+=== Wider Implications ===
+Since this service effectively reduces the security of the user's sync data to the security of their account password, we need to consider the wider implications for password management across all Services products.
+Account management and authorization in Services currently uses HTTP-Basic-Auth, and hence transmits the password to Mozilla in the clear.  Thus, users of the recovery service are trivially vulnerable to us snooping on them, or to anyone who manages to compromise any of our servers.  That's bad.
+Ideally, we would move to a system that can provide authentication without the server learning the user's password.  See [[Services/Sync/SecureAuthentication]] for a discussion.  Such a move will have to happen across the whole services infrastructure to be worthwhile.
+Open Questions:
+* if this key-recovery service lives in a high-security cage or other special server environment, should the auth system also live there?  Any breach in the auth system is basically an automatic breach in the key-recovery system. (e.g. why steal the encrypted recovery data and try to brute-force it directly, when you can steal the password database, dictionary-attack the weakly-hashed passwords, then use them to unlock the recovery data?)
+* if the key-recovery service and the auth service both live on the same infrastructure, does it make sense to split them up?  Can we just make the "recovery data" an extra property stored by the auth service?
 === Server-Generated Tokens ===
@@ Line 160: / Line 172: @@
 The disadvantage is that it can't be used to authenticate the initial upload of the recovery data, so there's a bootstrapping problem.
-=== Wider Implications ===
-Since this service effectively reduces the security of the user's sync data to the security of their account password, we need to consider the wider implications for password management across all Services products.
-Account management and authorization in Services currently uses HTTP-Basic-Auth, and hence transmits the password to Mozilla in the clear.  Thus, users of the recovery service are trivially vulnerable to us snooping on them, or to anyone who manages to compromise any of our servers.  That's bad.
-Ideally, we would move to a system that can provide authentication without the server learning the user's password.  HTTP-Digest-Auth at a minimum.  Something like the Secure Remote Password Protocol would be even better, but there's no current standard for integrating this into the HTTP-Auth workflow.
-In any case, since such a move will have to happen across the whole services infrastructure to be worthwhile, it's largely orthogonal to the development of the key recovery service itself.
 == Keeping Things in Sync ==