[HN Gopher] Show HN: Generate shared 2FA codes for your entire team
___________________________________________________________________
Show HN: Generate shared 2FA codes for your entire team
Author : hansy
Score : 18 points
Date : 2021-09-26 20:17 UTC (2 hours ago)
(HTM) web link (tfa.one)
(TXT) w3m dump (tfa.one)
| tialaramex wrote:
| 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.
| hansy wrote:
| 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.
| joshdev wrote:
| 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.
| hansy wrote:
| 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?
| tossaway9000 wrote:
| The use case seems to be to bypass any value provided in using
| 2FA in the first place...
| geofft wrote:
| 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.
| tialaramex wrote:
| > 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?
| hansy wrote:
| 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 wrote:
| What if a trusted employee is reusing the same password
| everywhere including slack?
| antondd wrote:
| Why?
| jon-wood wrote:
| 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.
| 1cvmask wrote:
| Interesting approach with Slack. This works differently and
| without Slack:
|
| https://blog.saaspass.com/sharing-authenticator-codes-with-t...
| chews wrote:
| Why not just share the seed for the 2fa with close team
| members... you have to back it up anyway.
| jamesvnz wrote:
| 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 wrote:
| "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.
| jeroenhd wrote:
| 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.
| hansy wrote:
| 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!
___________________________________________________________________
(page generated 2021-09-26 23:00 UTC)