On se moque de moi parce que je dis aux gens que les clés privées en texte clair sont mauvaises. Mais nous y voilà en 2026, et je me bats toujours contre des gens qui disent que c'est acceptable, alors que les fuites de clés étaient la source numéro 1 des hacks l'année dernière. Laissez-moi expliquer les contre-arguments courants que je reçois et pourquoi ils sont faux. 👇

1. "C'est juste ma clé de déploiement, pas ma clé d'administrateur" Une bonne pratique pour le développement de contrats intelligents est de transférer la propriété d'un contrat intelligent vers un portefeuille différent de celui avec lequel vous avez déployé. Nous recommandons d'inclure les scripts de déploiement dans le périmètre d'un audit pour vérifier cela.

Avoir un portefeuille jetable comme celui-ci est une bonne chose, mais cela vous expose toujours : - les adresses de déploiement sont souvent étiquetées sur les explorateurs pour donner de la crédibilité - vous avez toujours de l'argent dans ces portefeuilles qui pourrait être volé - nous avons vu de NOMBREUX attaques où quelqu'un a oublié de transférer la propriété

J'ai participé à des appels de warroom où la réponse était "la clé de déploiement était l'administrateur, et elle a été divulguée". La plupart des projets ne font pas auditer leurs scripts de déploiement. Donc, quand tu dis "ce ne sont que mes clés de déploiement", je dis "tu n'as pas audité ton déploiement, tu vas tout foutre en l'air"

Et enfin, si vous utilisez des clés de déploiement dans un .env, vous prenez l'habitude d'être à l'aise avec des clés en texte clair. Souvenez-vous de ceci : "Ce que vous pratiquez en dev, vous le ferez en prod" Et si vous avez des clés privées en texte clair, je parie que vous n'êtes de toute façon pas prudent.

2. "J'utilise un .gitignore, je ne vais pas le pousser vers la source" Terrible réplique. React, solana/web3js et npm ont tous été piratés l'année dernière, et certains des piratages ont examiné vos fichiers à la recherche d'informations sensibles dans les fichiers .env. Si vous avez exécuté "npm install" - vous auriez pu être cuit.

Sans parler des extensions IDE malveillantes et d'autres logiciels malveillants que vous pourriez installer et qui passent également par vos fichiers. Les personnes qui avancent ce contre-argument disent aussi généralement "Je ne suis pas un noob, je ferai attention", mais il est clair qu'elles ne comprennent pas comment fonctionne la chaîne d'approvisionnement logicielle.

3. "C'est trop compliqué, il est juste plus pratique d'utiliser des clés en texte clair" Eh bien, la vie est plus pratique quand vous avez 0 $, vous n'avez pas à vous soucier de garder votre argent en sécurité quand vous n'avez pas d'argent. Donc, je suppose que c'est un bon point.

Mais sérieusement, il y a des choses que vous pouvez faire. La plupart des frameworks de développement de contrats intelligents ont des outils de cryptage, comme foundry, moccasin et hardhat. Ils vous permettent tous de chiffrer vos clés en une seule commande et de déchiffrer avec un mot de passe lors de l'exécution du script. C'est très pratique.

Tout ce que je demande, c'est que nous ne normalisions pas les clés privées en texte clair. Vous ne recevez pas les messages directs que moi et SEAL recevons de ceux qui ont tout perdu. La douleur est réelle, ne la normalisez pas. Les LLM sont formés sur cette mauvaise pratique et continuent de la recommander, nous devons arrêter pour que les LLM s'arrêtent.