AuthZ module: Education on the risks is needed!
As we see more and more Cosmos based chains rolling out the “AuthZ” module we think it is important to have a larger debate on the potential security breach it can cause to unaware users. It is even more important to be proactive right here in the Hub because we also have the Liquid Staking Module module (LSM) which can further fuel the fire if combined with malicious AuthZ usage. As we wait to get an appropriate response from wallet providers introducing visible warnings on potential risky transactions approval, we need to have our community informed of both the wonders and the dangers that come along with this module. Source: x/authz | Explore the SDK `x/authz` is an implementation of a Cosmos SDK module, per ADR 30 , that allows granting arbitrary privileges from one account (the granter) to another account (the grantee). Authorizations must be granted for a particular Msg service method one by one using an implementation of the `Authorization` interface. To give a bit of context for regular Cosmos users, this module makes it possible to use services like REStake | Auto-compound your staking rewards . Its utility covers a much wider range of potential use cases,…
Excerpt (1194 of 5438 characters). Read the whole post on the forum ↗
This is vital. I wish there was something similar to Walletguard for Cosmos. It tells you in plain text exactly the rights you are granting, what signing does, etc.
Also has functionality to scan existing grants from your address so you can remove risky site permissions.
tknox35:Also has functionality to scan existing grants from your address so you can remove risky site permissions.
We’re working on this as well as many other projects I guess. This is another crucial feature we badly need into the mainstream wallet providers.
I’m agree, a warning is required
I won’t be so radical on GenericAuthorization, I imagine it can be useful otherwise we should simply delete it !?
But indeed Authz must be used with caution.
Thank you for providing more context to the matter. Unfortunately the screenshot I provided in this topic is dated from the moment of that post. Which means that improvements are still required on the alerting as it hasn’t been applied to the case presented above. Of course those custom transactions can take multiple forms which likely explains the difficulty to cover them all at the moment.
Anyway, it is evident that things are moving in the right direction and we couldn’t be happier to see this.
If we can suggest additional security features, we would recommend locking the “Approve” button for at least 10s before accepting the user’s action. This would ensure no one is clicking on it following a repetitive routine and inadvertently clicking before considering the additional warning displayed.
IMHO, the most valuable work in this direction should be done by explorers and wallets. Todays UI isnt ready to educate newly onboarded users, alas. Agreed, education here is vital