Love what this project is doing! Hope my thoughts are helpful here.
It appears there may be a vector for social engineering/phishing attacks, that can be potentially avoided.
If Alice wants to delegate a minting address for, say, "The Memes" collection, she can do so by calling registerDelegationAddress from her cold wallet ("from" address) and specifying a delegation account ("to" address). Great, works as intended.
However, if Bob is targeted with well-crafted phishing site designed to look like the actual "The Memes" delegation front-end, he could be tricked into signing an approval for his vault to delegate an attacker's address as his delegated "to" address. The attacker would then get to mint in his place, unless revoked in time.
A possible resolution that comes to mind:
Require delegations to be confirmed by the To address, which could include the transfer of some amount of Eth sent to the From address along with the approval of being a delegate address. Scammers are much less likely to engage if there is a cost to attack. Further, could the amount sent could be randomized (eg: .000891345) like an MFA code, and visible only to the From address in an additional signing? Perhaps the secret amount number could be encrypted with the public key of the From address. Although obtaining this random value could also be socially engineered, the effort required to maliciously complete the extra step would reduce attacks.
Love what this project is doing! Hope my thoughts are helpful here.
It appears there may be a vector for social engineering/phishing attacks, that can be potentially avoided.
If Alice wants to delegate a minting address for, say, "The Memes" collection, she can do so by calling
registerDelegationAddress
from her cold wallet ("from" address) and specifying a delegation account ("to" address). Great, works as intended.However, if Bob is targeted with well-crafted phishing site designed to look like the actual "The Memes" delegation front-end, he could be tricked into signing an approval for his vault to delegate an attacker's address as his delegated "to" address. The attacker would then get to mint in his place, unless revoked in time.
A possible resolution that comes to mind:
Require delegations to be confirmed by the To address, which could include the transfer of some amount of Eth sent to the From address along with the approval of being a delegate address. Scammers are much less likely to engage if there is a cost to attack. Further, could the amount sent could be randomized (eg: .000891345) like an MFA code, and visible only to the From address in an additional signing? Perhaps the secret amount number could be encrypted with the public key of the From address. Although obtaining this random value could also be socially engineered, the effort required to maliciously complete the extra step would reduce attacks.