Credential management

[ZeptimusQ]

Using JAM link as TEC credentials manager

Until now we were using Keybase for sharing credentials and keeping a registry of the members with access to each platform. With platforms like JAM we don’t need to share credentials anymore we can just share access. And credentials could be changed every month without affecting the workflow.

We could use JAM until more decentralized technologies such as https://www.nucypher.com/ are available.

Doing a change like this brings up a lot of questions. For example decisions like this centralizes our process and that’s why I think it’s worth opening this thread, to get pros and cons of this action and get a decision as a whole.

PROS:

• Increasing the security in case of future conflicts “The problem of decentralizing states is defence, and the problem of decentralizing daos is password management :-D”

• Access can be revoked when members are not contributing on a task anymore

• Every reset (we could define a period of time) restricts access to inactive contributors and/or to people with previous access who have broken the code of conduct.

CONS:

• Centralize power and the consequences of that.

• Add bureaucratic steps

• Sharing access isn’t much different from sharing credentials, people with it can do the same except sharing access with third parties.

We should also discuss how we wanna approach it also on our platforms such as GitHub or Discord. In my opinion we are doing a great job. We have different projects with different members with powers, for example we have Gitbook admin powers on 1 account. Then we have Github where there are many contributors but at the same time the contracts are on another repo where there are not many contributors.

But we can also see it the other way, for example on discord there are a lot of admins, is it necessary? Would it be ok with the moderator and 1 backup? What are the pros and cons?

Another goal with this post is to brainstorm the process to share credentials? Is it needed or would it be bureaucratic?

For example we could add a Typeform with questions like asking for handle, which platform do the contributor need access to and what it’s the job going to be done on that platform (to decide what kind of access we should give) And the results of the typeform could be share on the stewards chat with a poll and if no one is against on 24hrs we give the access corresponding to that Typeform. This process would have a delay of 48h more or less.

The idea it’s come up with the best process possible regarding security and efficiency. This one above might be super bureaucratic.

[liviade]

Thanks for bringing this up Zep! super important discussion
What if we use JAM and have a limited number of people that can be there like we did with SourceCred. We could have a bi-weekly or monthly check-in to see that everyone is still active and keep track of the access links sent.
Until the more decentralized solution is available.

[natesuits]

This content was authored by our Subject Matter Expert, @Durgadas:

TEC Security Management Practices

So, there is always a tension between security and access.

Here are the problems I see:

1. Trust would seem to be VERY important in our situation to have really clear security best practices, not consumer-level or untested new products.

2. We are not really using enterprise-level best practices and products up to now, to my knowledge, but there are significant gaps in my knowledge of the existing map of the tension between security and access; and failing to map this tension we cannot share it or vote on it. Top 15 Password Management Best Practices | BeyondTrust

3. Our stated goal (https://www.nucypher.com/) from Zeptimus’ post is an untested alpha/beta product. Sure, it is a Good Idea and very cutting edge, but not sure why we would implement that apart from testing any time soon.

4. Using a consumer-level product even as a stopgap seems like an odd choice that lessens security and trust.

5. Lessened Security Has Become Normalized…Because… “free”: But then again, we use many insecure products or “free” products made by companies with demonstrated tendencies to lack a concern for privacy (Discord, Google, etc.) which I also think is a mistake.

6. Discord’s desktop client is almost continuously hacked, and Google sees literally everything we do since we use their products to document EVERYTHING.

7. I’m not sure why this is not more of a concern among our users or those who would invest in our products, to be honest.

8. It seems to be that we take these things for granted, which is of course what Google and the like rely upon as the foundation of their business.

9. There is no map I can see of our current overlapping planned security circles or even risks posed by involving so many people with varying security practices participating in it. I’m happy to be corrected on this if such a map exists. How to Conduct an Internal Security Audit in 5 Steps

10. We need Auditing, and no program I see we’re using allows for this.

6. We are NOT in control of our participants computer security like you might get in an enterprise, so as a result we have existing and unclose-able threat vectors that an enterprise might not have. It is very possible to have any given user with a keylogger or other virus that can compromise our security or access, and so we need to find some way to state that people need to have some level of standard protection in this regard, since it would be tragic if one person’s machine being compromised somehow compromises security or access to key systems. This matters more after the Hatch when real money is being played with.

Here is what I would recommend:

1. Map all security and access, perhaps using Glassfrog.com circles to make sense of this (share among Super Admins and Admins, and vote for approval among the community).

2. ALL top-level Super Admin and Admin named accounts have 2FA as a requirement.

3. Recommend that we have 5 layers of access:

a) Super Admins (account-level payment, access, password & user management) Specific to validated Trusted Seed users using validated email accounts and phone numbers.

