The permission system of EOSIO based blockchains (e.g. WAX & EOS) are a bit different than your normal PrivateKey-PublicKey pair that you have on most blockchains. This is a great thing from a security perspective. It allow you to use one account, but give different permissions to different contracts, set up true decentralized account recovery and easily manage multi-sig on any account at any level. That essentially means you can eliminate almost all risks while interacting with the Blockchain and/or giving access to your team account to multiple team members without risking your assets. Of course, this depends on how you set it up, how you manage keys, and what your employees or yourself need access to. At first glance, all this power can be confused for someone that learnt how key based accounts work on other systems, compared to the account based system on EOSIO. 

Understanding a key-pair

A key-pair is not a new technology, it's a simple yet great idea. You have a PublicKey, which you can share with anyone. This PublicKey is generated together with a specific PrivateKey, and will only have 1 unique match. If you change 1 character in your PrivateKey, it will no longer match the PublicKey. 

This means that for the PrivateKey to match the PublicKey, it can not change, they are immutable and can not be manipulated. 

Every Bitcoin address balance is tied to the PublicKey, and only the PrivateKey that matches that Bitcoin PublicKey can access these funds. If you lose your PrivateKey, you will lose your funds, and if anyone else get access to your PrivateKey, they will have access to your funds. 

A common missconception is that your funds are stored in a cryptocurrency wallet. This is untrue. What is stored in the wallet is the private key that is used to prove that you have access to the funds tied to the public key on the blockchain. This means that your assets are always on the blockchain, and never in any wallet. The wallet is essentially just a way to interact with the blockchain and sign transactions with your private key. 

key-pairs is also used in pretty much all IT security, so it is not a new concept. 

What is different with EOSIO based system?

First, EOSIO based systems are for example WAX, EOS, Proton, Ultra, Fio, Telos and a few others. Unless they have changed something, they will work the same. EOSIO is the blockchain system in the back, and the chains that use this technology are not related in any other way, but are usually called sister chains since they are related by code. This is different than sidechains, which purpose is to complement the main chain. 

On EOSIO, you have an account name that is of a "readable" format. An account is limited by max 12 characters, a-z and 1-5. As long as you comply with those rules, you can create any account that is 12 characters long, and you are also able to get premium names that are shorter than 12 characters. You can think of these account names as domain names used for websites. 

Bitcoin public key: 34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo

WAX account: anyo

As you can see above, the readable name is way easier to remember and to give someone that can accurately type into a transaction. 

Another benefit of EOSIO based accounts is that you can add and change keypairs for an account name. As well as add custom permission keypairs that are only allowed to interact with a chosen smart contract. So even if that keypair is compromised, it can only perform the exact actions you allow it to perform. It means you can safely and securely add games into a custom key that you can use in your mobile phone, without any risk of compromising any liquid funds in your account. This is truely amazing when you start to understand the implication of those permissions. 

That means that the potential expensive NFTs that are part of the game, are safe, even if someone get access to that custom private key. Below you can see an example of the permission named "claim", which are only allowed to interact with the "bcbrawlers" smart contract and only perform the actions "brawl" and "heal". If that key tries to do anything else, it will be rejected. 

There are no limits to which contract you lock these permissions for, that means if you have a business based account, you can easily give employees access to certain tasks, but still remain in control of what you want. 

Owner and active key

Since the account is immutable, and can't change, there is a smart system to securely manage these accounts. Each account come with 2 different level permissions from the start, the Owner key, and the Active key. They are similar, but very different in a security level. There has been multiple projects who missmanage these keys and thereby allow customers funds to get rekt. There are also many users who has done the same mistake, which is rather sad. 

The main difference on the Active and Owner key, is how you should treat them. The Active key has to be secured as good as you want to protect your assets. If that permission level gets compromised, you may be in for a really hard learning experience. 

The Owner key has to be treated as securely as your most hidden and darkest secret. This is your savior if something bad happens, it can be used to restore your ownership of the account in case something bad happens. It will prevent anyone from ever getting full access of your account, NFT collection or project. 

For example, if you have staked WAXP, it takes 72h to unstake those. So if a hacker get access to your active key, and starts to unstake your WAXP.. you have 72 hours to get your owner key into a secure machine, update the active key, and thereby get back full control of your account. With proper notification this can be done within a very short timeframe which might save a lot of your value if you get compromised, as it provides you with the ability to lock out the hacker!

So if you, or anyone you know, run a project and don't have proper management of their owner key... it might end really bad. If they instead manage the owner key properly, they can minimize any damage done by a hacker or malicious employee. 

Adding multisig for increased security

We have already learnt that the EOSIO permission system is super powerful, it gives us more power to securely manage our account, project, collection and thereby funds. But it's not limited to a single key, you may actually add multiple keys, and easily add and manage multisig transactions.

