setApprovalForAll Phishing : lisez les signatures avant de signer

Pourquoi la plupart des utilisateurs de crypto sous-estiment les signatures de portefeuille

Les fenêtres de signature se ressemblent toutes : un nom de site en haut, un nom de méthode au milieu, un bouton Confirmer en bas. Comme l'apparence varie à peine entre un swap de token à 5 $ et une fuite complète du portefeuille, les utilisateurs apprennent à cliquer sans réfléchir. C'est précisément cette habitude qu'exploite le phishing par signature.

En réalité, les quatre types de signatures les plus courants, approve(), setApprovalForAll(), permit et eth_sign, font des choses radicalement différentes. Trois sont bien compris et ont des usages légitimes. Un, eth_sign, n'a aucun usage légitime dans l'Ethereum moderne et n'existe quasiment que dans les kits de phishing. Les traiter comme interchangeables, c'est exactement comment on perd sa collection.

Avant de passer en revue chacune d'elles, il est utile de garder à l'esprit qu'une signature de portefeuille est une autorisation, pas seulement une authentification. Quand vous signez avec votre clé privée, vous ne faites pas que prouver qui vous êtes ; vous donnez souvent au destinataire la permission de déplacer un actif à votre place. La signature est la permission.

Les types de signature, classés selon la fréquence à laquelle ils vident les portefeuilles

Toutes les signatures ne mettent pas vos fonds en danger de la même façon. Voici comment les quatre principaux types se comparent, classés à peu près du plus dangereux au plus bénin.

eth_sign : presque toujours une arnaque

eth_sign produit une signature ECDSA brute sur un texte arbitraire, sans donnée structurée ni domaine on-chain. Il n'y a pas de format de message standard, donc le site doit vous expliquer en clair ce que vous signez, et la plupart des portefeuilles ne l'analyseront même pas. Tout ce qui vous demande de signer un message eth_sign en 2026 est très probablement une tentative de phishing. Quelques outils légitimes l'utilisent encore (anciens authentificateurs, certaines consoles de débogage), mais pour un usage quotidien en DeFi et NFT vous devriez traiter eth_sign comme un refus automatique.

setApprovalForAll : accès NFT en blanc

setApprovalForAll(tokenAddress, operator, true) indique au contrat NFT qu'une adresse opérateur spécifique peut déplacer tous les NFT que vous possédez dans cette collection, présents et futurs. Approuver une marketplace NFT comme OpenSea ou Blur est normal : la marketplace doit transférer les NFT quand votre annonce est conclue. Le problème, c'est que le même appel vers un contrat de phishing livre toute votre collection Bored Ape, et pas un seul token.

Les dégâts ne sont pas limités. Si vous mintez un nouveau NFT de cette collection plus tard, l'ancienne approbation le couvre toujours. Si vous recevez un airdrop dans le même contrat ERC-721, l'opérateur peut aussi le balayer. Il n'y a aucune expiration ni plafond par token.

Signatures Permit : approbations de tokens sans gas

Permit (EIP-2612) et son successeur Permit2 vous permettent d'autoriser une dépense d'ERC-20 avec une signature hors chaîne au lieu d'une transaction approve on-chain. L'avantage est réel : pas de gas, une expérience utilisateur plus fluide, pas d'étape d'approbation séparée. Le coût, c'est qu'une signature permit est un chèque en blanc que le dépensier peut soumettre à tout moment avant la date limite que vous avez fixée.

Les stablecoins sont la cible privilégiée. Un site de phishing proposant un « claim USDC » ou un « vérificateur d'airdrop » peut demander tranquillement un permit qui donne à l'attaquant un USDC illimité pendant l'heure suivante ou plus. Vous pouvez quitter le site, vous éloigner, et revenir des heures plus tard pour trouver vos USDC envolés. La transaction affiche même le token légitime et votre propre adresse, ce qui la rend normale aux yeux des explorateurs de blocs.

