Le vrai site peut aussi déclencher une autorisation malveillante : l’affaire de 3 millions de dollars m’a fait redécouvrir GRVT SecureKey
Le 25 juin, Polymarket a confirmé que le site officiel avait été compromis via un fournisseur tiers de front-end. Des scripts malveillants ont ainsi été injectés dans le véritable front-end consulté par certains utilisateurs. PeckShield, citant des enquêtes on-chain, indique qu’environ 3 millions de dollars en PUSD ont été détournés, puis pontés de Polygon vers Ethereum, et convertis en environ 1 893 ETH. Polymarket affirme avoir supprimé les dépendances concernées, contacté les utilisateurs affectés et procédé à une compensation intégrale.
Le plus contre-intuitif, c’est que : un nom de domaine correct, un HTTPS normal, et même la possibilité de se connecter à un compte ne prouvent pas, à eux seuls, que le contenu que vous allez signer correspond bien à votre intention réelle.
C’est précisément pour cela que je reconsidère la conception de <b>
@grvt_io SecureKey</b>. D’après le centre d’aide de GRVT, les permissions du compte sont réparties en deux couches : l’e-mail + mot de passe, ou Google/Microsoft OAuth, sont des identifiants Web2 utilisés pour consulter les actifs, les positions et participer à des fonctions non liées aux transactions ; toute opération susceptible de modifier la propriété des actifs nécessite une signature Web3 via SecureKey.
SecureKey est, en essence, une paire de clés publique/privée Ethereum. L’utilisateur peut choisir un portefeuille externe, ou utiliser un schéma OTP par e-mail pris en charge par Privy.
L’intérêt de cette architecture en couches est le suivant : même si des identifiants de connexion Web2 sont divulgués, un attaquant ne peut pas, à lui seul et uniquement à partir de l’état de connexion, effectuer les changements d’actifs qui exigent une autorisation SecureKey.
Si l’appareil est contrôlé par un cheval de Troie, si une extension de portefeuille externe est remplacée, ou si l’utilisateur approuve sur un vrai site un contenu altéré, une signature valide cryptographiquement peut tout de même exprimer une intention incorrecte. L’auto-hébergement réduit surtout le risque de transfert d’actifs unilatéral par la plateforme, mais n’élimine pas automatiquement les risques de phishing, la compromission de composants, les risques liés aux contrats intelligents et ceux des actions personnelles.
Après cet incident, j’ai ajouté cinq vérifications à chacune de mes signatures :
1. Entrer via un signet ou une page d’accès officielle, sans dépendre de publicités de recherche ni de liens reçus par messages privés ;
2. Déterminer si la requête est une preuve de connexion, une commande, une autorisation de jetons, un transfert ou un retrait ;
3. Vérifier les actifs, les quantités, l’adresse cible, le contrat et l’étendue de l’autorisation ;
4. Si la page et l’affichage du portefeuille ne correspondent pas, ou si une autorisation infinie est soudainement demandée, annuler immédiatement ;
5. Pour les comptes importants, utiliser autant que possible un dispositif de signature indépendant, sans mélanger l’environnement de téléchargement quotidien et les clés à haute valeur.
#grvt #SelfCustody #WalletSecurity #Web3Security