Kryptografia zwykle nie pęka przez AES.
Pęka przez pomysłowość programisty.
Najgroźniejsze błędy kryptograficzne nie wynikają z matematyki, tylko z implementacji: własne formaty tokenów, stałe IV, przewidywalne losowanie, brak uwierzytelnienia szyfrogramu i sekrety w kodzie. To rzeczy, które w pentestach wracają regularnie.
Co najczęściej widzimy
Aplikacja używa mocnego algorytmu, ale w złym trybie albo bez uwierzytelnienia. Token jest „zaszyfrowany”, ale można go modyfikować. Hasła są hash’owane, ale bez kosztownego KDF. Klucze są rotowane ręcznie albo wcale.
Dlaczego własna kryptografia jest ryzykowna
Projektowanie protokołów wymaga modelu zagrożeń. Bez niego łatwo zbudować mechanizm, który wygląda profesjonalnie, ale nie chroni przed replay, podmianą parametrów, padding oracle albo wyciekiem przez błędne komunikaty.
Jak raportujemy takie błędy
Nie wystarczy napisać „użyć AES-GCM”. Pokazujemy wpływ biznesowy, minimalny PoC, bezpieczny wzorzec migracji, plan rotacji kluczy i scenariusz kompatybilności ze starymi danymi.
Jak wygląda praktyczna weryfikacja
Szyfrowanie bez kontroli integralności często daje fałszywe poczucie bezpieczeństwa. Atakujący nie musi znać treści, jeśli może bezkarnie modyfikować zaszyfrowane parametry.
Na co zwracamy uwagę w raporcie
Tokeny własnego formatu
Brak podpisu lub zły dobór pól pozwala manipulować rolą, datą ważności albo identyfikatorem.
Losowość
Token resetu hasła nie może wynikać z czasu, ID użytkownika ani przewidywalnego generatora.
Zarządzanie kluczami
Sekret w repozytorium to nie konfiguracja — to przyszły incydent.
Masz własny mechanizm tokenów lub szyfrowania?
Sprawdzimy projekt i implementację kryptografii, wskażemy realne ryzyka i bezpieczną ścieżkę migracji.
Zapytaj o wycenę →