Chromia SSO: The whys and the whats
April 08, 2020
You may have encountered this recent Coindesk article, about ZenGo and the work they are doing to address a security flaw in the Ethereum platform that they call baDAPPprove. The short version is this: the user of an Ethereum dapp can (and usually does) give dapps almost arbitrary privileges merely by using them with commonly available Ethereum wallet software. In practise this means that a malicious dapp could completely drain your account. ZenGo describes the issue as follows:
At Toyota they ask "why?" five times to discover root causes. Let’s try it.
Why is the user giving complete access to his savings to a malicious decentralized application? Because the wallet does not clearly show a warning about this.
Why does the wallet not show a clear warning about this behaviour? Because it is a convention to approve large sums indefinitely to dapps.
Why is is it a convention to approve large sums indefinitely to dapps? Because it is “fundamental to allowing smart contracts to interoperate with tokens” (MetaMask response in Coindesk article).
Why is it fundamental for smart contracts to interoperate with tokens? Because in Ethereum all transactions have a cost that must be paid in order for the transaction to go through.
And the final "Why?"
Why are dapp users being exposed to this kind of risk at all?
This is the most difficult to answer. Especially when Chromia has an architecture that avoids the issue entirely, enabling features that make DeFI secure AND easy to use, rather than requiring a choice.
Introducing Chromia SSO
Chromia SSO is perhaps the most important UX improvement that Chromia offers the decentralized world. It revolutionizes the way users interact with dapps.
Any dapp requires users to sign transactions, that means they need a private key. Control of the private key is control of any and all dapps or assets associated with it. This means that private keys have an especially stringent set of security requirements in a blockchain context – they control real value, and there is no recourse if they are compromised or lost.
Loss of access is usually addressed by requiring users to write down a mnemonic phrase which can be used to reconstruct the key. Keep it offline and keep it secure. This is quite an onerous requirement. It is clear that there is value in allowing users to interact with a plurality of dapps using the same keypair, as in the Ethereum model. The alternative, creating a new wallet and adding some small amount of tokens, as well as recording that passphrase, for every single dapp, is clearly a massive pain.
So, we end up using one unique wallet for all dapps within a certain blockchain ecosystem, usually in the form of a browser extension. As we read above, this model has deeply rooted security issues for which opt-in messages and transparency are a sticking plaster rather than a real solution.
So, is there a real solution?
First of all Rell, Chromia’s language for blockchain smart contracts, provides much more flexibility than mainstream blockchains, since the complexity and delegation of complex smart rules can take place without requiring the user to trigger the transaction. This is also helped by the fact that Chromia has no inherent requirement for transaction fees. Second, we are introducing few nice features that helps in this direction:
Authenticator descriptor
Authenticator descriptors allow you to attach multiple keypairs to one account. Believe it or not, you don’t have to remember it. In fact you should not save it and just forget it. The authenticator descriptor is explicitly permitted to send transactions only in the module (smart contract) specified at the moment of delegation. And you can also prevent it from sending money.
Furthermore, thanks to Chromia architecture (one chain per dapp), in case the keypair of the authenticator descriptor is compromised, it can only steal the tokens that have been assigned to that dapp.
Authenticator descriptor rules
Now, let’s say that you create a disposable authorization descriptor, how can you prevent it from draining your assets in case it gets compromised? Well, you can attach rules to it at the moment of creation.
So the authenticator descriptor is only valid for a session, it can perform a limited number of operations, be limited in time or blocktime. Or all the conditions together.
SSO
Lastly the real juice. How can I have different keypair in each dapp by only remembering one passphrase?
As we saw it is possible to delegate authenticator descriptors across dapps. This means that if we elect a master account (we do that in Vault chain), and we make sure that the passphrase / keypair we have in there is well protected. We can automatically login to any dapp with a seamless user experience.
It is in many ways easier than any other existing unified login system, centralized or not. Once the user has an account in the vault, it only requires 2 clicks to be registered and logged in on any chromia dapp. Just like signing in with Google, or Facebook, only this way the user stays in control.
https://chromia.com
https://minesofdalarnia.com
https://twitter.com/teamchromia https://www.reddit.com/r/Teamchromia https://www.youtube.com/channel/UCM_FvcRzwoZUmc60fYFj.. https://www.instagram.com/teamchromia https://t.me/hellochromia https://www.linkedin.com/company/chromia
https://www.facebook.com/teamchromia
https://t.me/hellochromia
https://t.me/ChromiaRu