Show HN: Generate shared 2FA codes for your entire team(tfa.one)
tfa.one
Show HN: Generate shared 2FA codes for your entire team
https://tfa.one
42 comments
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.
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!
This works around a real problem I'm surprised nobody has solved - the ability to register a bunch of keys at the same time.
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).
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).
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.
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.
Do you know 1password handles storing mfa codes?
Yep! I use that with my personal 1password. And honestly, that's probably the way we'll go eventually, but right now we're a super tiny startup - setting up a team 1password and getting every new engineer onboarded seems like a hassle. Even if it's only a few hours of work, tfa.one seems like it's a few minutes of work. For non-sensitive accounts (which is the main pain point I have at the moment), a 1-step tool is awesome. :)
I thought 1password only allows storing MFA codes for pre-determined sites? Eg it doesn't provide a MFA option for microsoftonline.com.
It prompts for some sites (using some .well-known URL protocol?). But I recently learned you can add the "One Time Password" field type to any Login entry manually. I do it all the time for intranet/test sites that need MFA and I have done it with sites that didn't prompt that are shared in our family (home) and team (work) 1Password vaults. The field time lets you scan a QR code or enter the seed key manually
Huh that's awesome I didn't know it had that feature. Cheers!
Bitwarden does this too
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.
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.
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.
That's a feature (not a limitation) of TOTP. Also, the time step defaults to 30 seconds, but can be changed: https://datatracker.ietf.org/doc/html/rfc6238
My OATH HOTP/TOTP implementations are here:
https://github.com/62726164/oathgen
https://github.com/62726164/goathgen
My OATH HOTP/TOTP implementations are here:
https://github.com/62726164/oathgen
https://github.com/62726164/goathgen
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.
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.
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.
> 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.
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.
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.
The factors are: something you know, something you own. Logging in from your phone doesn't break 2FA in any way, as long as you still enter a password.
Using a password manager on your phone turns it into just something you own.
Using a password manager on your phone turns it into just something you own.
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.
Does that make sense?
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?
The use case seems to be to bypass any value provided in using 2FA in the first place...
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.
- 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.
> 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?
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.
What if a trusted employee is reusing the same password everywhere including slack?
Why not just share the seed for the 2fa with close team members... you have to back it up anyway.
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.
"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.
Is it possible to reconstruct the seed (or some equivalent that would allow you to generate future codes)? If yes, how many codes would you need to do so?
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.
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.
Where does non-repudiation fit in if multiple people get the same 2FA code?
You're trusting teamFA, Slack, and each team member's Slack accounts. This seems like a security nightmare.
You're trusting teamFA, Slack, and each team member's Slack accounts. This seems like a security nightmare.
I'm not sure if this idea already exist or not but this is a good idea especially for a startup that needs to shared account to save money
Why?
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.
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
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.