On 8/12/13 6:55 AM, Lloyd Hilaiel wrote: > What are the cons of reducing the security of recoverable class A data > such that it could be accessed with a persona assertion asserting > ownership of the email address stored in your account?
If I understand you correctly, the proposal is to replace the "help I forgot my password" flow from: 1: we email you a code, you type the code into your browser, you replace the password with something you can remember to 2: you use that browser to get a Persona assertion for the email, then you replace the password with something you can remember If that's correct, I'm all in favor of the change. I don't even think it's a reduction in security, especially if we improve the Persona email-verification like you suggested. Using Persona for this would allow IdPs to use other (non-email) authentication mechanisms, which is is part of the whole enabling-competition story of Persona. There are technical details to figure out (the assertion should probably be delivered to chrome code instead of a web page, so figuring out what the audience should be is non-trivial), but overall I think it's the right thing to do. If you meant "instead of typing in a password to connect a new browser to the account, you use an assertion", then 1: that won't give access to any class-B data, and 2: we can't provide the "changing your password causes other devices to be disconnected" behavior, because we wouldn't have a password. If we were offering a class-A-only service, it could work. Toby> Is the idea that the data would sit on the servers unencrypted? Toby> How far reduced are you thinking? Class-A data is encrypted by a key which lives on our key-server. We have access to that key, which means we can be coerced into revealing it. From the user's point of view, it's mostly just encryption-at-rest (which is either "best practice", "defense in depth", or "CYA", depending upon your mood that day). The one improvement over completely transparent server-side encryption is that the IdP (or someone who can create valid Persona assertions for that address) must actually reset the account password first, to learn the class-A key. This leaves a trail (for us to see), and the user can discover they've been a victim because they won't be able to log in (they'll have to reset the password again before they can get in). Karen> From previous discussions when we initially settled on class B Karen> several months ago, that felt like a really good place as default Karen> for most of our data types. Like the others are asking, What's Karen> the benefit of moving it to class A? This will help me understand Karen> the pros / cons of changing our recommendation from a while back. I don't think Lloyd is talking about switching any defaults from B to A. I think he's just talking about changing the way you recover your class-A data. As far as I know, we still haven't decided what the defaults ought to be. I agree that B is a good default for most of our datatypes. cheers, -Brian _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
