Geeze, first I'm sorry for making you speculate my intent. More color inline.
On Aug 20, 2013, at 2:55 AM, Brian Warner <[email protected]> wrote: > 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. I actually wasn't even thinking of optimizing the reset password flow with persona. But that generally this is possible seems like something we can leverage later to streamline the experience. > 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. Got it, understand, and agree. The interesting post-milestone-1-crazy-talk optimization here is that we could actually sync class A data without a password, right? If a user has an active session with their email provider and that provider is persona-enabled. Then, while there are some technical details, we could have a two click sync set up experience leveraging the fact that the email verification step is already done. There's a lot to figure out here and room for skepticism, but this is one tangible optimization we gain when we have the property that a subset of your firefox account is accessible via proof-of-email-ownership. > 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). +1 > 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. +1 > 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. Per-data-type classification is extremely interesting. Meta, one thing that seems like it would be really nice to have so that we don't have to be 100% right the first time, is an easy ability to change the defaults and cause clients to re-encrypt. I think this is the tiny consideration that gives us the freedom to get the defaults wrong. (inline with the work already we're already doing to avoid future flag days, I expect - probably already figured out and totally redundant :) lloyd > cheers, > -Brian > _______________________________________________ > Sync-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/sync-dev _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