b) Admins/Stewards (user-modification access toward the Provisional Admins) Specific to validated users using validated email accounts and phone numbers.

c) Provisional Admins (management of individual password and designated account password management). Either assigned or service accounts created here.

i. Caveat: In positions with high turnover, you might want to create service accounts whose passwords and accounts are ‘assigned’ to a given individual but the shared nature of this means you won’t want to turn on 2FA.

d) General Editor Users who need to have passwords shared with them temporarily or using a lower-level type access to individual accounts for some function or to assist. Either assigned or service accounts created here.

i. Caveat: In positions with high turnover, you might want to create service accounts whose passwords and accounts are ‘assigned’ to a given individual but the shared nature of this means you won’t want to turn on 2FA.

e) Everyone else in the community with their own access and passwords with 2FA available:

i. Discord, Forum, website, etc.

[ZeptimusQ]

Thanks guys! This is being super valuable

I love the 2 practices suggested that we can do regarding which method we end up using

• Bi-weekly or monthly audit for the access
• Guide our members with good practices regarding security. I think we could add this best practices on top of the rules we are building for each platform that ideally we will add on the Gitbook.

Regarding GlassFrog, correct me if I’m wrong it would be a substitute for Discord and the forum. I think it wouldn’t be beneficial, the main reason being that Discord and forum are like the default apps on the DAO space (from what I know, could be wrong). The benefits of using them in my opinion are higher over GlassFrog which still a centralized platform

(A dapp that substitutes discord would be super cool :D)

In the case of the password management tool JAM it’s a provisional solution and nucypher is a project to keep an eye on in fact other projects might be raised to solve this issue. Of course we can use something different than JAM, Dashlane is another option.

But the main goal of the discussion is to know how to approach as a DAO this kind of centralization, or maybe we want the keybase method we are using right now which is more decentralized which also has its pros and cons. But especially when we have roles like super admin, admin etc. How many of each role should we have? Who should be a super admin and why? I would love 0mega engagement on this threat

[ZeptimusQ]

Another thing that worries me that Juan raised on our last transparency call , is when members want to contribute but they don’t have certain access to do their job. What if a new member that’s working on marketing stuff needs to work with sensitive information?

@ZeptimusQ

For example we could add a Typeform with questions like asking for handle, which platform do the contributor need access to and what it’s the job going to be done on that platform (to decide what kind of access we should give) And the results of the typeform could be share on the stewards chat with a poll and if no one is against on 24hrs we give the access corresponding to that Typeform. This process would have a delay of 48h more or less.

Would that solve something?

[ygg_anderson]

This is a great thread. I would support a CV proposal that funds this discussion and the implementation process that comes out of it. Proper access permissioning is a factor on organizational efficiency. In other words, positive ROI in the long term. And a great research area given the novel systems that we are operating.

[drllau]

1. Firstly, let’s look at what state of the art is … I reference the book “Security Engineering 3rd Ed”. The whole 1st edition is available gratis (just not recent cases).

2. What is Zep trying to do? … identify the “opponent” or failure mode you are trying to prevent. If it is laziness of credential holders, the simplest solution may be a dead-man switch which after a period of inactivity, grants the multi-sig to a reserve list … .aka auto-fallover, rather than adopting a whole new system. Are you going for operational tweaks or systemic changes in practices?

3. Decision process for systemic changes … orthogonal to above is how does TEC decide what to decide.

So with ref to the book (chp & verse) perhaps we can typograph the issues Zep raises (passwords, sigs, wallets, audit, etc) and try to come to some consensus which risks justifies the cost in change.

I come at this from both a Legal engineering back ground (risk management) plus CompSci (systems programming) as history shows that simple as possible reduces the attack surface and avoids security gaps due to lack of human comprehension.

@drllau

ObJoke … Privacy is a transient notion. It started when people stopped believing that God could see everything and stopped when governments realised there was a vacancy to be filled.– ROGER NEEDHAM