Totally get the use case for this, lots of shared accounts in IT, been a problem for years that gets solved in a number of ways. Sometimes clever, sometimes barely duct tape.
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.
Of the two 1password for teams is much better, the user interface on LastPass Enterprise is this horrid monstrosity that keeps flipping you between web pages and a native interface for basic account maintenance. 2FA required a separate client altogether though they might have integrated it just as I was saying goodbye. In 1password it is seamless.
Not just that... you're also sending those 2FA codes through yet another third party service (Slack), so you have two places where your security can be compromised.
I can see the use case in this (even though it entirely defeats the purpose of 2FA) but one glaring omission I see on the homepage screenshots is the lack of an audit log. I supposed I could trust others with one-time codes, but I'd like to verify that nobody is doing anything funky (e.g. a disgruntled employee or a compromised account) in a quick who-did-what-when dashboard, maybe even with a notification when someone is requesting a lot of codes.
If access requests are actually being logged, the audit dashboard deserves a place on the home page in my opinion.
At the moment I don't log/track anything (I don't even store user emails), but I can see an audit trail being extremely useful. Thanks for the suggestion!
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).
This is absolutely perfect for a use case that I've seen a lot: shared test accounts. Eg our app connects to external service X, so we have a staging account set up such that the staging version of our app can operate. But service X values security and requires 2fa on all accounts. This is really annoying, especially if service X is expensive and charges per seat. We don't want to pay for a seat for all of our developers just for our test account, so we share credentials, which is a pain in the ass with required 2fa. A slack-based shared 2fa account would be perfect for this.
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.
It doesn't say, but I presume these are TOTP codes, and there is just a single generator that you're sharing and thus one shared secret.
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.
Yup this is indeed a limitation in that once a code is used, the next person essentially has to wait at least one minute before they can get another working code.
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.
Like most of the services popping up around 2FA, now that 2FA is popular: this essentially removes one of the factors.
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.
Most people have their phone as a 2FA device, but they will login to websites/services on their phone anyway. Would you suggest preventing logins from phones?
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.
I get the use case, but I just can’t get behind using software like this for security reasons. It’s too easy to add users to slack, leading to accidentally exposing secrets.
One conscious decision made when building this was not to blast 2FA codes inside some channel where potentially anyone can see them, which would indeed be pretty bad when users are constantly being added to your Slack workspace.
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.
It looks like with this service the user who can generate a TOTP can't see the backing seed. Therefore, if they leave, and get removed from Slack, they can't generate a code.
If you just shared the seed then everytime someone left the team you'd need to regenerate.
Bitwarden, and the fantastic rust-built equivalent Vaultwarden can be self-hosted, include granular, multi-user sharing of credentials which may contain TOTP secrets.
The web GUI, various plug-ins, and apps can all then generate the TOTP codes.
Can't the login with 2FA be shared with the team in 1Password, because 2FA alone is not enough to share a login. Not that sharing logins is a smart thing to do, but people still do it to go around per-seat pricing.
For that one vital service which doesn’t support multiple users on a single account (or locks it away behind an eye-wateringly expensive enterprise plan). Every org has one, for a long time in mine it was access to the Alexa developer console, which supported a single Amazon account being able to publish updates.
If you find yourself in this situation and use 1Password for business you can share credentials, including a TOTP token, using that.
Would recommend hashi vault in place of this which can work for human/non-human workflows and a pretty robust security model with better auditing and authorization than slack. https://www.vaultproject.io/docs/secrets/totp
ShakataGaNai|4 years ago
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.
zxcvbn4038|4 years ago
tgsovlerkhgsel|4 years ago
jeroenhd|4 years ago
If access requests are actually being logged, the audit dashboard deserves a place on the home page in my opinion.
hansy|4 years ago
LethargicStud|4 years ago
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).
fishtoaster|4 years ago
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.
auslegung|4 years ago
weird-eye-issue|4 years ago
tialaramex|4 years ago
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.
hansy|4 years ago
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.
remram|4 years ago
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.
tedk-42|4 years ago
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.
joshdev|4 years ago
hansy|4 years ago
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?
tossaway9000|4 years ago
rmetzler|4 years ago
chews|4 years ago
jamesvnz|4 years ago
jeffalyanak|4 years ago
The web GUI, various plug-ins, and apps can all then generate the TOTP codes.
nikolay|4 years ago
whoknew1122|4 years ago
You're trusting teamFA, Slack, and each team member's Slack accounts. This seems like a security nightmare.
kevinlst|4 years ago
antondd|4 years ago
jon-wood|4 years ago
If you find yourself in this situation and use 1Password for business you can share credentials, including a TOTP token, using that.
1cvmask|4 years ago
[deleted]
weirdo28|4 years ago