As part of my previous article, I described 3 proposals that greatly improve the state of web3 UX. This time I’ll continue with yet another proposal that would allow web3 users to be authenticated on demand without requiring their input providing yet again an improved user experience without sacrificing security. It is in some way a variation of the non-interactive signatures described in the previous article, but this time without the need for origin checks.

Introduction

It is a common pattern for web3 applications to require their users to authenticate themselves to their back-end (if they have any) via their web3 wallet’s signature capability. This removes the need for a traditional sign-up process that would involve either passwords or some third-party sign-in mechanism and the risks they impose.

For example cryptokitties uses such authentication signature mechanism to allows users to be the only one able to modify their kitty name (saved on their back-end, not in the blockchain) and prevent them from modifying the name of others’ kitties and that without ever requiring the users to sign up.

How it works

When a users visit the cryptokitties website for the first time (or from a new device) they are asked to sign a message with their web3 wallet. Since only the private key is able to sign messages, this allow the back-end to ensure that the address exposed by the web3 wallet API, is indeed controlled by the user. This establish authentication. From that point, the user’s authenticated status can then be saved in a cookie to not require further authentication signatures requests.

While that sounds already better than traditional password authentication, we can do better.

(It is worth noting that cryptokitties always use the same friendly message and as such is vulnerable to replay attacks (by someone who could get access to the signed message or by malicious application successfully requesting users to sign the exact same message). A proper implementation should inject unforgeable data in the message so no other parties could replay or create a valid message without having access to the private key.)

Removing user’s confirmation step

We could indeed go a bit further and provide an effortless authentication user experience without even needing user confirmation. Indeed, requiring the user to confirm an authentication pop-up like the one used by cryptokitties is actually unnecessary if wallets can be aware of the nature of the signature request (which should not be used in other contexts) and the verifier (the back-end) injects some unforgeable data in the message to be signed (not unlike a CSRF token).

After all, it is generally assumed that a web3 wallet exposing a specific address has the corresponding private key. The signature required for authentication is only necessary because a dishonest user could simply expose an address as part of the web3 API for which it does not possess the private key.

Requiring the users to confirm such signature would not increase the security of the mechanism though, as the users have no data to verify by themselves since such data is generated by the verifier itself. This is what allow such signature to be done automatically by the web3 wallet.

This is unlike the scheme used by cryptokitties which use a static message. Indeed, if such message is reused and no confirmation popup is presented to the user. Any application could generate the valid signature and then use that to maliciously authenticate as the user. This means though that the security of that scheme relies on user’s effort. This is in my opinion a bad user experience but also a security risk that could lead them to authorization fatigue. I’ ll invite you again to read my previous article which go in more details about this threat.

Currently though, every web3 wallets out there consider all signature requests equivalent and require users confirmation for all of them as a measure of security. This would need to change.

Solution

We simply need to come up with an authentication signature standard (EIP) that would allow web3 wallets to recognize such specific signature requests and perform them without requiring user confirmation.

This could take the form of a special signature format that wallet would recognise and would not be used in other contexts. I ll not describe a specific scheme here but this could take the form of a specific envelope type for EIP712.

To avoid signature replay, the application requesting authentication would have to provide different inputs to it every time like it should do with existing authentication signatures. And as mentioned above, to prevent a, malicious application to generate such authenticated signatures, the message needs to include data that only the correct application knows (like a CSRF token).

With standard such as ERC-1271 and ERC-1654 this could apply to smart contract wallet too.

For those who read my previous article on the non-interactive signatures, it is worth mentioning that we could use these for such scheme too. In which case the need for unforgeable data would vanish or inversely if unforgeable data is included, the origin would not need to be inspected by the verifier. They form thus a superset of the proposal outlined in the current article.

Conclusion

Authenticating web3 users via their wallet is a great UX improvement over traditional web as this does not require the annoying sign-up step nor does it require to use third-party signing to avoid it. On its own, such capability is a sure sign of the success of web3 over web2.

Unfortunately, as it stands it requires the constant use of unnecessary (and misleading) confirmation popup or/and the use of cookies to keep a user authenticated.

This is not an inherent issue with web3 though. It is simply due to the lack of an authentication signature standard that would allow wallets to perform such signatures without user confirmation and without reducing security.

By implementing an automatic authentication signature standard that allow applications to request signature without confirmations, applications could be sure at any time whether the user behind the exposed address is in control of it. Such mechanism would actually allow application to request such signatures on demand and bypass the need for cookies.

We could even imagine such standard to accept arbitrary payload and be used beyond simple login authentication. It could for example be used to sign every request made to the back-end.

Thanks for reading.

Don’t hesitate to follow me on medium or on twitter.

This post can also be found on medium here where you can follow me.