+Ryan Kelly since password reset involves accounts Very interesting article Ryan. I look forward to seeing what password reset UX alternatives you will propose. I was under the impression that SMS wouldn't work for us. Do you think that SMS could be a viable option?
Thanks for sharing. -- Alex Davis // Mountain View Product Manager // FxA & Sync (415) 769-9247 IRC & Slack: adavis On Tue, Sep 13, 2016 at 12:06 PM, Ryan Feeley <rfee...@mozilla.com> wrote: > I've begun researching good examples for security questions, as I imagine > they are hard to solicit unique and memorable responses across the globe. I > came across this paper by Google that is essentially declaring them dead. > https://security.googleblog.com/2015/05/new-research-some- > tough-questions-for.html > They make the case for SMS as it's twice as successful as security > questions. > > On Tue, Sep 6, 2016 at 11:13 AM, Alex Davis <ada...@mozilla.com> wrote: > >> 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 <ckar...@mozilla.com> >> 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 <rhubsc...@mozilla.com> >>> 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 >>>> Sync-dev@mozilla.org >>>> https://mail.mozilla.org/listinfo/sync-dev >>>> >>>> >>> >> >
_______________________________________________ Sync-dev mailing list Sync-dev@mozilla.org https://mail.mozilla.org/listinfo/sync-dev
