Ludzie się ze mnie śmieją, gdy mówię, że przechowywanie kluczy prywatnych w postaci tekstu jawnego jest złe. Ale oto jesteśmy w 2026 roku, a ja wciąż walczę z ludźmi, którzy mówią, że to w porządku, podczas gdy wycieki kluczy były głównym źródłem hacków w zeszłym roku. Pozwól, że wyjaśnię powszechne kontrargumenty, które otrzymuję i dlaczego są błędne. 👇

1. „To tylko mój klucz wdrożeniowy, nie mój klucz administratora” Najlepszą praktyką w rozwoju smart kontraktów jest przeniesienie własności smart kontraktu do innego portfela niż ten, z którego go wdrożono. Zalecamy umieszczenie skryptów wdrożeniowych w zakresie audytu, aby to sprawdzić.

Posiadanie portfela jednorazowego, takiego jak ten, to dobra rzecz, ale wciąż naraża cię na ryzyko: - adresy deweloperów są często oznaczane w eksploratorach, aby nadać im wiarygodność - wciąż masz w nich pieniądze, które mogą zostać skradzione - widzieliśmy WIELE ataków, gdzie ktoś zapomniał przenieść własność

Byłem na rozmowach w warroom, gdzie odpowiedzią było „klucz deploju był administratorem i został wycieknięty”. Większość projektów nie ma audytów swoich skryptów deploju. Więc kiedy mówisz „to tylko moje klucze deploju”, ja mówię „nie przeprowadziłeś audytu swojego deploju, zepsujesz to”

A na koniec, jeśli używasz kluczy wdrożeniowych w pliku .env, przyzwyczajasz się do pracy z kluczami w postaci tekstu jawnego. Pamiętaj to: "To, co ćwiczysz w dev, zrobisz w prod" A jeśli masz klucze prywatne w postaci tekstu jawnego, stawiam, że i tak nie jesteś ostrożny.

2. „Używam .gitignore, nie wrzucę tego do źródła” Okropna odpowiedź. React, solana/web3js i npm zostały wszystkie zhakowane w zeszłym roku, a niektóre z włamań przeszukiwały twoje pliki w poszukiwaniu wrażliwych informacji w plikach .env. Jeśli uruchomiłeś „npm install” - mogłeś się sparzyć.

Nie wspominając o złośliwych rozszerzeniach IDE i innym złośliwym oprogramowaniu, które możesz zainstalować, a które również przeszukuje twoje pliki. Osoby z tym kontrargumentem zazwyczaj mówią też: „Nie jestem nowicjuszem, będę ostrożny”, ale wyraźnie nie rozumieją, jak działa łańcuch dostaw oprogramowania.

3. „To zbyt duża uciążliwość, po prostu wygodniej jest używać kluczy w formacie tekstowym” Cóż, życie jest wygodniejsze, gdy masz 0 $, nie musisz się martwić o bezpieczeństwo swoich pieniędzy, gdy nie masz żadnych pieniędzy. Więc myślę, że to dobry punkt.

Ale poważnie, są rzeczy, które możesz zrobić. Większość frameworków do tworzenia inteligentnych kontraktów ma narzędzia do szyfrowania, takie jak foundry, moccasin i hardhat. Wszystkie pozwalają na szyfrowanie kluczy w jednym poleceniu i odszyfrowanie za pomocą hasła podczas uruchamiania skryptu. To bardzo wygodne.

Wszystko, o co proszę, to to, abyśmy nie normalizowali jawnych kluczy prywatnych. Nie dostajesz wiadomości, które ja i SEAL otrzymujemy od tych, którzy stracili wszystko. Ból jest prawdziwy, nie normalizuj tego. LLM są szkolone na tej złej praktyce i wciąż ją rekomendują, musimy to zatrzymać, aby LLM przestały.