Thanks Chris for sharing. I have a 1:1 with RFeeley today and we will look over this together.
-- Alex Davis // Mountain View Product Manager // FxA & Sync (415) 769-9247 IRC & Slack: adavis On Fri, Aug 26, 2016 at 4:44 PM, Christopher Karlof <[email protected]> wrote: > Let me take this opportunity to make sure this problem is framed correctly: > > *Our goal is increase user success and satisfaction in their experience > using Sync, specifically when connecting additional devices.* > > The obvious problem that’s been identified is that in the current system, > when users go to login to FxA (for Sync or otherwise), many user’s > instinctive reaction is to "login via reset password”, either because they > don’t remember it or they just think it’s easier. This, of course, will > create a sad time, because after the password reset, none of the data they > are expecting will appear, and just to rub it in, your currently connected > devices will be disconnected. Sad times all around. > > I see two high level approaches to address this problem: we can either > limit the consequences of resetting your password (e.g., start using kA) or > create flows that make it less likely users will trigger the password reset > flow described above. > > Either way, the flows we create have to be simple, easy to use, and > understandable (and of course, secure), because otherwise it’s unlikely > we're increasing user success and satisfaction. Many of the approaches > discussed here don’t seem that simple to me, either from the implementation > POV or user POV (or both). We can likely eat implementation complexity if > it results in a simple user flow, but unlikely the other way around. > > I feel it would be great to do some structured brainstorming around these > two general approaches that persistently captures the pros and cons of > various approaches (outside of an email thread) and perhaps enables people > to vote on the most promising ideas. It could even lead to a Google > Ventures style sprint. *Ryan F. or Alex [1], could you take the lead > here?* > > Me personally, I have two favorites, one that limits consequences of reset > and one that tries to reduce the frequency of resets: > > 1) I’d love to understand what it would take to start using kA for some > datatypes (technically, legally, and operationally). > 2) I’d love to see how good we could make various pairing flows as an > alternative to password reset, and if we can get users to use them. > > -chris > > [1] Both Ryan and Alex are out next week, so my timing is perfect. > > > On Wed, Aug 24, 2016 at 12:44 AM, Rémy Hubscher <[email protected]> > wrote: > >> Thank you for your answer Richard. >> >> > Ryan's thread is about ways we can give those users an experience >> closer to Dropbox: reset your password but keep your data. >> > >> > It sounds like you're talking about the space on the other side: >> reducing the dependence on a single password. >> > Am I reading you correctly? >> > >> > 2FA could be part of a key escrow solution, but probably isn't enough >> protection on its own. >> Yes it makes sense. >> >> Regards, >> >> Rémy >> >> Le 23/08/2016 à 18:01, Richard Newman a écrit : >> >> I like the idea of having an encryption key that is generated randomly. >>> >> We used to do that. The difficulty was in moving it around between >> machines. We used J-PAKE to exchange credential bundles, but that required >> users to have both devices together at the same time. We used >> printable/savable keys, but those are hard to type. And of course, users >> didn't remember to save the third credential. >> >> Getting away from the harm caused by strong random keys was the core >> motivation for FxA's existence: the second or third try at a better login >> experience for Sync (indeed, the second attempt called "Firefox Account"!). >> >> >>> This encryption key could be encrypted and decoded using kB and stored >>> decrypted on the user computer so that when users change their password the >>> encryption key can be re-encrypted with the new kB. >>> >> This is what happens with the Sync keybundle when you change your >> password. >> >> >>> However, I usually use the "forgot password" feature when I am >>> connecting a new computer to Sync and in that case the new computer doesn't >>> have the previous encryption key. >>> >> That's why Sync 1.5 uses kB, derived from your password, as the root of >> its crypto: users are not good at managing keys. >> >> >> >>> "You changed your password, please login with your new password from a >>> previously connected computer to update your encryption key and sync your >>> data." >>> >> >> That's what we do now: when you change your password on one device, you >> need to log in again on all of the others. >> >> We tried pairing-based UX flows before, and didn't have much success. >> >> >> I personally like the fact that the "forgot password" feature prevent an >>> attacker from using it to grab my Sync data. >>> >> >> Then it sounds like current Sync 1.5 is a good fit for you! And I don't >> think anyone is suggesting that we don't continue to support that level of >> resistance. >> >> >> >>> However it is still possible for an attacker with my password to do so. >>> Could we have a 2FA workflow that could help us there or maybe even a key >>> recovery process based on the fact that the user have got their registered >>> device with them? >>> >> >> I think you're talking about a different direction. >> >> Sync is currently fairly biased towards security: I'd guess 99% of the >> time a password reset is a user who forgot their password, not an attacker, >> but we force those users to lose their server data. Ryan's thread is about >> ways we can give those users an experience closer to Dropbox: reset your >> password but keep your data. >> >> It sounds like you're talking about the space on the other side: reducing >> the dependence on a single password. >> >> Am I reading you correctly? >> >> Ryan's last question is key here — a user who already has a device >> connected to Sync doesn't need to lose their data. They can turn a password >> reset into something equivalent to a known-kB password change. >> >> From my perspective, 2FA could be part of a key escrow solution, but >> probably isn't enough protection on its own. >> >> >> >> _______________________________________________ >> 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
