SHA-1 to hasz, nie szyfrowanie. Przez lata służył do sprawdzania integralności plików i budowania mechanizmów zaufania, ale dziś jego bezpieczeństwo jest zbyt słabe, żeby opierać na nim nowe rozwiązania. W tym tekście wyjaśniam, jak działa ten algorytm, gdzie nadal się pojawia, dlaczego przestał wystarczać i czym rozsądnie zastąpić go w systemach Linux.
Skupię się na praktyce: na różnicy między sumą kontrolną a podpisem, na realnych skutkach kolizji i na prostych krokach, które pomagają ocenić, czy w danym projekcie SHA-1 trzeba od razu wycofać, czy tylko zostawić do odczytu starych danych.
Najważniejsze fakty o SHA-1 w praktyce
- SHA-1 generuje 160-bitowy hash, ale jego odporność na kolizje jest dziś zbyt słaba dla nowych podpisów i certyfikatów.
- NIST planuje pełne odejście od SHA-1 do 31 grudnia 2030 r.
- Najbezpieczniejszym domyślnym następcą jest SHA-256; w części środowisk sens ma też SHA-512/256 lub SHA3-256.
- W Linuksie do szybkiej weryfikacji plików zwykle używa się
sha256sum, a niesha1sum. - Do haseł nie używa się żadnego z tych hashy; tam potrzebny jest Argon2id, bcrypt albo scrypt.
Czym jest SHA-1 i po co w ogóle powstał
Najprościej mówiąc, hash działa jak krótki odcisk palca danych. Z dowolnego pliku, wiadomości albo bloku bajtów wylicza stałej długości wynik, który zmienia się radykalnie nawet po jednej drobnej modyfikacji wejścia. W przypadku SHA-1 ten wynik ma 160 bitów, czyli 40 znaków szesnastkowych w typowym zapisie.
To właśnie dlatego taki algorytm był przez lata użyteczny. Pozwalał szybko sprawdzić, czy plik nie został uszkodzony, czy kopia jest identyczna z oryginałem i czy podpis opiera się na tym samym materiale wejściowym. Ja lubię porównanie do pieczęci na kopercie: jeśli koperta się zmieni, pieczęć też wygląda inaczej. Tyle że pieczęć nie mówi jeszcze, kto ją przyłożył.
Właśnie tu leży ważne rozróżnienie. Hash nie jest szyfrowaniem, bo nie służy do ukrywania treści. Nie jest też podpisem cyfrowym, bo sam z siebie nie daje żadnej gwarancji tożsamości nadawcy. Dobrze nadaje się do kontroli spójności, dużo gorzej do budowania zaufania. To prowadzi do pytania, kiedy ten mechanizm przestał być wystarczająco mocny.
Dlaczego przestał być dobrym wyborem
W bezpieczeństwie kluczowa jest odporność na kolizje, czyli możliwość znalezienia dwóch różnych wejść z tym samym wynikiem. Jeśli taki atak staje się praktyczny, algorytm przestaje być dobrym fundamentem dla podpisów cyfrowych, certyfikatów i innych mechanizmów, które mają odróżniać oryginał od podrobionej wersji.
| Własność | Co oznacza w praktyce | Stan w SHA-1 |
|---|---|---|
| Odporność na kolizje | Trudno znaleźć dwa różne pliki z tym samym haszem | Praktycznie złamana |
| Odporność na preimage | Trudno odtworzyć wejście na podstawie samego hasza | Nadal trudna, ale to nie wystarcza do zaufania |
| Odporność na second preimage | Trudno znaleźć inny plik o tym samym wyniku co wskazany | Za słaba, by budować na niej nowe zabezpieczenia |
W 2017 roku Google pokazało pierwszą praktyczną kolizję SHA-1, a to zamknęło spór o to, czy problem jest tylko teoretyczny. Nie był. Od tego momentu sensowne stało się traktowanie SHA-1 jako algorytmu historycznego, a nie jako podstawy nowych podpisów i zaufanych łańcuchów weryfikacji. W praktyce oznacza to jedno: jeśli bezpieczeństwo ma znaczenie, trzeba patrzeć dalej niż ten hash.
To nie znaczy jednak, że każda jego obecność jest od razu awarią. Ważne jest, gdzie dokładnie algorytm pracuje i czy służy do tworzenia nowych zabezpieczeń, czy tylko do odczytu przeszłości.
Gdzie jeszcze spotkasz go w praktyce
W realnych systemach najczęściej trafiam na SHA-1 tam, gdzie ktoś przez lata po prostu nie ruszał starego mechanizmu. Sam fakt jego występowania nie mówi jeszcze wszystkiego. Liczy się rola, jaką pełni, oraz to, czy atakujący może podmienić również sam wynik haszowania.
| Miejsce użycia | Ryzyko | Co zrobić |
|---|---|---|
| Archiwalne podpisy i stare certyfikaty | Wysokie, jeśli nadal służą do nowych decyzji zaufania | Nie wystawiać nowych artefaktów z SHA-1, stare zostawić tylko do odczytu |
| Sumy kontrolne do dawnych wersji oprogramowania | Umiarkowane, jeśli weryfikujesz tylko historyczne wydania | Przechodzić na SHA-256 w nowych publikacjach |
| Starsze repozytoria i mechanizmy referencji | Różne, zależnie od tego, czy repo jest aktywnie rozwijane | Planować migrację i nie mieszać starego formatu z nowym bez testów |
| HMAC i KDF w legacy systemach | Mniejsze niż przy podpisach, ale nadal nie jest to wybór idealny | Migrować, jeśli kontrolujesz obie strony albo możesz zaktualizować protokół |
Najważniejsza zasada jest prosta: sama suma kontrolna nie potwierdza źródła pliku. Jeśli ktoś może podmienić plik, może też podmienić hash obok niego. Dlatego w nowoczesnym workflow lepiej traktować hasz jako element pomocniczy, a nie jako jedyny dowód, że plik jest właściwy. Z tego powodu warto od razu porównać dostępne zamienniki.
Czym zastąpić SHA-1 w systemach Linux
W praktyce wybieram algorytm nie według nostalgii, tylko według tego, czy ma być zgodny z większością narzędzi, czy raczej dać świeższy margines bezpieczeństwa. Dla większości zastosowań operacyjnych najlepszym punktem startu pozostaje SHA-256.
| Algorytm | Długość wyniku | Kiedy ma sens | Mój wybór |
|---|---|---|---|
| SHA-256 | 256 bitów | Checksumy plików, podpisy, API, większość systemów | Domyślnie tak |
| SHA-512/256 | 256 bitów | Środowiska 64-bitowe i ekosystemy oparte na rodzinie SHA-512 | Tak, gdy kompatybilność na to pozwala |
| SHA3-256 | 256 bitów | Nowe projekty, gdy chcesz inną rodzinę algorytmów | Dobry wybór dla nowych wdrożeń |
Ważne: do haseł nie wybiera się zwykłych hashy typu SHA-1, SHA-256 ani SHA3-256. Do przechowywania haseł potrzebny jest wolny algorytm przeznaczony właśnie do tego celu, na przykład Argon2id, bcrypt albo scrypt. To jest jeden z tych błędów, które widuję zaskakująco często w starych projektach.
Kiedy wybór algorytmu masz już uporządkowany, można przejść do konkretów: jak znaleźć problematyczne miejsca w kodzie i konfiguracji oraz jak bezpiecznie je wymienić.
Jak sprawdzić i wymienić użycie w praktyce
W systemach Linux zaczynam od prostego audytu: szukam miejsc, w których ktoś generuje, zapisuje albo weryfikuje SHA-1. Potem rozdzielam te przypadki na dwa koszyki. Pierwszy to rzeczy historyczne, które trzeba tylko odczytać. Drugi to wszystko, co tworzy nowe dane, podpisy albo sumy kontrolne.
sha1sum obraz.iso
sha256sum obraz.iso
sha256sum -c SHA256SUMS
rg -n "sha1|sha1sum|SHA-1" .Takie podejście jest praktyczne, bo nie wymaga od razu wielkiej migracji. Najpierw widzę, gdzie algorytm faktycznie występuje, a dopiero potem decyduję, czy wystarczy go zastąpić, czy trzeba przebudować cały proces publikacji. W przypadku pakietów i archiwów dobrze działa też prosta zasada: nowa wersja pliku ma nową sumę SHA-256, a plik z sumami powinien być dodatkowo podpisany niezależnym mechanizmem.
- Znajdź miejsca, w których SHA-1 jest używany do generowania nowych danych.
- Oddziel ścieżki historyczne od aktywnych.
- Zamień nowe generowanie na SHA-256 albo SHA3-256.
- Zostaw SHA-1 wyłącznie do weryfikacji starych danych, jeśli jest to naprawdę potrzebne.
- Przetestuj kompatybilność, zanim wyłączysz stary format w produkcji.
Jeśli publikujesz pliki do pobrania, nie zatrzymuj się na samej sumie kontrolnej. Dołącz podpis do pliku z sumami, bo dopiero to daje realną ochronę przed podmianą całego katalogu z wydaniem. To prowadzi do ostatniej rzeczy, która najczęściej rozstrzyga temat w organizacjach.
Trzy decyzje, które porządkują migrację z SHA-1
Gdybym miał zamknąć temat w trzech decyzjach, zrobiłbym to tak: najpierw wyłączyłbym tworzenie nowych podpisów i nowych sum opartych na SHA-1, potem zostawiłbym go wyłącznie do odczytu starych archiwów, a na końcu przepiąłbym nowe publikacje na SHA-256 albo SHA3-256. To jest prostsze niż niekończąca się dyskusja o tym, czy „jeszcze można”.
- Nowe podpisy, certyfikaty i artefakty wydawaj bez SHA-1.
- Stare dane weryfikuj tylko tam, gdzie naprawdę musisz zachować zgodność historyczną.
- W nowych projektach wybieraj SHA-256 jako domyślne minimum, a SHA3-256 rozważaj tam, gdzie ekosystem już go wspiera.
Ja traktuję SHA-1 jako technologię do porządkowania archiwów, a nie do budowania zaufania. W 2026 roku rozsądny domyślny wybór jest prosty: SHA-256 dla kompatybilności, SHA-3 gdy chcesz świeższej rodziny algorytmów, a SHA-1 zostawiasz tylko tam, gdzie wymaga tego historia.