Multisig means that multiple keys (or accounts) have to sign a transaction for it to go through. This is another important layer to secure accounts with a lot of value. 

Through the help of multisig, and the flexibility of custom permissions, you can even use this for decentralized and secure account recovery! So even if you lose your key, you don't lose your assets!

Now, at first glance, the above screenshot of an account security might be confusing or even scary to look at. But don't worry, I got a video (below) breaking it all down for you.

The TLDR is that you can add a threshold to a permission, and then add one or multiple keys under that permission which get different powerlevels. You can make them all equal, or treat certain keys or accounts differently. 

Custom permissions - The Gamechanger

Custom permissions is something not fully understood by even smart contract developers. Even experienced teams sometimes hardcode the use of active key for their users, which reduces their capabilities to add security for their assets. With those contracts set aside, you got a superb system that we mentioned before. You can set a custom permission that is only allowed to interact with specified smart contracts, games, marketplaces, and nothing else. These custom permissions is a great way for you to securely interact with the blockchain, and reduce any risk of testing out new applications and clicking phishing links. Oh ye, it can be used to remove the risk of phishing, since the key you have in your wallet is only able to do X, and thereby is unable to perform the transaction the phishing site is trying to do. This however require you to not add the active or owner key into the wallet and accidently signing with that key. As well as not add any of the dangerous actions into your custom permission, which in short are transfers of assets. 

The contracts and actions to be careful with

Your custom permission is as safe as you make it. If you add the ability to transfer tokens, it can do that, but not other things. You might limit it to certain tokens, and there can be usecases for this as well. So what is mentioned here is for you to understand the risk, not necessarily a blacklist of contracts and actions. 

To showcase what can be done, and how it look, you can see the example below. On this example you have two custom permissions, one called "vote" and one called "wps". You may name your permissions anything, but I personally like to keep them similar to the task they are created to perform. 

The vote permission has 1 key added, and 3 actions it can be utilized for. All these actions are on the "eosio" smart contract, which is the main contract on EOSIO chains. The actions I've given it permission to perform are "claimgbmvote", "claimgenesis" and "voteproducer". These 3 actions allow me to vote for guilds, and claim rewards. If I try to do anything else, it will fail. There is also a second custom permission to vote for proposals. 

The above custom permission is great for safely and securely automating the task of voting (to refresh the vote weight), and to claim your rewards (on WAX).  I can with confidence add this key on any of my devices and automate this action without compromising any risk to any assets. 

Another perfect usecase is games

When it come to games on the blockchain, there is an inherit risk. This is partly because there is a lot of incentive for bad actors to build semi-attractive applications to attract a lot of value and take advantage of that in different ways. There is also a lot of incentive for bad actors to make fake websites and try to get you into those, and trick you into signing something you do not intend to do... so called phishing attacks. 

One really good way to mitigate this is to use a separate wallet and custom permission for your games, one that, even if you happen to be tricked into opening a transaction that contains something malicious, nothing gets stolen from you. This is simply because even if you sign that transaction, it will not work since you haven't added that permission. 

I try to set stuff up to be better safe than sorry, I expect myself to make a mistake at some point, and at that date, I hope that I have set everything up to minimize the damage that is done. No one is safe on the internet, specially in the crypto sphere... so plan for failiure and set it ut properly. 

Below is an example from one of my accounts where you can see a lot of contracts and actions under the same custom permission. We see games such as blockchain brawlers, rplanet, farmersworld, farminggames, nftpanda, xpansion and others. 

I could, if I wanted, even give the private key of this action to anyone... simply because all you are able to do is the things specified... oh no, the person can claim tokens for me... Or can go and actually play the game for me.. 

Now, I would not do that, but if I did, I would not create any issues for myself, as long as I remember that I did give that key away and don't add a "transfer" for NFTs into it.. because at that point, every NFT in that account could be stolen. In fact, you can even see above that I have given it permission to do 1 transfer. e.rplanet::transfer, this action allows me to transfer aether, which is the rplanet token. I had to add this permission because the game required such action each time I tried to invent or craft a new material in the game. 

For that reason, I would not use that account to stash any aether tokens that I would want to keep in the long-term, if I wanted to do that. 

What I mean by that is, as I see it as a slight increase in risk, I intentionally don't keep to many of those tokens in that account, but I store them in a more secure wallet. Even if the risk is low, it exists.

Learn to set custom permissions

Setting up custom permissions on your account can seem complicated, specially the first few times you do it. For that reason I always recommend using one of the testnets for the first few times you try to do anything with keys, permissions and updates. Once again to mitigate risk. 

I have created a course, of course it's free as the other content, and it's located on the WAX sw/eden website. 
https://waxsweden.org/course/adding-custom-permission-using-bloks/

This will be a step by step guide to help you get started and to secure your account.