Q&A - How Do I Use Permissions To Protect My Account On EOS?

Alexandre walks through the permissions system within EOS. Permissions can be used to control different security features and operation allowances of an account.

Still have more questions? Join us on Telegram
https://t.me/EOSCanada

Today we're going to talk about something really awesome. One of my favourite features of EOS, I think it's a main distinctive feature from other blockchains. It's the permissions system.
We're going to talk about two things. I'm going to give you an example of how we can use permissions in a concrete setting, and then how the permissions are structured on chain.
One of the main differences of EOS with other blockchains is the account system. Between your funds and you, there's an account. A 12 character name. And when you want to spend those funds, you need to sign a transaction for the account, not an associated key directly. Behind the account you can have one or more keys and those are on chain, and you can change those. You can alter them and there's different permission levels. That's really awesome. It also means you can do permissions management on your account.
By default, you have two keys. You have the owner key and the active key. Any transaction can be signed with your active key that is associated with your account. Now I'm going to show you the structure of that, but just before that, I'm going to show you a usage. Us block producers, we need to claim rewards once per day. And you know, you don't want to miss it, because otherwise you're going to lose some EOS and whatever, so we wrote a program called "EOS-Claimer." And we didn't want to put the active key on a server to sign transactions once per day, you know to get the claim reward, because the active key allows you to sign transactions for everything. Transfers... you know anything on the chain normally by default.
So let me show you this here. So this here is the EOS-Claimer repository, and this is the source code. And this is where we propose the setup of the permissions. Cleos has two ways to set up permissions. The first one is to create a new permission. There's owner and active, but we are going to create a third one, called claimer. And we're going to delegate the access to that operation to that permission. Does that make sense? So we're going to create on our producer account here, a claimer permission. That's the name of the permission. And in there we're going to pass an authority structure. Let me show you an example of a fully-fledged authority structure. So this here is how an authority structure looks like. We have two here; the active and owner. And they're composed of three slots here. There's keys, accounts, and weights. And you have a threshold to wrap them up. So you can have one or more keys and each key can have a specific weight contributing to the threshold. If you accumulate sufficient weight, then you can be authorized to sign for that transaction. Let's say we want to sign something for the owner here, we would need to sign with this key and this key. Both of them - two signatures for the same transaction - unlock the owner authority. But look here we also have a "wait." It means if we sign with one key, and we submit a transaction, that will be delayed by 300 seconds, it will also go through. And in the second example here, we're literally delegating access to the active permission to that guy, so "otheraccount." And we say, instead of checking on my keys, check out his keys. And make sure you pass the permission "otheraccount" active to get a weight of one, and in this case we have a threshold of one so signing with the keys from that account is sufficient to sign transactions for our account.
To set this on the chain you can use cleos, or you can use our own EOSC. But let's take a look at cleos. When you call `set account permission` you're going to set on that account a new permission with those information - the threshold and the key and whatever other things. And then you sign that transaction with your active key. And then what you can do is attach that new permission to a given action. So an action on a contract. In this case, we're going to set the permission "claimer" to be required when you sign a transaction in the contract EOSIO, and the action's name is "claim rewards." It means that the next time you want to sign a claim rewards action, you need only to pass that single key in that case because it has a weight of 1, and a threshold of 1. And over here we're using mostly a throwaway key. We put that on the server. It's a low privileged key, it cannot sign anything else except the claim rewards action. And claim rewards is a very low risk operation. So you might also have noticed here the little "active." This makes it a hierarchy. It makes it nested. So it says this is the parent, and if you have owner, and then active which is a parent, and then you have claimer, which is a child here, you can sign operations with the active key for the child permissions. But not the reverse. You could not sign transactions that require your active key with the claimer permission, because it's a child. So you have a lot of flexibility directly on chain. I'm going to show you how this is represented within `get account.`
So if I get account for our own account, EOS Canada, you will see a few things. But most notably here, the permissions. Where we set that up. We have an owner permission which we set some keys in secure bags, and some keys owned by different people in vaults, and all that, because that's very sensitive. Owner allows you to override the active permission, so we have those things in a vault. We have an active key, and then we have a claimer key. I added that. And see how they're in the hierarchy. You have a 1 weight here, to contribute to a 1 threshold here. And over here, we have 1, and some that are 2 (more powerful) that can contribute to the threshold for owner.
So I've said much already, but let me give you one example. I think it's critical and crucial, it's a huge feature, it's a hidden gem. So it's related to that `wait` section here. This means you can force, on a given account, let's say you have one account where you have big funds, you can force a wait time. You put 1 key and 1 weight, a threshold of 2 and then you'll be forced to wait for, let's say, 24 hours. Send a transaction that's going to be on chain and cancelable by yourself. If you got your keys stolen, someone will have no choice but to send a transaction that needs to wait for 24 hours. You'll be able to see that, receive notification, call your buddies, and then you can send the cancel operation to shut it down. That's amazing! No other blockchain allows you to do those things. So it's an awesome feature! I hope you see the potential.