szyfrowanie

Szyfrowanie to przekształcenie danych za pomocą algorytmu i klucza kryptograficznego w postać nieczytelną dla osób postronnych, odwracalne tylko przez posiadacza właściwego klucza. Chroni przede wszystkim poufność, a w nowoczesnych trybach także integralność danych ^[1]. MITRE uznaje brak szyfrowania wrażliwych informacji przed zapisem lub przesłaniem za odrębną słabość, CWE-311 ^[2]. Szyfrowanie różni się od funkcji skrótu (hashowania): skrótu nie da się odwrócić, szyfrogram z kluczem tak.

Jak działa

Algorytm szyfrujący jest jawny, tajny pozostaje klucz. Nadawca przekształca tekst jawny w szyfrogram, odbiorca z właściwym kluczem odtwarza tekst jawny. Kto przechwyci szyfrogram bez klucza, nie odczyta treści.

OWASP zaleca dla szyfrowania symetrycznego algorytm AES z kluczem co najmniej 128-bitowym, najlepiej 256-bitowym, w bezpiecznym trybie pracy ^[1]. Tam, gdzie to możliwe, należy stosować tryby uwierzytelnione, które poza poufnością gwarantują integralność i autentyczność danych; najczęściej używane to GCM i CCM ^[1]. Trybu ECB według OWASP nie należy stosować poza bardzo szczególnymi przypadkami ^[1]. Własnych algorytmów OWASP odradza jednoznacznie ^[1].

Typowy przepływ szyfrowania danych zapisanych pokazuje schemat poniżej.

RYS. 1Szyfrowanie danych w spoczynku

Rodzaje

Szyfrowanie dzieli się według liczby kluczy i według miejsca, w którym chroni dane.

W praktyce oba rodzaje kluczy się łączy. Kryptografia asymetryczna służy do uzgodnienia klucza, a symetryczna do szybkiego szyfrowania dużych ilości danych. Tak działa TLS. RFC 8446, opublikowany w sierpniu 2018 roku, określa cel TLS 1.3 jako ochronę przed podsłuchem, manipulacją i fałszowaniem wiadomości ^[4]. Po zestawieniu kanału dane są widoczne tylko dla jego końców i nie mogą zostać zmienione bez wykrycia ^[4].

Osobną odmianą jest szyfrowanie end-to-end (E2EE), w którym treść odszyfrowuje dopiero odbiorca, a nie serwer pośredniczący. Szyfrowanie urządzenia chroni z kolei cały dysk laptopa lub telefonu na wypadek kradzieży.

W WordPressie

Dla strony WordPress najważniejsze jest szyfrowanie w tranzycie, czyli HTTPS. Wymaga certyfikatu SSL/TLS i poprawnej konfiguracji serwera. CERT Polska zaleca dopuszczać tylko TLS 1.2 i TLS 1.3, a wyłączyć SSL 2.0, SSL 3.0, TLS 1.0 i TLS 1.1 ^[5]. Siła szyfrowania zależy według CERT Polska od konfiguracji serwera, czyli dopuszczonych wersji protokołu i zestawów szyfrów ^[5]. Zalecane są między innymi AES-GCM i ChaCha20-Poly1305, a słabe szyfry, jak RC4 i 3DES, należy wyłączyć ^[5].

Wersja 5.7 wprowadziła w Kondycji witryny wykrywanie HTTPS i przełączenie strony z HTTP na HTTPS jednym kliknięciem ^[6]. Ta sama zmiana podniosła status braku HTTPS w Kondycji witryny z „zalecanego” do „krytycznego” ^[6]. Po migracji warto usunąć mixed content, czyli zasoby ładowane nadal przez HTTP, i włączyć HSTS (HTTP Strict Transport Security). HSTS to nagłówek, który każe przeglądarce łączyć się z domeną wyłącznie przez HTTPS ^[5].

Hasła użytkowników WordPress nie szyfruje, tylko przechowuje jako skróty; to słuszne, bo hasła nie powinny dać się odtworzyć. Szyfrowanie w spoczynku dotyczy raczej kopii zapasowych i sekretów, takich jak klucze API zapisane przez wtyczki. Wtedy obowiązuje zasada OWASP, by klucze przechowywać w innym miejscu niż zaszyfrowane dane ^[1].

Zagrożenia i skutki

MITRE wskazuje dwa skutki braku szyfrowania. Atakujący z dostępem do sieci może podsłuchać ruch i odczytać wrażliwe dane bez dużej wiedzy technicznej ^[2]. Może też wstrzyknąć do komunikacji własne dane, a odbiorca nie odróżni ich od prawdziwych ^[2]. To scenariusz ataku man-in-the-middle (MITM), szczególnie groźny w publicznych sieciach Wi-Fi.

W zestawieniu OWASP Top 10 z 2025 roku błędy kryptograficzne (Cryptographic Failures) zajmują czwarte miejsce ^[3]. Kategoria obejmuje 32 powiązane CWE i 2185 CVE ^[3]. Wśród zaleceń OWASP są: szyfrowanie wszystkich danych w tranzycie protokołem TLS 1.2 lub nowszym, wymuszanie HSTS, rezygnacja z przestarzałych funkcji, takich jak MD5, SHA1 i tryb CBC, oraz przygotowanie do kryptografii postkwantowej ^[3].

Samo szyfrowanie nie wystarcza, gdy zawodzi zarządzanie kluczem. Klucz zapisany obok danych albo zaszyty w kodzie daje atakującemu wszystko, czego potrzebuje. Wyciek zaszyfrowanej bazy z kluczem jest w praktyce wyciekiem danych jawnych.

Dobre praktyki

• Szyfrować dane w tranzycie: HTTPS na całej stronie, TLS 1.2 lub 1.3, HSTS ^[3].
• Używać sprawdzonych algorytmów i trybów uwierzytelnionych, bez własnych konstrukcji ^[1].
• Przechowywać klucze oddzielnie od zaszyfrowanych danych ^[1].
• Zmieniać klucze przy podejrzeniu ujawnienia, po upływie okresu ważności albo po wykryciu słabości algorytmu ^[1]; zob. rotacja kluczy.
• Stosować szyfrowanie kopertowe: klucz danych (DEK) szyfruje dane, a klucz szyfrujący klucze (KEK) chroni klucz danych ^[1].
• Nie przechowywać danych, które nie są potrzebne ^[3].

Historia i przykłady

Przykład z 2010 roku pokazuje, że mocny algorytm nie chroni przy błędnej implementacji. Niebezpiecznik opisał wtedy wyniki firmy SySS dotyczące szyfrowanych pendrive’ów Kingston, SanDisk i Verbatim ^[7]. Nośniki szyfrowały dane sprzętowo 256-bitowym AES-em, a dysk był szyfrowany losowym kluczem, chronionym z kolei kluczem wyprowadzonym z hasła użytkownika ^[7]. Oprogramowanie wysyłało jednak do urządzenia to samo polecenie odszyfrowania niezależnie od wpisanego hasła, więc można je było podać bezpośrednio ^[7]. Nośniki miały certyfikat FIPS 140-2, ale jak zauważył Niebezpiecznik, zarządzanie kluczami było poza zakresem tej certyfikacji ^[7].