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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
