> > 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
