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.
I'm not sure I agree with that. There's a lot of different values provided by 2FA which this preserves:
- 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 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?
Using a separate device (yubikey, mobile phone, etc) is always recommended, but this is a bit more secure than meets the eye. Someone would have to get access to your Slack account to view the codes, and to do that, they'd have to first get access to your work email (because Slack is password-less and emails auth links to you).
To do this semi-securly (because slack accepts regular passwords) you'd need validate the user's own mfa before handing out these mfa creds to prevent a slack account compromise from escalating... but slack can't do that unless there was an extension in the plugin somehow to prompt for an otp code.
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?