With the breadth and types of data collected here, 2FA seems like almost a must have.
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
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.
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.
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
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
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!
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.
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.
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…
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.
This is the conclusion I came to as well. TOTP seems simple and better supported.
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
Absolutely necessary today for every service but especially for aggregate services such as Exists.io!
Oh lord can we not. If I have to two-factor auth one more thing in my day I’m going to go full on pants-on-head bananas. How about no two factor if in marked safe zones, safe PCs, within proximity of a paired wearable … ?
I wouldn’t be in favor of the app requiring users to use 2FA, but it should be an option for those who want it.
Right, we were never proposing to make it required, it would be opt-in.
Opt-in TOTP is my vote. No special recovery needed - users opting for TOTP (in general) need to be able to manage their own recovery. For those not comfortable with that, SMS 2FA seems like the only viable “general audience” solution today, but I always opt for TOTP instead where possible due to the prevalence of SIM-swap attacks these days.
2FA is really important when there is so much data!
Wait, all this personal data that’s being collected - what if you went the other way and gave us options to monetize it by selling it to companies?!
(I know some people will be vehemently against this; I’m only suggesting it as an option for those of us for whom our privacy is less valuable than cold hard cash! I don’t want to force everyone to sell their data!)
While it’s not up to us to tell users what to do/not do with their data, this isn’t something we would ever support as part of Exist.
It’s also not particularly relevant to this suggestion and the discussion around its implementation, but feel free to start a topic in our user forum if you want to chat about this further with other users.
FWIW: use WebAuthn/FIDO2, not TOTP. It’s 2023 now, we don’t need more code-generators! 😅