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
