J'ai récemment participé au hackathon Ethereum, et aujourd'hui je veux parler du projet EtherAuth, avec lequel l'équipe MixBytes a pris la troisième place. EtherAuth est une tentative de création d'une version décentralisée d'une connexion à un site à l'aide d'un compte externe. En tant que bouton, connectez-vous via Facebook, uniquement sans Facebook.
Problème et solutions
Si vous souhaitez créer une zone fermée pour les utilisateurs sur votre site Web, vous devez choisir: développer votre propre système d'identification, d'authentification et d'autorisation des utilisateurs, ou utiliser une solution prête à l'emploi. Une solution clé en main signifie que votre utilisateur possède déjà un compte dans un système (Facebook, Google, Yahoo, Outlook ou même simplement un e-mail). Et vous utilisez le mécanisme approprié (le plus souvent le protocole OAuth 2.0) pour vous assurer que quelqu'un qui essaie de se connecter à votre site à l'aide d'un ID utilisateur externe est bien cet utilisateur.
Cette dernière option est plus facile à mettre en œuvre, mais il y a un risque pour l'utilisateur: si quelque chose arrive à son compte principal (par exemple, Facebook bloquera le compte sans donner de raisons), il perdra également l'accès à ses informations sur votre site.
De plus, si en tant qu'utilisateur je souhaite me connecter à un site auquel je n'ai pas encore confiance, je suis confronté à la nécessité de fournir à ce site un accès à mes informations personnelles, telles que le courrier électronique ou l'âge. Si le site ne prend en charge que la connexion avec un compte externe, je dois littéralement faire un choix: refuser d'utiliser le site ou sacrifier mon anonymat.
La plupart des utilisateurs finissent par sacrifier l'anonymat avec les mots «alors ce qui peut arriver de terrible, je n'ai rien à cacher». Malheureusement, la plupart des attaques ciblant un utilisateur non préparé et se terminant par une perte d'argent commencent par des mots similaires. "Que peut-il arriver de terrible si j'envoie un code SMS à un employé de banque?" "Quelle chose terrible peut arriver si j'envoie à un employé du support technique les en-têtes de demande?" La réponse à cette question est le plus souvent découverte quand rien ne peut être fait.
Comment Ethereum peut-il aider ici? Nous avons déjà réalisé qu'il y avait trois problèmes principaux:
- L'utilisateur n'est pas obligé de faire confiance au site qu'il visite et souhaite éviter les fuites d'informations personnelles.
- Le site souhaite utiliser un système d'authentification externe pour éviter de stocker les données des utilisateurs et les coûts de sécurité associés.
- Les systèmes externes existants qui offrent aux sites la possibilité d'authentifier les utilisateurs comportent un risque de censure. Tout compte peut être bloqué à tout moment sans explication et parfois sans possibilité de récupération.
Nous pouvons utiliser le réseau Ethereum au lieu d'un système externe et y stocker uniquement les données nécessaires. Nous devons veiller à ne pas stocker d'informations secrètes dans le domaine public, mais comme tout portefeuille sur le réseau Ethereum est en fait une paire de clés cryptographiquement solides, dans laquelle la clé publique détermine l'adresse du portefeuille, et la clé privée n'est jamais transmise sur le réseau et n'est connue que du propriétaire, nous nous pouvons utiliser un cryptage asymétrique pour authentifier les utilisateurs.
Dans le cas le plus simple, vous pouvez utiliser l'adresse du portefeuille Ethereum comme ID utilisateur. Mais ici se pose un problème: en cas de fuite de clé, l'utilisateur perd à jamais l'accès au système. Plus précisément, à partir du moment où la clé secrète de l'utilisateur est devenue connue de l'attaquant ou est simplement tombée accidentellement en accès public, nous ne pouvons pas utiliser une telle clé pour l'authentification.
Implémentation
Dans notre solution, j'ai écrit un simple contrat intelligent EtherAuth pour stocker les ID utilisateur et les adresses de portefeuille associées. L'ID utilisateur n'est qu'une chaîne UTF-8 d'une taille comprise entre 2 et 32 octets. Il est inventé une fois par l'utilisateur lui-même et utilisé plus tard pour se connecter à tout site prenant en charge EtherAuth. Aujourd'hui, j'ajouterais une restriction sur les caractères possibles inclus dans la chaîne, laissant la possibilité d'utiliser des caractères latins et des chiffres arabes (sous-ensembles de codage ASCII 7 bits) pour limiter la possibilité de créer des connexions externes similaires.
Lors de la création d'un compte dans EtherAuth, une paire de clés est définie: une clé d'autorisation (authAddr) et une clé pour restaurer l'accès (recoveryKey). Le nom recoveryKey n'est pas entièrement réussi, car cette adresse est utilisée pour gérer le compte, et pas seulement pour la récupération. Lors de la création, les deux adresses sont égales à l'adresse du portefeuille pour le compte de laquelle la transaction a été envoyée. Mais un utilisateur soucieux de sa sécurité doit créer une clé de contrôle distincte et la stocker dans un endroit inaccessible sur le réseau. Je le garderais même sur papier dans un coffre-fort sous forme de 12 mots mnémoniques, permettant, si nécessaire, de recréer quelques clés.
Il est également judicieux d'utiliser une adresse de portefeuille distincte pour l'authentification, en la séparant de l'adresse de portefeuille dans laquelle tout votre Ether est stocké. La relation entre authKey et l'adresse du portefeuille qui a créé le compte peut toujours être tracée en analysant la séquence de transactions du contrat intelligent. Désormais, vous ne pouvez pas définir une clé d'authentification et une clé de récupération distinctes lors de la création d'un compte. Cependant, si vous affinez le contrat intelligent dans cette direction, l'adresse qui a créé le compte ne sera pas nécessairement associée au propriétaire du compte, ce qui permettra à chacun de protéger son anonymat.
Pour l'interaction des utilisateurs avec le contrat intelligent, nous avons créé une page Web distincte. Vous pouvez y créer un compte, modifier ses clés ou le supprimer. Pour fonctionner, l'utilisateur devra installer le plugin de navigateur MetaMask. Si vous utilisez déjà activement le réseau Ethereum, vous avez probablement déjà installé ce plugin, c'est-à-dire que la majorité des utilisateurs qui souhaitent accéder au site via Ethereum ne rencontreront pas d'obstacle supplémentaire sur leur chemin.
Le processus d'authentification utilisateur général utilisant EtherAuth ressemble à ceci:
- Le site (backend) se transforme en un contrat intelligent et reçoit l'adresse Ethereum de l'utilisateur;
- Le site (backend) génère et se souvient de certains messages et demande à l'utilisateur de signer ce message en utilisant l'adresse authKey;
- L'utilisateur, étant sur le site (frontend), signe le message à l'aide du plugin MetaMask et l'envoie au backend;
- Le site (backend) vérifie la signature, et si tout est en ordre, il active la session utilisateur selon sa logique choisie.
Dans notre solution pour le hackathon, pour plus de simplicité, nous avons combiné les parties backend et frontend, nous avons eu un gros frontend. Dans la vraie vie, il est important que la vérification de l'authentification ait lieu dans un environnement non contrôlé par l'utilisateur, c'est-à-dire non pas dans le navigateur, mais sur le serveur.
Parmi les problèmes rencontrés, nous pouvons noter la vérification de la signature dans la partie frontend. Il n'y avait pas de prise en charge des courbes elliptiques dans le navigateur, j'ai donc dû ajouter une fonction au contrat intelligent qui renvoie le résultat de la récupération électronique du message et apprendre comment lui transmettre correctement les paramètres (les obtenir à partir d'un message signé par MetaMask).
En conséquence, nous avons reçu en deux jours une preuve de concept d'authentification décentralisée utilisant le réseau Ethereum et le plugin MetaMask. Nous comprenons comment affiner ce système afin d'ajouter l'anonymat à l'utilisateur. L'utilisateur peut restaurer l'accès en cas de fuite de sa clé primaire (mais pas en cas de fuite de la clé de récupération). Un système décentralisé n'est pas soumis à la censure de grandes structures telles que Google ou Facebook. Si la censure est nécessaire, le site doit l'exécuter seul, mais il ne peut le faire que dans son propre système, sans affecter l'accès des utilisateurs aux autres systèmes. Le réseau Ethereum n'effectue pas les transactions très rapidement (lors de la création d'un compte, l'utilisateur peut devoir attendre quelques minutes), mais il est possible d'obtenir des données et de vérifier l'authentification de l'utilisateur très rapidement. Cette solution évolue bien, car il y a beaucoup de nœuds avec des données, et n'importe qui peut en ajouter un à tout moment. La complexité de la mise en œuvre d'une telle solution pour les propriétaires de sites n'est pas supérieure à la complexité de la mise en œuvre de la prise en charge d'OAuth 2.0.
Conclusion
Bien sûr, aujourd'hui, les utilisateurs utilisant le réseau Ethereum sont négligeables par rapport au nombre d'utilisateurs de Facebook. Cependant, la popularité des technologies de la chaîne de blocs augmente, et je pense que dans un avenir prévisible, il y aura de plus en plus d'utilisateurs de ce type, ce qui signifie qu'il sera possible d'utiliser l'authentification décentralisée dans les systèmes industriels.
Les références