E-mail z hasłem dowodzi odwracalności, nie schematu

Usługa, która wysyła e-mailem bieżące hasło użytkownika, dowiodła jednego: potrafi uzyskać ten sekret w postaci, którą może wysłać. Nie dowiodła jednak, która kolumna, algorytm lub biblioteka go wytworzyła. Ta różnica ma znaczenie, ponieważ ustalenie jest prawdziwe, a wniosek, jaki ludzie z niego wyciągają, jest zwykle zbyt konkretny. Odwracalność gdzieś na ścieżce jest mechanizmem; zgadywany format przechowywania nie jest.

Utrzymaj dowody na tym poziomie, a reszta przeglądu pozostanie trafna.

Co dowodzi odesłanie starego sekretu

Weryfikator jednokierunkowy nie może wytworzyć oryginalnego hasła, ponieważ został zaprojektowany tak, aby nie był odwracalny. Jeśli usługa może wysłać hasło e-mailem, to w tym momencie przechowuje materiał, z którego hasło można odzyskać, albo przechwytuje i zapisuje tekst jawny przed haszowaniem. W obu przypadkach ścieżka odzyskiwania jest odwracalna, i to jest prawdziwe ustalenie bezpieczeństwa. Nie mówi nic o tym, czy ta sama baza danych używa kosztownego hasza dla innych kolumn.

Zwróć uwagę także na przypadek pośredni: zapisany zaszyfrowany blob z kluczem trzymanym przez aplikację jest w praktyce odwracalny, choć słowo zaszyfrowany brzmi w raporcie uspokajająco.

Dlaczego to ustalenie projektowe, a nie mapa przechowywania

E-mail dowodzi odtwarzalności i nie wskazuje dokładnego schematu. Może to być tekst jawny, szyfrowanie deterministyczne, rutyna zaciemniania dostawcy albo odrębny magazyn danych logowania używany tylko do odzyskiwania. Różne części produktu często używają odmiennego przechowywania. Przypisanie algorytmu na podstawie jednego e-maila to twierdzenie, które się rozpada na kolejnym spotkaniu.

To, co można powiedzieć, jest węższe i bardziej użyteczne: ta ścieżka potrafi odzyskać sekret, więc produkt nie może twierdzić, że nie istnieją żadne odtwarzalne dane logowania. Wszystko poza tym wymaga dowodów operatora.

Zbuduj resetowanie wokół autoryzacji

Resetowanie rozwiązuje inny problem: udowodnienie, że proszący może wybrać nowe hasło. Wytyczne OWASP w tej sprawie opisują bezpiecznie generowane jednorazowe tokeny lub kody z odpowiednim terminem ważności i traktują etap żądania jako coś, co trzeba chronić przed wyliczaniem i zalewaniem. Nieuwierzytelnione żądanie nie może samo zmienić konta. Zweryfikuj autoryzację przed przyjęciem zamiennika i po jednym udanym użyciu unieważnij token.

Kanał e-mail jest częścią modelu bezpieczeństwa. Posiadanie nazwy konta niczego nie dowodzi, a przepływ resetowania, który ujawnia, czy konto istnieje, daje atakującemu listę do pracy.

Unieważnij to, co chroniło hasło

Zmiana hasła nie kończy automatycznie dostępu, którego udzielało. Aktywne sesje VPN, zapamiętane urządzenia i tokeny wydawane przez serwer mogą mieć własne zachowanie unieważniania. Świadomie zdecyduj, które z nich muszą się zakończyć, i sprawdź, czy implementacja to robi, ponieważ użytkownik, który zakłada, że resetowanie wylogowało go wszędzie, często się myli. Zapisz tę decyzję razem z przepływem.

Dla operatorów: udokumentuj, który komponent weryfikuje żądanie, który zmienia dane logowania i jak obsługiwane są powiązane sesje. Dla użytkowników: chroń legalny kanał odzyskiwania i traktuj każdą wiadomość zwracającą hasło jako podejrzaną.

Dokładna ocena jest krótka: co dowodzi wiadomość, co pozostaje nieznane i czy odzyskiwanie zastępuje dostęp przez kontrolowany proces.