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 <[email protected]> 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 <[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
