keybase / client

Keybase Go Library, Client, Service, OS X, iOS, Android, Electron
BSD 3-Clause "New" or "Revised" License
8.88k stars 1.23k forks source link

Team owner reset account, now can't admin team #12015

Open tradel opened 6 years ago

tradel commented 6 years ago

I created a keybase team and added a bunch of people to it. Everything was working great until I lost my Yubikey, and reset my Keybase account to protect myself. Now some commands report I'm not a member of the team, and other commands say I'm still the owner:

bash-3.2$ keybase team  list-members chadikins
▶ ERROR You are not a member of this team (code 2623)
bash-3.2$ keybase team add-member chadikins --user=tradel --role=owner
▶ ERROR You are not a member of this team (code 2623)

So I try to add myself back into the team:

$ keybase team request-access chadikins
▶ ERROR You are an implicit admin - no reason to request access. (code 2734)

Is there anything I can do besides deleting the team and creating a new one? Thanks!

5h4d0ww0lf commented 6 years ago

By deleting your keys you lost your access and there is no way of adding you back if there isn't another owner of the group. And the groupname can't be reused you will have to create a new one.

Avamander commented 5 years ago

Could there be a fix for this? Some kind of an auto-admin mechanism, turning team useless sounds like an anti-feature - protects noone if the person resetting their account can be reverified.

edmundlaugasson commented 5 years ago

Would propose to allow generate the paper key for the team when owner will create it. Similar behaviour with device management - you see it only once while creating a team and later can acquire ownership of the team via that team paper key.

junderw commented 5 years ago

If you lose your yubikey, just revoke the yubikey.

By resetting your account from scratch you actually increase your risk of impersonation.

Think about it.

Having a trail of signed keys and proofs of social media leading to a signed message saying "btw, the GPG key I used at the beginning is revoked" will allow anyone to verify you are no longer using the GPG key.

Once you reset all keys, no one can verify anything anymore. Your newly generated keys require new out of band confirmation.

During the confusion the person who stole your GPG key could create a new account with it and tell people "oops sorry, reset my account and got hacked, this is my new account"

For all they know, a new account with your old GPG key is more trustworthy than a new set of keys appearing out of nowhere on your old account.

Avamander commented 5 years ago

Your newly generated keys require new out of band confirmation.

Currently there's no way to say "I verified out of band that this is fine". It just makes the team useless - even if everyone in it would agree to reset it.

junderw commented 5 years ago

As for the "paper key for team recovery" feature.

The next step in the cat and mouse game would be someone saying they were "deleting my team's paper key because I thought it was no longer secure for some reason"

Then "well, then share the paper key"

In which case we arrive at "make someone else a co-owner" which solves the problem.

Keybase should warn if someone resetting all keys or deleting their account is the last owner/admin of a global team. With big red letters, and suggest making someone else an owner while you are resetting your keys.

Make them type in the name of each team to verify.

People will shoot themselves in the foot. The best way to prevent it is to remind them what they're doing.

Avamander commented 5 years ago

The next step in the cat and mouse game would be someone saying they were "deleting my team's paper key because I thought it was no longer secure for some reason"

You could apply that logic to user's paper keys as well. There's no super good reason to not provide the same alternative to teams as well.

Keybase should warn if someone resetting all keys or deleting their account is the last owner/admin of a global team. With big red letters, and suggest making someone else an owner while you are resetting your keys.

At that point it is too late.

In which case we arrive at "make someone else a co-owner" which solves the problem.

Not always applicable.

People will shoot themselves in the foot. The best way to prevent it is to remind them what they're doing.

Even when trying your best to prevent shooting yourself in the foot it would still be a good idea to have a few bandages nearby.

junderw commented 5 years ago

There's no super good reason to not provide the same alternative to teams as well.

Now team ownership's attack surface is increased significantly for little benefit.

Currently there's no way to say "I verified out of band that this is fine". It just makes the team useless - even if everyone in it would agree to reset it.

So we should allow a certain number of non-admin users to vote to add a new admin (remember, when an account is reset, the name stays, but crypto-wise it's a new person)?

I don't think that's a good idea.

Avamander commented 5 years ago

Now team ownership's attack surface is increased significantly for little benefit.

That should be up to the team's creator to decide and could you please explain how an user's paper key is somehow better than having a team's paper key?

So we should allow a certain number of non-admin users to vote to add a new admin (remember, when an account is reset, the name stays, but crypto-wise it's a new person)?

What's wrong with that? Can you describe an attack scenario where this could be abused?

junderw commented 5 years ago

Can you describe an attack scenario where this could be abused?

Admin A still has control over his keys. No recovery is needed. Regardless, non-admin users just decide to kick out Admin A and Implant Admin B. This could be abused in certain types of teams where it's a community surrounding a centralized service: ie. Coinbase makes a public team, 5000 bots join and boot the admins (Coinbase employees) and the new admins that make similar looking names spam links to "official downloads" of malware.

(Keep in mind, in order to fix OP's problem, whatever you are proposing must be enabled by default, otherwise anyone who doesn't "enable" whatever solution is still in the same boat)

please explain how an user's paper key is somehow better than having a team's paper key?

Admin A and Admin B run the team. Admin A and Admin B both have the paper key for the team. Admin A goes rogue and starts doing something bad using admin power. Kick Admin A. Admin A still has the paper key. Admin A uses the paper key to "recover" his admin status.

A paper key being tied to one identity is fine (paper key for accounts) because the only person managing that key is one person. When you get a paper key representing a team and spread that key around among multiple admins, there's no accountability and any demoted admin can immediately un-demote themselves.

...

Of course, your counter argument could just be "well, then implement it without those drawbacks" under the assumption there exists such a method. And tbh at that point we're just arguing for no reason about specifics of a spec that doesn't exist yet.

...

There already exists a recovery method for teams:

This goes along the same vein of "I deleted my account and now I can't get it back.":

And Keybase needs to be as clear as possible to users before they do those destructive changes. Anything else is in the "oops, should have read the warning text. Sorry." category.

Avamander commented 5 years ago

This could be abused in certain types of teams where it's a community surrounding a centralized service: ie. Coinbase makes a public team, 5000 bots join and boot the admins (Coinbase employees) and the new admins that make similar looking names spam links to "official downloads" of malware.

This wouldn't work if there's just one non-bot account in the team. The presumption is also that the single admin has reset his/her account.

there's no accountability and any demoted admin can immediately un-demote themselves.

Assuming the owner shares the paper key and shares it with people who would do this. Should we remove admins as well because someone could abuse that?

There already exists a recovery method for team

It's not complete

Learn how keybase works before doing huge destructive changes like deleting / resetting your account.

Accidents happen, there has to be a way to recover.