Show HN: Generate shared 2FA codes for your entire team

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.

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.

> secrets are not static, unlike passwords

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?

"need to" is a bit much. One should absolutely regenerate keys but to every attackers delight (and every CISO's chagrin), that doesn't make it actually happen. For things that need to be secure, (forced) expiration of keys is an important part of the system as a whole.

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.