eips
eips copied to clipboard
ergoplatform
EIP-0028 ErgoAuth
ErgoAuth: user authentication protocol between wallet applications and dApps
Maybe we should step back and go to the root cause of the problem. We discuss at the moment a problem that a man in the middle getting knowledge of a signed message can use it to authenticate to another dapp. Why do we have this problem here, but not in signed transactions in the first place? Because for transactions, the user get revealed what he actually is going to sign, while for now this is not the case here for ErgoAuth. The message that is signed is hidden to the user and only the issueing dapp knows what it is used for. To overcome this, we can define that the message to sign must contain a plain text message to be shown to the user, that explains in simple language what he is going to sign for. This plain text message could be prefixed to the message to sign and separated by a 0 byte. Some examples for such a message:
"Login to getblok.io configuration @ 06 Jul 22 15:30" "Flip a coin @ NightOwl" "Draw a card @ Blitz TCG"
etc etc
By this, the user knows what he is going to sign and we can get rid of the unsolvable problem of insecure transmission channels. Additionally, dapps can persist the signed message and signature and have a proof that the user actually signed to do an outlined action.
As an alternative to implementing encryption as part of this EIP, we can restrict this EIP to work only over secure https connections, also requiring the UI to show connection security status to the user (same as it is done in browsers)
As an alternative to implementing encryption as part of this EIP, we can restrict this EIP to work only over secure https connections, also requiring the UI to show connection security status to the user (same as it is done in browsers)
This is now part of the specification:
To fetch the auth request:
An URL is provided without the https prefix. http communication is not allowed except for IP addresses (in order to test within a local network).
For the replyToUrl:
The replyToUrl's hostname must be the same as the one the request was fetched from - a wallet application should verify that.
So https is already enforced, I will check possibilities for showing the certificate information.
I have checked how FIDO works and it has the same concept to prevent middleman attacks. So I am confident we are good to go with this one. On a side note, ZelID only uses short living signing messages. This is recommended to do for the dApps anyway.