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

by hansy • 5 years ago

49 41 5 years ago

joshdev• 5 years ago

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.

tossaway9000• 5 years ago

The use case seems to be to bypass any value provided in using 2FA in the first place...

geofft• 5 years ago

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.

hansy5• 5 years ago

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).

rmetzler• 5 years ago

What if a trusted employee is reusing the same password everywhere including slack?

hansy5• 5 years ago

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?

jeroenhd• 5 years ago

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.

hansy5• 5 years ago

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!

antondd• 5 years ago

Why?

jon-wood• 5 years ago

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.

chews• 5 years ago

Why not just share the seed for the 2fa with close team members... you have to back it up anyway.

jamesvnz• 5 years ago

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.

fragmede• 5 years ago

"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.

cmeacham98• 5 years ago

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?

tialaramex2• 5 years ago

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.

hansy5• 5 years ago

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.

_wldu• 5 years ago

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

fishtoaster2• 5 years ago

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.

auslegung• 5 years ago

Do you know 1password handles storing mfa codes?

hnzix2• 5 years ago

I thought 1password only allows storing MFA codes for pre-determined sites? Eg it doesn't provide a MFA option for microsoftonline.com.

fishtoaster2• 5 years ago

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. :)

weird-eye-issue• 5 years ago

Bitwarden does this too

ShakataGaNai• 5 years ago

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.

tgsovlerkhgsel• 5 years ago

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.

zxcvbn4038• 5 years ago

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.

remram2• 5 years ago

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.

tedk-42• 5 years ago

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.

bawolff• 5 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.

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.

remram2• 5 years ago

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.

whoknew1122• 5 years ago

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.

nikolay• 5 years ago

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.

LethargicStud• 5 years ago

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).

weirdo282• 5 years ago

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

jeffalyanak• 5 years ago

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.

kevinlst• 5 years ago

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

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

Related Stories