approve() : l'approbation bornée, mais toujours risquée, par défaut

approve(spender, amount) définit une allowance de token. Si amount est petit (disons, 5 USDC pour un swap), le rayon de l'explosion est petit. Si amount est la constante magique MaxUint256 (~2^256 - 1), l'approbation est de fait illimitée et se comporte comme un permit.

De nombreux protocoles DeFi légitimes demandent des approbations illimitées par défaut parce qu'ils n'ont besoin de demander qu'une seule fois, puis de régler plus tard. Cette commodité est aussi celle de l'attaquant : quand les clés du dépensier fuient, vos tokens partent avec elles.

Étape par étape : comment lire une fenêtre contextuelle de portefeuille avant de signer

Quel que soit le portefeuille, la routine est la même. Ne signez pas en pilote automatique.

Étape 1 : lisez le nom de la fonction

Si vous voyez setApprovalForAll, permit ou eth_sign, ralentissez. Chacune comporte les risques évoqués plus haut. Un swap légitime affichera transferFrom ou un appel de routeur de swap, et non une autorisation.

Étape 2 : lisez les paramètres

Pour les autorisations, vérifiez qui est le spender. Pour setApprovalForAll, vérifiez l'adresse de l'opérateur. Recoupez les deux avec le vrai contrat du protocole (onglet « Contract » d'Etherscan, documentation du projet). Si l'adresse est toute neuve ou n'a pas de nom public, considérez-la comme hostile jusqu'à preuve du contraire.

Étape 3 : lisez la simulation

Les portefeuilles modernes (Rabby, Frame, MetaMask avec la simulation Tenderly) affichent un aperçu du changement d'état : quels jetons bougent, dans quelle direction, sur quel contrat. Si la simulation est vide ou ne se charge pas, c'est en soi un signal d'alerte. Les signatures légitimes produisent des simulations prévisibles.

Étape 4 : vérifiez la date limite

Les messages permit incluent un horodatage de date limite. Une date limite à un an est plus dangereuse qu'une autre expirant dans dix minutes. Le signatureTransfer de Permit2 inclut des champs supplémentaires (witness, expiration) qui déterminent l'ampleur de l'usage qui peut être fait de la signature. Traitez les délais anormalement longs comme suspects.

Étape 5 : utilisez un portefeuille brûleur dédié

Pour les airdrops, les mint et les sites inconnus, gardez un portefeuille distinct, approvisionné uniquement avec ce que vous êtes prêt à perdre. Les autorisations sur le brûleur ne pourront jamais toucher vos avoirs principaux. C'est l'assurance la moins chère dans la crypto.

Comment les attaquants transforment des signatures légitimes en drains

Le plus effrayant est que l'attaquant a rarement besoin de casser la cryptographie. Il lui suffit de vous faire cliquer sur Confirmer une seule fois.

Le piège classique de la mise en vente NFT

Vous arrivez sur une fausse page OpenSea qui reproduit la vraie interface. Elle vous demande d'« annuler une mise en vente bloquée » en signant un setApprovalForAll au contrat de la marketplace. La plupart des utilisateurs ne réalisent pas qu'« annuler une mise en vente » ne nécessite aucune signature, alors ils signent. L'attaquant contrôle désormais chaque NFT de ce portefeuille pour cette collection, et l'autorisation n'expire jamais.

Signatures de marketplaces de type Seaport

Le protocole Seaport d'OpenSea utilise des signatures d'ordre hors chaîne (plutôt que des mises en vente en chaîne) pour rendre les offres et les mises en vente moins coûteuses. Un ordre Seaport signé est un paquet de paramètres : zone, conduit, composants d'exécution, etc. Les pages de phishing ont appris à imiter ces signatures parce que les utilisateurs voient « OpenSea » dans la signature et supposent que c'est sûr. Lisez les paramètres, pas le nom du protocole.

Hameçonnage par permit sur stablecoins

USDC et USDT prennent en charge les permis EIP-2612. Un site qui « vérifie votre solde USDC » peut cacher un permit dans le bouton Signer. Vous confirmez une fois, vous repartez, et la signature reste dans le mempool en attendant que l'attaquant la soumette pendant la fenêtre de validité. La transaction en chaîne ressemble à un TransferFrom USDC normal, ce qui la rend plus difficile à repérer ensuite sur un explorateur de blocs.

Adversaire de type address poisoning combiné aux autorisations

Certains kits de phishing génèrent désormais une adresse vanity qui commence et finit par les mêmes caractères que votre véritable contrepartie. Quand un utilisateur jette un œil au destinataire, la correspondance du préfixe semble correcte. La même astuce est adaptée aux champs de spender d'autorisation : le spender malveillant partage les quatre premiers et quatre derniers caractères d'un spender légitime, en espérant que vous approuviez visuellement au lieu de lire l'adresse complète.

Implications pratiques : comment rendre votre portefeuille plus difficile à drainer

Lire les signatures est une habitude, pas un talent. Mettez en place quelques règles par défaut qui tiennent même lors des soirées de fatigue.

• Utilisez Rabby ou Frame comme portefeuille au quotidien. Tous deux décodent les types de signatures courants en langage clair et affichent la fonction appelée, et pas seulement le nom de la méthode.
• Conservez un portefeuille matériel pour tout avoir significatif. Les clés de signature ne touchent jamais une machine connectée à Internet, donc même une dapp malveillante ne peut pas extraire une signature utilisable.
• Lancez un audit mensuel des autorisations via revoke.cash (interface populaire et claire) ou le vérificateur d'autorisations d'Etherscan (sans connexion, données brutes). Révoquez tout ce qui concerne un contrat que vous n'avez pas utilisé depuis 90 jours.
• Remplacez les autorisations globales après chaque gros swap : passez l'allowance à 0, puis réapprouvez un petit montant. Cela invalide les anciennes autorisations illimitées.
• Désactivez eth_sign dans les paramètres de votre portefeuille si l'option existe. MetaMask, Rabby et Rainbow l'exposent toutes dans les paramètres avancés.
• Ajoutez en favori les dapps que vous utilisez réellement. La plupart du hameçonnage atteint les utilisateurs via des publicités dans les moteurs de recherche ou des liens sur Twitter, pas via des favoris. Tout ce qui vient d'un résultat de recherche mérite une lecture attentive supplémentaire.

Aucune de ces mesures n'est lourde à mettre en place. L'idée est que l'effort marginal pour vérifier une signature est faible, alors que le coût de l'omettre, c'est le portefeuille entier.

Foire aux questions sur le hameçonnage par signature

Voici les questions que les lecteurs tapent le plus souvent dans les moteurs de recherche sur le hameçonnage par signature de portefeuille. Les réponses restent sur des faits éducatifs, pas sur des conseils financiers, car le bon comportement ici dépend des avoirs et du modèle de menace de chaque lecteur.

Comment suivre la sécurité des wallets de manière intelligente

Le phishing par signature de wallet évolue vite, car la surface d'attaque évolue vite : chaque nouvelle primitive DeFi est un nouveau type de signature à apprendre, et chaque nouvelle fonctionnalité de wallet est un nouvel indice visuel à interpréter. Suivre les approbations, les signalements d'arnaques et les analyses post-mortem sur plusieurs blockchains est un travail à temps plein, et la plupart des utilisateurs n'ont pas le temps.

Zippfeed agrège les titres de sécurité sur Ethereum et dans l'écosystème crypto au sens large, attribue une note de sentiment à chaque histoire (bullish, neutre ou bearish sur le protocole nommé) et affiche une note d'importance de 0 à 100, afin que vous puissiez parcourir l'actualité du jour en quelques minutes, voir quelles signatures et approbations sont exploitées en ce moment, et vous éloigner des spenders risqués avant de vous faire vider.