Nie oznaczaj, że próba „nie powiodła się”. Użytkownik (uprawniony lub inny) prosi o link do resetowania hasła i podaje adres e-mail. Wszystko, co powinieneś tutaj powiedzieć, to

Twoje zgłoszenia zostały odebrane. Jeśli mamy konto pasujące do Twojego adresu e-mail, otrzymasz wiadomość e-mail z linkiem do zresetowania hasła.

Użytkownik nadal otrzyma łącze (powodzenie), ale atakujący nie wiedzieć, czy podany adres e-mail jest powiązany z kontem.

Przyczyną tego odkrycia jest to, że użytkownik otrzymuje różne odpowiedzi w zależności od istnienia adresu e-mail. Może to być tak proste, jak powiedzenie im, że adres nie jest znany lub coś bardziej subtelnego w odpowiedzi.

Najłatwiejszą implementacją pozwalającą uniknąć tego rodzaju problemu jest podanie dokładnie tej samej odpowiedzi , bez względu na to, czy adres e-mail istnieje, czy nie. Prosty

Informacja o zresetowaniu hasła została wysłana na podany adres e-mail. Jeśli nie otrzymasz e-maila, sprawdź, czy podałeś prawidłowy adres.

załatwi sprawę.

Jeśli adres e-mail jest Ci znany, wyślij informacje dotyczące resetowania hasła. Jeśli nie istnieje, nie rób nic. Prawdziwy użytkownik otrzyma łącze, a osoba atakująca nie może określić, czy wiadomość e-mail została wysłana, czy nie.

Jako dodatek do powyższych odpowiedzi (lepiej by się nadawał jako komentarz, ale jeszcze nie może tego zrobić) kolejnym krokiem, jaki może podjąć haker, jest zmierzenie CZASU Twojej odpowiedzi na formularz. Ustalenie, że wiadomość e-mail nie istnieje, może zająć 10 ms, natomiast wygenerowanie łącza resetowania i wysłanie wiadomości e-mail może zająć 100 ms. Haker może wiedzieć, czy odpowiedź jest wolniejsza, że ​​jest to udane znalezienie. Możesz zastosować losowy wyłącznik czasowy w przypadkach, gdy wiadomość e-mail nie zostanie znaleziona, aby obie odpowiedzi zajęły tyle samo czasu.

Przed czym chronimy?

Przede wszystkim należy zapytać, przed czym dokładnie chronią. W tym przypadku istnieją dwa różne zagrożenia:

• Zagrożenie 1 Brutalny atakujący wymusza na losowych wiadomościach e-mail znalezienie prawidłowych zarejestrowanych wiadomości e-mail. Teoretycznie można by to wykorzystać do tworzenia list spamu, ale o ile wiem, nigdy nie zostało to zrobione, ponieważ łatwiej jest po prostu wysłać e-maile, niż przejść przez dodatkowe problemy (ile razy otrzymałem spam z żądaniem mojego [niektórych konto bankowe], mimo że nie mieszka w USA, jest niezliczone).
• Zagrożenie 2 Osoba atakująca atakuje określonego użytkownika lub listę określonych użytkowników. Jest to szczególnie ważne, gdy sam fakt, że ktoś jest gdzieś zarejestrowany, może mieć konsekwencje. Przykład: sam fakt posiadania konta na Grindr lub Ashley Madison może być niebezpieczny w niektórych społecznościach.

Szerszy obraz

Następnym pytaniem do przemyślenia jest inne miejsca mogą ujawniać te same informacje i traktować je jako całość. Zwykle formularz rejestracyjny poinformuje użytkownika, czy podany adres e-mail jest już zarejestrowany, ale nie dotyczy to oczywiście większości oprogramowania B2B. Poza tymi funkcjami `` udostępnij użytkownikowi '' (pole wejściowe, w którym można wprowadzić wiadomość e-mail, aby udostępnić jakiś obiekt temu użytkownikowi) często również ujawnią te informacje, ale ponieważ są one rzadkie, nie uwzględnię ich w tej odpowiedzi.

Rozwiązania dla systemu z rejestracją publiczną

Przede wszystkim warto przyznać, że nie informowanie użytkownika o tym, że konto już istnieje w trakcie rejestracji jest z punktu widzenia UX bardzo nieprzyjemne. To samo dotyczy formularzy resetowania hasła, które po cichu zawodzą ¹ , gdy użytkownik popełnia literówkę lub ma wiele wiadomości e-mail. Nie oznacza to, że jest to coś, czego nie powinno się robić, ale należy to porównać z zagrożeniami i korzyściami dla bezpieczeństwa.

