Planned

:bulb:

Two-factor authentication (2FA)

Make logging into the web site require an extra code from Google Authenticator or similar app.

49 votes

Tagged as New feature

Created 09 January 2018 by Josh Sharp

Moved into Planned 12 June

  • Sign in to comment and vote. Sign in by email
  • avatar

    With the breadth and types of data collected here, 2FA seems like almost a must have.

    30 March 2018
  • avatar

    Agreed, this doesn’t seem like a feature to be voted on, but bare minimum security. You guys do amazing work, having this in place would fit with that.

    25 June 2018
  • avatar

    This seems like a no-brainer. Any reason not to? And I would suggest app-based such as Google Authenticator or Authy, not SMS based

    05 February
  • avatar

    TFA would be important for such sensitive data. I don’t think it’s necessary to reinvent the wheel, Google Authenticator (I also prefer to use it with Authy) would be a good and simple solution.

    09 April
  • avatar

    I want to support this using TOTP (e.g. Google Authenticator) but just want to read up on best practices around recovery codes first, and things like manually authenticating a user who has lost their second factor. I’m not keen on needing scans of official government IDs, for example, so I’ll need to look into what’s recommended.

    12 June
  • avatar

    I’m not keen on needing scans of official government IDs, for example, so I’ll need to look into what’s recommended.

    I would also like to avoid doing this :).

    I would strongly suggest implementing WebAuthN as it’s a comprehensive solution to the 2nd factor authentication problem and supports the traditional yubikey like dongle AND some of the newer 2nd factor auth devices like google titan.

    https://www.w3.org/TR/webauthn/

    As far as account recovery goes, there’s no ideal way to do it w/o a trusted 3rd party / third form of authentication that can confirm an identity. The best compromise is to use email and set the impetus so that users must keep their inbox reasonably secure and give users very simple tools to quickly report a stolen 2nd factor auth device and to monitor where else their account is logged in at / revoke those sessions.

    TL;DR: WebAuthN is the new/best way to implement a second factor of auth. Account recovery codes are more secure than a SMS fall back, but there is no good solution to restoring a users account if they loose access to both their inbox and their 2nd factor. It should not be on the exist.io team to engineer around a user that does not keep their inbox secure. Tools that allow users to monitor their “active” exist sessions (time, user agent, IP address) and quickly revoke other sessions are the best defense against an adversary that Exist can be reasonably expected to provide

    12 June
  • avatar

    Having a phone number on the account with a verification text can be used a backup for TOTP or WebAuthn 2fa as well.

    12 June
  • avatar

    Coming from a security background, I definitely agree RE: WebAuthN being the way forward, but I strongly disagree on the email part of this:

    As far as account recovery goes, there’s no ideal way to do it w/o a trusted 3rd party / third form of authentication that can confirm an identity. The best compromise is to use email and set the impetus so that users must keep their inbox reasonably secure and give users very simple tools to quickly report a stolen 2nd factor auth device and to monitor where else their account is logged in at / revoke those sessions.

    If I get access to your email, I get access to your password reset. The whole point of 2FA in this instance is that I can’t, with a single point of access, takeover your account. So if you allowed 2FA reset just with an email, you’d basically be nullifying that protection.

    /2c

    12 June
  • avatar

    We have users sign up who don’t even know what email address they used, or who entered an incorrect one, so I also think it needs to be something other than email. Or I need to add email address verification when I add this. SMS makes sense, but then there’s two external dependencies to add, TOTP and SMS… we’ll see. Thanks everyone!

    13 June
  • avatar

    Webauthn looks nifty, but there are a bunch of browsers that don’t support it, mostly Apple. TOTP seems to be the standard with most services because it doesn’t require a specific browser, and I love how it works with 1password.

    13 June
  • avatar

    2nd factor is mostly to prevent against password reuse/stuffing. A compromised inbox negates a ton of the common security mechanisms… especially if the adversary can hide sent messages!

    I wish i couldn’t name people that keep their MFA fallback codes as a Draft message in their Inbox or in the “sent” folder if they use an email to print service.

    My inbox is more secure than my SMS inbox… especially if the sending mail agent can present a client certificate to my mail server.

    13 June
  • avatar

    Or I need to add email address verification when I add this.

    Wasn’t this already required for password recovery? Either you look up my user name and send a token to my inbox or i give you an address and you confirm that’s associated with an account and send the token…

    13 June
  • avatar

    Sure, an email address is already required. I mean “verification” as in you need to confirm that the one you entered when you signed up is correct by receiving an email and entering a code from it, clicking a link, etc., which is not something we currently do, but is needed.

    14 June
  • avatar

    This is the conclusion I came to as well. TOTP seems simple and better supported.

    14 June
  • avatar

    I would encourage you to re-think TOTP ve WebAuthN and this feeling that you “must” implement a fallback.

    This is a very current summary of the trade-offs between the various 2nd factor auth implementation strategies:

    https://blog.trailofbits.com/2019/06/20/getting-2fa-right-in-2019/

    Two things that i feel are worth repeating again:

    WebAuth is not, however, limited to security keys: as mentioned earlier, Google is working to make their mobile devices function as WebAuthn-compatible second factors, and we hope that Apple is doing the same. Once that happens, many of your users will be able to switch to WebAuthn without an additional purchase.

    WebAuthN supports “virtual” devices that can be built ontop of “commodity” secure hardware. Yubi Keys are what everybody thinks of, but the google Titan keys can also be an app on some phones (currently, only pixel 3 has the proper hardware root of trust, but more Android OEMs will build this into their phones in the future)

    and most importantly:

    Recovery codes should be available and should be opt-out with sufficient warnings for users who prefer their accounts to fail-deadly. Recovery codes are not second factors — they circumvent the 2FA scheme. However, users don’t understand 2FA (see below) and will disable it out of frustration if not given a straightforward recovery method. When stored securely, recovery codes represent an acceptable compromise between usability and the soundness of your 2FA scheme.

    Recovery codes are not second factors — they circumvent the 2FA scheme.

    I maintain that the user is responsible for keeping their credentials secure. Using ANY recovery technique works to negate the entire point. For this reason, the ultra common techniques of SMS/Voice fallback or downloaded codes should be not an option or only available after clicking through a few very scary ™ “this puts you at grater risk; please have a moment to consider the value of the data and weather you’d prefer to be locked out forever or risk allowing others in” type warnings.

    I would obviously prefer a WebAuthN only implementation that becomes more accessible to users over time (as soft webauthn devices/apps become more common place) rather than a vastly inferior MFA strategy based on SMS/Voice that will increasingly become insecure.

    I can understand that this is a rather “hardline” viewpoint, so i’d expect that most users would prefer and benefit most from support for the “traditional” TOTP code based approach. Under no circumstances should SMS or Voice be used to transmit the 2nd factor of auth.

    I’ll leave you with this:

    Most importantly of all: the fact that TOTP is not as good as a hardware key is not an excuse to continue allowing either SMS or voice codes.

    CC: @glengrant

    Friday