TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

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

49 点作者 hansy超过 3 年前

14 条评论

ShakataGaNai超过 3 年前
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.<p>This is much nicer looking. But... and it&#x27;s a very big but... why would you trust this service? You&#x27;re giving random person on the internet your 2FA secret keys. Their TOS &amp; PP don&#x27;t even mention encryption. I&#x27;m not saying you can&#x27;t do something like this, but I&#x27;d be extremely hesitant using something for a very high security purpose that is probably done by one person as an MVP.<p>There are other options, 1Password and LastPass both support 2FA TOTP codes. If you trust those, they are &quot;better&quot; 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.
评论 #28666890 未加载
评论 #28666102 未加载
jeroenhd超过 3 年前
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&#x27;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.<p>If access requests are actually being logged, the audit dashboard deserves a place on the home page in my opinion.
评论 #28665099 未加载
LethargicStud超过 3 年前
This <i>works around</i> a real problem I&#x27;m surprised nobody has solved - the ability to register a bunch of keys at the same time.<p>The webauthn spec has public&#x2F;private keys incorporated: <a href="https:&#x2F;&#x2F;www.w3.org&#x2F;TR&#x2F;webauthn-2&#x2F;#sctn-sample-registration" rel="nofollow">https:&#x2F;&#x2F;www.w3.org&#x2F;TR&#x2F;webauthn-2&#x2F;#sctn-sample-registration</a><p>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&#x27;d really just be tapping your yubikey or scanning your fingerprint on login.<p>Ideally, password managers would offer key servers that websites could hit in real-time to pull your public keys. That&#x27;s probably a stretch - maybe websites could sync your 2fa pub keys in the background.<p>With such a model:<p>1. Having multiple yubikeys<p>2. Having multiple team members with access (same as 1, effectively)<p>3. Revocation of individual 2fa devices<p>4. Adding 2fa devices after account creation<p>Would be pretty trivial.<p>I assume there&#x27;s something basic in the webauthn protocol that I&#x27;m overlooking that prevents such a model. What is it, and why can&#x27;t we have these properties?<p>I for one don&#x27;t want all my accounts to hinge on access to a single physical device, and I certainly don&#x27;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超过 3 年前
This is absolutely perfect for a use case that I&#x27;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&#x27;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.<p>I&#x27;d be pretty hesitant to use something like this for accounts I consider sensitive, though, because<p>A. It&#x27;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<p>B. It&#x27;s putting more trust into a third party (tfa.one) than I&#x27;d be comfortable with, given how new it is.<p>But again, <i>perfect</i> for our test accounts, and cheap enough that I don&#x27;t even need to think about it.
评论 #28666293 未加载
评论 #28666320 未加载
tialaramex超过 3 年前
It doesn&#x27;t say, but I presume these are TOTP codes, and there is just a single generator that you&#x27;re sharing and thus one shared secret.<p>This has some surprising consequences, e.g. a conformant TOTP implementation marks off your recently used codes, making them actually <i>one time</i>, 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&#x27;t twelve codes, so, some of them can&#x27;t use the shared 2FA codes.<p>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.<p>If you find that enrollment is a constant pain due to high turnover, I&#x27;d argue the high turnover is the real problem, what are you &quot;authenticating&quot; with such high turnover? If you&#x27;ve got most team members for a week or less (which is where that starts to feel very painful) I don&#x27;t see what can be authenticated, that&#x27;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&#x27;t much trust them (and why would you) then two factors seems excessive.<p>If your pain isn&#x27;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.
评论 #28665251 未加载
remram超过 3 年前
Like most of the services popping up around 2FA, now that 2FA is popular: this essentially removes one of the factors.<p>Whether you&#x27;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.
评论 #28666002 未加载
joshdev超过 3 年前
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.
评论 #28665089 未加载
评论 #28664717 未加载
评论 #28665070 未加载
chews超过 3 年前
Why not just share the seed for the 2fa with close team members... you have to back it up anyway.
评论 #28665159 未加载
jeffalyanak超过 3 年前
Bitwarden, and the fantastic rust-built equivalent Vaultwarden can be self-hosted, include granular, multi-user sharing of credentials which may contain TOTP secrets.<p>The web GUI, various plug-ins, and apps can all then generate the TOTP codes.
nikolay超过 3 年前
Can&#x27;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.
whoknew1122超过 3 年前
Where does non-repudiation fit in if multiple people get the same 2FA code?<p>You&#x27;re trusting teamFA, Slack, and each team member&#x27;s Slack accounts. This seems like a security nightmare.
kevinlst超过 3 年前
I&#x27;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
antondd超过 3 年前
Why?
评论 #28665170 未加载
weirdo28超过 3 年前
Would recommend hashi vault in place of this which can work for human&#x2F;non-human workflows and a pretty robust security model with better auditing and authorization than slack. <a href="https:&#x2F;&#x2F;www.vaultproject.io&#x2F;docs&#x2F;secrets&#x2F;totp" rel="nofollow">https:&#x2F;&#x2F;www.vaultproject.io&#x2F;docs&#x2F;secrets&#x2F;totp</a>