This is much nicer looking. But... and it's a very big but... why would you trust this service? You're giving random person on the internet your 2FA secret keys. Their TOS & PP don't even mention encryption. I'm not saying you can't do something like this, but I'd be extremely hesitant using something for a very high security purpose that is probably done by one person as an MVP.
There are other options, 1Password and LastPass both support 2FA TOTP codes. If you trust those, they are "better" for security. Do they have some of the features and convenience of this service? No. But at least you already trust them for high-security usage.
If access requests are actually being logged, the audit dashboard deserves a place on the home page in my opinion.
The webauthn spec has public/private keys incorporated: https://www.w3.org/TR/webauthn-2/#sctn-sample-registration
There should be no risk to storing all your public keys in e.g. 1password. When signing up for e.g. facebook.com, you should be able to hit a button and have all your keys registered at the same time. You can send $site all your public keys, and sign auth reqs as you log in. Of course, the UX would be handled by webauthn, so you'd really just be tapping your yubikey or scanning your fingerprint on login.
Ideally, password managers would offer key servers that websites could hit in real-time to pull your public keys. That's probably a stretch - maybe websites could sync your 2fa pub keys in the background.
With such a model:
1. Having multiple yubikeys
2. Having multiple team members with access (same as 1, effectively)
3. Revocation of individual 2fa devices
4. Adding 2fa devices after account creation
Would be pretty trivial.
I assume there's something basic in the webauthn protocol that I'm overlooking that prevents such a model. What is it, and why can't we have these properties?
I for one don't want all my accounts to hinge on access to a single physical device, and I certainly don't want to register 10 yubikeys with every service (some I may not even have physical access to on a day-by-day basis).
I'd be pretty hesitant to use something like this for accounts I consider sensitive, though, because
A. It's too easy to accidentally add the wrong person to slack, and ideally not everyone at the company has access to all accounts anyway, and
B. It's putting more trust into a third party (tfa.one) than I'd be comfortable with, given how new it is.
But again, perfect for our test accounts, and cheap enough that I don't even need to think about it.
This has some surprising consequences, e.g. a conformant TOTP implementation marks off your recently used codes, making them actually one time, but if a dozen employees log in ready for the 0900 start between 08:59 and 09:01 and need one code each, the system cannot in fact generate them 12 different codes, there aren't twelve codes, so, some of them can't use the shared 2FA codes.
Accepting this, the value of the secret being owned by this service (hopefully not controlled by bad guys) rather than employees have their own secret (preferable but I can see arguments this could be unwieldy) or all having the same shared secret on their local device (trivial to implement) seems dubious.
If you find that enrollment is a constant pain due to high turnover, I'd argue the high turnover is the real problem, what are you "authenticating" with such high turnover? If you've got most team members for a week or less (which is where that starts to feel very painful) I don't see what can be authenticated, that's not even long enough for a superficial background check to complete, so you pretty much have no idea who these people are anyway. If you don't much trust them (and why would you) then two factors seems excessive.
If your pain isn't enrollment but usage, two things: One, better Single Sign On can get you to a world where people are only authenticating a few times per day at most, instead of for every separate service, and Two, WebAuthn (and other FIDO tech for e.g. SSH) can get you to a world where authenticating is a single action and feels very painless which getting and re-entering six digit codes is not so do that where possible.
My target is smaller teams, where collisions (hopefully) happen less frequently. If you're a bigger org, chances are you also have the resources to just buy everyone their own seat/license to the account instead of relying on the employees to share one account.
My OATH HOTP/TOTP implementations are here:
Whether you're making one of the factors available to everyone on Slack, or putting it next to the password in LastPass, the result is the same, you delete the security benefits of 2FA.
The REAL benefit of TOTP is that it's time sensitive. If someone does have your password and TOTP code over the wire, they cannot repeat the attack.
I think this service is fine, but as others have pointed our you're giving away for TOTP secret to a third party which makes them a very good target for attackers looking to score a pot of gold.
Instead they just have your session cookie, which probably doesn't expire for six months.
The real benefit of 2FA is unlike passwords, users cannot make stupid choices, like use the same one for multiple websites or the password "password". The User is usually the weakest link, 2FA reduces reliance on the user behaving appropriately.
Using a password manager on your phone turns it into just something you own.
Instead, codes are fetched by explicitly using the slash command and only users who are granted access to them can see them. So if a new person joins your team and types `/tfa` into the box, they won't see anything because nobody has given them access to any codes.
Does that make sense?
- secrets are not static, unlike passwords, reducing risks from logging/monitoring code or certain types of keyloggers (especially hardware keyloggers)
- secrets cannot be human-generated and are known to be high-entropy (password managers can also effectively ensure this)
- secrets cannot be shared across multiple websites (password managers can also effectively ensure this)
- you can revoke access to someone's future ability to authenticate without having to change passwords
Depending on exactly how you choose to implement it (namely, how you choose to set up Slack logins/SSO), you might also get
- login effectively requires attestation of identity that are independent of "knows a secret," such as "has a certain physical object" or "is coming in from a particular network" or "passes certain behavior checks/hueristics"
You don't get
- long-term secrets cannot be stolen by malware because they are fixed in a physical object
- the 2FA mechanism is capable of authenticating only to the specific website, eliminating phishing risks (password managers can also effectively ensure this)
but if you're not using a hardware code generator (and possibly not even that, see also the RSA seed breach) or a WebAuthn device, you aren't getting those anyway.
The web GUI, various plug-ins, and apps can all then generate the TOTP codes.
You're trusting teamFA, Slack, and each team member's Slack accounts. This seems like a security nightmare.
If you find yourself in this situation and use 1Password for business you can share credentials, including a TOTP token, using that.
The TOTP secret is static. The one time codes are just trivially generated from the secret. Now, TOTP is designed to use a cryptographic hash function (I assume SHA-1 is still being used in this case, which is short of ideal but it's not the weakest link here) and so it isn't practical to unwind the hash and get the actual secret but...
> you can revoke access to someone's future ability to authenticate without having to change passwords
The agent knows the secret and so can generate any such codes at any time, I assume it's hard to convince it to give you codes for tomorrow or next Wednesday but who knows?