La signature à l'aveugle consiste à approuver une transaction ou un message que votre wallet ne peut pas afficher sous une forme lisible par un humain : du calldata brut, un bloc hexadécimal opaque ou un simple hash de 32 octets, au lieu d'un énoncé clair de ce que la signature autorise. Ce n'est pas un échec de la cryptographie : la signature est parfaitement valide et porte toute l'autorité on-chain, si bien que signer des données illisibles accorde des permissions que vous n'avez jamais inspectées — c'est pourquoi la quasi-totalité des wallet drainers est bâtie autour de cela. Le remède, c'est le clear signing, la signature claire — le wallet décode la requête en une phrase que vous pouvez vérifier, puis la simule pour prévisualiser quels actifs bougeraient réellement — plus une habitude qu'aucun logiciel ne peut fournir à votre place : refusez tout ce que vous ne pouvez pas lire. Parce qu'une signature est l'instant précis où l'autorité change de mains, il importe aussi que la clé qui la produit soit la vôtre seule : le Hot Wallet de WATS est non dépositaire sur Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana et TON, si bien que rien ne bouge sans une signature que vous avez personnellement approuvée.
Qu'est-ce que la signature à l'aveugle ?
La signature à l'aveugle, c'est toute approbation où la requête et son affichage se sont dissociés. La chaîne exécute ce que disent les octets signés ; votre écran est le seul endroit où votre intention et le contenu réel peuvent être comparés. Quand l'écran affiche de l'hexadécimal, cette comparaison devient impossible — et les attaquants construisent précisément sur cette impossibilité.
L'écart est un écart d'information, pas de mathématiques. Une signature n'encode pas « j'ai accepté d'échanger 100 USDC » ; elle encode « cette clé autorise ces octets ». Savoir si ces octets signifient un swap, une approbation illimitée ou un ordre hors chaîne qui vend votre NFT pour rien est une question à laquelle seule l'interface peut répondre — et la signature à l'aveugle, c'est ce qui arrive quand l'interface refuse d'y répondre.
Où apparaît la signature à l'aveugle
La signature à l'aveugle n'est pas une fonctionnalité unique : c'est une famille de situations où l'affichage ne rend pas justice aux données. Les suspects habituels :
| Type de requête | Ce que vous voyez le plus souvent | Risque |
|---|---|---|
| eth_sign | Un hash brut ou un bloc hexadécimal | Critique : invérifiable par conception ; à refuser toujours |
| Données typées brutes (EIP-712) | Des champs structurés : spender, montant, échéance | Élevé quand le sens reste flou : un champ lisible n'est pas un champ compris |
| Transaction de contrat | Une action décodée, ou du calldata brut quand le wallet ne sait pas la décoder | Dépend entièrement du décodage du wallet |
| Écran de hardware wallet n'affichant qu'un hash | Uniquement un hash sur l'écran de l'appareil | Élevé : l'appareil confirme une présence, pas une compréhension |
Le motif commun aux quatre lignes : le risque suit la lisibilité. Partout où l'affichage s'amincit, le danger s'épaissit.
Pourquoi eth_sign est-il si dangereux ?
Parmi les méthodes de signature, eth_sign est la forme la plus pure du problème : elle demande à votre wallet de signer une valeur arbitraire de 32 octets, présentée en hexadécimal brut, sans aucun des préfixes qui marquent un message comme « juste un message ». Comme l'entrée ne porte aucune séparation de domaine, elle pourrait être n'importe quoi — y compris le hash d'une transaction qui fait sortir des actifs de votre compte. Il n'existe aucun moyen, même pour un expert attentif, de vérifier la requête à partir de la seule fenêtre de confirmation ; elle est invérifiable par conception. C'est pourquoi les grands wallets ont déprécié la méthode ou l'ont retirée entièrement, et pourquoi la règle pratique ne souffre aucune exception : en 2026, un site qui demande eth_sign est soit dangereusement obsolète, soit franchement hostile, et les deux réponses veulent dire refuser.
Que vous montre réellement un hardware wallet ?
Un hardware wallet garde les clés hors ligne et affiche les requêtes sur un écran qu'un malware ne peut pas modifier — mais cet écran ne vaut que ce qu'on y affiche. Pour les interactions avec des contrats que l'appareil ne comprend pas, beaucoup d'appareils se sont historiquement rabattus sur l'affichage d'un simple hash, derrière une option de réglage littéralement nommée blind signing. Confirmer un hash sur un écran de confiance prouve que vous avez appuyé sur le bouton ; cela ne prouve rien sur ce que vous avez approuvé. La promesse de la sécurité matérielle, c'est ce que vous voyez est ce que vous signez — une promesse qui s'effondre en silence quand ce que vous voyez, ce sont trente-deux octets de bruit. L'isolation matérielle protège la clé, pas la décision.
Comment les drainers exploitent-ils la signature à l'aveugle ?
Un kit de drainer est, avant tout, une attaque contre l'expérience de signature. Le site ressemble à une page de mint, à une réclamation d'airdrop ou à un portail de support ; la requête qu'il déclenche est une approbation de token illimitée, un setApprovalForAll couvrant une collection NFT entière, ou une signature Permit ou d'ordre hors chaîne qui déplacera les actifs plus tard, sans nouvelle demande. Ce que tout cela partage, c'est la présentation : la victime a signé une requête qu'elle ne pouvait pas lire — ou qu'elle a lue sans la comprendre — et le vidage a suivi. Le mode opératoire complet est détaillé dans ce qu'est un wallet drainer, et la mécanique des approbations — y compris pourquoi une seule signature sans gas peut vider le solde d'un token — dans les approbations de tokens et Permit expliquées. Les deux mènent à la même cause profonde : le vol se produit à l'instant de la signature, et la signature à l'aveugle est ce qui permet à l'attaquant de franchir cet instant sans être démasqué.
Qu'est-ce que le clear signing — et où en est-il ?
La réponse du secteur, c'est le clear signing : le principe selon lequel un wallet doit traduire chaque requête en des termes qu'un humain peut vérifier avant de lui demander une signature. En 2026, il repose sur deux mécanismes. Le décodage : le wallet reconnaît le contrat et la fonction appelés et les restitue sous forme de phrase — approuver le token X, spender Y, montant illimité — avec des efforts comme ERC-7730 qui construisent des registres ouverts de métadonnées, afin que même les écrans des hardware wallets puissent afficher les appels de contrat en termes humains plutôt qu'en hash. La simulation : le wallet, ou un service qu'il interroge, exécute la transaction contre l'état actuel de la chaîne avant que vous ne signiez et prévisualise le résultat — quels actifs sortent, lesquels arrivent, quelles approbations changent. La simulation est une prédiction, pas une garantie — l'état peut changer entre l'aperçu et l'inclusion, et un contrat hostile peut se comporter autrement une fois miné — mais un aperçu montrant vos NFT partir vers une adresse inconnue arrête net la plupart des vidages. En 2026, l'adoption reste inégale selon les wallets et les chaînes : vérifiez donc ce que votre propre wallet affiche réellement pour une action de routine avant de compter sur lui pour vous avertir.
Règles pratiques : illisible veut dire non fiable
Vous n'avez pas besoin de savoir lire du calldata pour rester en sécurité — vous avez besoin d'habitudes qui font échouer les requêtes illisibles par défaut :
- N'approuvez jamais une requête eth_sign. Il ne lui reste plus aucun usage légitime répandu — traitez la requête elle-même comme le signal d'alarme.
- Privilégiez les wallets qui décodent et simulent. Si votre wallet affiche de l'hexadécimal brut pour une action de routine, c'est un problème de wallet qui justifie d'en changer.
- Lisez les champs qui comptent dans les requêtes de données typées : spender, montant, échéance, operator. Un montant illimité ou un spender inconnu est un panneau stop.
- Laissez désactivés les modes blind signing du matériel à moins de comprendre exactement pourquoi une transaction précise en a besoin — et désactivez-les de nouveau juste après.
- Connectez-vous délibérément. La plupart des mauvaises requêtes arrivent par des connexions précipitées — la méthode décrite dans comment connecter un wallet à une dApp en toute sécurité garde la porte d'entrée surveillée.
- Illisible égale non fiable. Refuser une signature ne coûte rien de plus qu'un nouvel essai. Une mauvaise signature peut tout coûter. L'asymétrie décide pour vous.
Où WATS s'inscrit
La signature à l'aveugle est un problème d'affichage. Le décodage et la simulation peuvent restituer une requête en termes lisibles, mais aucun wallet — WATS compris — ne peut décider à votre place si cette requête est bien celle que vous voulez. Ce qu'un wallet tranche, en revanche, c'est qui contrôle la clé qui transforme cette décision en autorité. Le Hot Wallet de WATS est entièrement non dépositaire : c'est vous qui détenez les clés, WATS ne détient jamais de clé, et aucun transfert ne quitte votre compte sans une signature que vous avez approuvée sur Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana ou TON. Cela supprime toute une catégorie de risque — personne ne peut signer à votre place — tout en laissant la discipline de lecture ci-dessus entièrement entre vos mains.
La WATS NFC Metal Card occupe la même place honnête. Elle ne stocke pas de clés privées et ne décode pas le calldata : c'est un dispositif tap-to-authenticate doté d'un identifiant de carte unique, appairé à un seul appareil, qui authentifie auprès des clés qui vivent dans les applications WATS. Cela ajoute un facteur physique — quelque chose que vous tenez, pas seulement quelque chose sur votre écran — mais cela ne peut pas rendre lisible une requête illisible. Rien ne le peut, sauf la fenêtre de confirmation elle-même.
Traitez donc les deux moitiés séparément. La moitié « lecture » est une habitude : ne signez jamais ce que vous ne pouvez pas lire, et refusez tout ce qui arrive sous forme d'hexadécimal nu. La moitié « garde » est un choix que vous faites une fois : gardez vos clés dans un wallet non dépositaire, et laissez l'autorité de signature là où elle doit être. Installez le Hot Wallet de WATS, transformez chaque fenêtre illisible en refus automatique, et appairez une WATS NFC Metal Card à votre appareil si vous voulez un facteur physique qui vous authentifie auprès des clés de vos applications WATS.
Foire aux questions
La signature à l'aveugle et eth_sign, est-ce la même chose ?
Non — eth_sign en est le cas le plus extrême. La signature à l'aveugle désigne toute approbation où vous ne pouvez pas lire ce que vous autorisez : calldata brut, données typées opaques, ou écran de hardware wallet n'affichant qu'un hash. eth_sign va plus loin en étant invérifiable par principe, raison pour laquelle les grands wallets l'ont déprécié ou retiré. Toute requête eth_sign est une signature à l'aveugle, mais on signe aussi beaucoup à l'aveugle dans des fenêtres de transaction tout à fait ordinaires.
Un hardware wallet me protège-t-il de la signature à l'aveugle ?
Seulement en partie. Un hardware wallet garde vos clés hors ligne et affiche les requêtes sur un écran qu'un malware ne peut pas altérer — mais si l'appareil ne sait pas décoder un appel de contrat, il peut n'afficher qu'un hash, et confirmer un hash ne vous apprend rien sur ce que vous avez approuvé. La protection s'améliore à mesure que les standards de métadonnées de clear signing atteignent les écrans des appareils, en 2026. Le matériel isole la clé ; à lui seul, il n'explique pas la transaction.
Un wallet non dépositaire me protège-t-il de la signature à l'aveugle ?
Il protège la clé, pas la décision. Non dépositaire signifie que vous seul pouvez produire une signature — le Hot Wallet de WATS en est un exemple : c'est vous qui détenez les clés, WATS ne détient jamais de clé, et rien ne bouge sur Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana ou TON sans votre approbation. Cela supprime le risque qu'un tiers signe à votre place, mais une signature que vous approuvez vous-même reste contraignante : lire la requête avant de l'approuver reste donc votre travail. La WATS NFC Metal Card ajoute un facteur physique tap-to-authenticate pour les clés qui vivent dans les applications WATS — elle ne stocke aucune clé privée et ne décode pas le calldata.
Que faire quand un wallet n'affiche que de l'hexadécimal brut ?
Refusez. Une demande de signature que vous ne pouvez pas lire est une demande que vous ne pouvez pas évaluer, et la refuser ne vous coûte qu'un nouvel essai. Enquêtez ensuite : vérifiez si la dApp est authentique, si votre wallet prend en charge le décodage et la simulation pour cette chaîne, et si l'action a vraiment besoin de cette méthode. S'il existe un chemin lisible — une fenêtre décodée ou un aperçu simulé — empruntez-le. S'il n'y en a aucun, considérez la requête comme non fiable et passez votre chemin.