Biorąc pod uwagę system z rejestracją publiczną, ważną rzeczą do rozważenia jest to, jak duże jest Zagrożenie 2 dla użytkowników Twojego produktu. Biorąc pod uwagę nawet niewielkie ryzyko, rozsądnie jest zmienić formularz rejestracyjny, aby rozpocząć od wpisania tylko imienia i nazwiska i adresu e-mail, podając wiadomość „sprawdź swój adres e-mail, aby kontynuować rejestrację”, a jeśli adres e-mail jest już zarejestrowany, wysłanie użytkownikowi e-maila im tego. Podobnie w takim przypadku formularz resetowania hasła w żaden sposób nie poinformuje użytkownika, czy e-mail jest ważny.

Z drugiej strony, jeśli Zagrożenie 2 jest minimalne, musimy modelować wyłącznie pod kątem Zagrożenia 1 . Oczywiście poprzednie podejście zadziała również doskonale przeciwko Zagrożeniu 1, ale biorąc pod uwagę koszt UX warto rozważyć inne rozwiązania. Najbardziej oczywistym rozwiązaniem jest ograniczenie szybkości ² zarówno w przypadku sprawdzenia „e-maila istnieje”, jak i „zapomnienia hasła” (technicznie rzecz biorąc, wywołania te mogą nawet trafiać do tego samego punktu końcowego API). Często są one zaprojektowane tak, aby były dość łagodne dla pierwszych około 10 połączeń, ale po tym czasie bardzo szybko się ograniczają.

Ważne : nigdy nie usuwaj komunikatów o błędach z hasła rejestracja bez wprowadzania podobnych ograniczeń w formularzu rejestracyjnym.

Rozwiązania dla systemu bez rejestracji publicznej

Wszystko sprowadza się do tych samych problemów, co powyżej (i powinienem był napisać to najpierw ), ale bez „dodatkowego” kosztu trafienia do UX rejestracji stosunkowo „taniej” jest mieć bezpieczną formę zapomnienia hasła, chociaż oczywiście jest to nadal nieprzyjemne dla użytkowników i nadal można rozważyć, czy ograniczenie szybkości nie jest wystarczające dla Twojego konkretnego modelu zagrożeń.

Uwagi

^{1: Zamiast po cichu zawieść, rozsądnie jest przynajmniej wysłać wiadomość e-mail na podany adres e-mail z informacją, że ich adres e-mail nie został znaleziony. To 1) uniemożliwia atakującym masowe nadużywanie systemu (jak można zauważyć) oraz 2) zapobiega zastanawianiu się przez użytkowników, dlaczego nie otrzymują wiadomości e-mail.}

^{2: Czy zwróć uwagę, że ograniczenie prędkości może negatywnie wpłynąć na użytkowników dużych sieci lub VPN. Zawsze rozważ, jak ważna jest dla Ciebie ta publiczność i na tej podstawie poświęć odpowiednią ilość czasu, aby aplikacja działała nawet wtedy, gdy ograniczenie szybkości jest najsurowsze (np. Poprzez obniżenie limitu szybkości przez rozwiązanie captcha lub ustawienie maksymalnego limitu szybkości na około raz na minutę i upewnienie się, że aplikacja będzie czekała pełną minutę (uwaga: nadal będzie nieprzyjemne, biorąc pod uwagę zespół użytkowników rejestrujących się w tej samej usłudze na początku tego samego spotkania)).}

Należy rozważyć problem w porównaniu z niedogodnością rozwiązania. Często jest to kompromis.

Moim zdaniem zwykle lepiej jest poświęcić tę odrobinę bezpieczeństwa dla wygody użytkownika, chyba że ktoś mógłby zostać prześladowany za zarejestrowanie się w Twojej witrynie.

Od czasu do czasu po latach przechodzę do witryny i próbuję dowiedzieć się, jakiego adresu e-mail użyłem w tej witrynie. Witryny, które ukrywają te informacje, są dość denerwujące.

Zauważ, że to również (poza innymi odpowiedziami) dotyczy ekranu rejestracji, zamiast narzekać na już zarejestrowanego użytkownika, wysłał mu e-mail, że jest już zarejestrowany i nie przekazuje żadnej opinii na ten temat w aplikacji internetowej poza „sprawdź pocztę ”.

Najlepiej jest to zrobić, jeśli w pierwszym kroku przed weryfikacją adresu e-mail poprosisz o minimum danych wejściowych (co jest również dobre dla RODO, gdzie możesz udowodnić, że użytkownik otrzymał Twój e-mail informacyjny i kontynuował rejestrację ).

W rzeczywistości nie jest to kłopotliwe przy rejestracji i zawsze powinno być robione. W przypadku funkcji resetowania hasła udostępniamy opcję w oprogramowaniu, w której można wybrać bezpośrednią opinię lub opinię e-mail. (W scenariuszach korporacyjnych, zwłaszcza w intranecie, odgadywanie e-maili nie jest prawdziwym zagrożeniem).