Pytanie:
Dlaczego po zresetowaniu hasła należy przekierować użytkownika na stronę logowania?
Adam Parkin
2015-11-10 19:57:05 UTC
view on stackexchange narkive permalink

OWASP Zapomniałem hasła sugeruje:

Po pomyślnym zresetowaniu hasła sesja powinna zostać unieważniona, a użytkownik przekierowany do strony logowania

Nie rozumiem, dlaczego jest to takie ważne. Czy istnieje podstawa bezpieczeństwa dla tego zalecenia, a jeśli tak, to jaka jest?

Może to tylko drobna kwestia i nie jest tak ważna, ale powstrzymuje użytkownika przed wprowadzaniem swoich danych w innym miejscu ... czasami robią takie szalone rzeczy
Mogę więc przechowywać nowe hasło w moim menedżerze haseł :)
Zależałoby to od mechanizmu resetowania hasła. Użytkownik resetujący hasło, ponieważ nie pamięta hasła, normalnie nie miałby sesji, ponieważ nie jest zalogowany. IMO może wystąpić problem ze sformułowaniem zdania, jeśli „sesja” odnosi się do sesji utworzonych przez innych użytkowników na tym samym koncie.
Pomyślałbym, że to sprawa UX, więc szybciej jest wprowadzić nowe hasło.
To stare pytanie, ale jestem ciekawy, czy jest to implementowane po wyjęciu z pudełka w aplikacjach tożsamości, takich jak Ping Identity, Oracle Access Manager, WSO2 Identity Server, Okta itp.?
Dziewięć odpowiedzi:
#1
+104
Jay
2015-11-10 20:03:06 UTC
view on stackexchange narkive permalink

Powiedzmy, że osoba atakująca ma Twoje hasło. Logujesz się i resetujesz. Jeśli reset nie unieważni wszystkich istniejących sesji, osoba atakująca nadal ma dostęp, o ile nie pozwoli, aby sesja wygasła.

Reset tak naprawdę nic nie przyniósł w tym scenariuszu.

W zależności od tego, co robi witryna, mogą również wystąpić problemy z zalogowaniem się przy użyciu nieaktualnego hasła. Powiedzmy, że Twoje hasło jest używane do odblokowania czegoś, jesteś zalogowany za pomocą „hasło1”, ale serwer ma teraz Twoje hasło zapisane jako „hasło2”, co się dzieje? Jest to oczywiście hipotetyczne, ale miejmy nadzieję, że to ilustruje.

Przekierowanie do ekranu logowania to chyba tylko zalecenie. Nie jestem pewien, dlaczego ma to znaczenie, dokąd wysyłasz użytkownika, ale z punktu widzenia użyteczności bardziej sensowne jest wysłanie użytkownika na stronę logowania niż na stronę główną.

Wydaje mi się, że powodem odesłania ich z powrotem do ekranu logowania jest faktycznie jasne dla użytkownika, że ​​musi zalogować się ponownie.
Po co wysyłać użytkownika do ekranu logowania, zamiast ... przesyłać go * przez * ekran logowania i faktycznie ponownie logować? Rozumiem sugestię unieważnienia istniejących sesji, która brzmi rozsądnie, ale * „Wpisałem skomplikowane nowe hasło dwa razy, a Ty nadal nie wiesz, kim jestem, i od razu chcesz, żebym wpisał je ponownie” * to bardzo frustrujące doświadczenie użytkownika .
@TessellatingHeckler Uwierzytelnianie dwuskładnikowe? Prostsze programowanie? Pewnego dnia hasło już dawno zniknie i już nigdy więcej nie będziemy mieli takich problemów.
@nocomprende być może to samo „prostsze programowanie”, które powoduje powstanie wzorca wcześniejszego w sekwencji resetowania hasła, w którym próbujesz się bez końca logować, rezygnujesz z prób zapamiętywania, klikasz, aby zresetować hasło i wyświetla się formularz „wprowadź swoją nazwę użytkownika lub adres e-mail ”i pomyśl *„ Cześć? Właśnie podałem swoją nazwę użytkownika * kilkanaście razy, czy nie możesz śledzić jej na jednej zmianie strony? ”*.
Unieważnienie wszystkich aktywnych sesji zapewnia również, że jeśli atakujący jest tym, który zmienia hasło (jeśli w jakiś sposób zdobył Twoje obecne), prawowity użytkownik jest o tym świadomy. Ale to nadal nie oznacza, że ​​jest to konieczne dla jednej sesji, w której hasło zostało zmienione. Oczywiście pomaga to w przechwyconych sesjach.
To, co piszesz w pierwszym akapicie i na czym opiera się Twój pierwszy punkt (... unieważnij ** wszystkie istniejące sesje **) nie jest tym, co jest zapisane w ściągawce OWASP (** sesja ** powinna zostać unieważniona).
Fakt, że użytkownik się loguje, nie unieważnia istniejących sesji.
Hmm, przegapiłem ostatnie zdanie ... w rzeczywistości uniemożliwia to osobom, które są zalogowane za pomocą wcześniej używanego hasła / sesji, korzystania z Twojego konta.
Jak już wcześniej skomentowałem, wszystkie wymienione przez Ciebie rzeczy można łatwo zrobić bez wchodzenia na stronę logowania. Tak więc, rozbieranie wszystkiego, nie odpowiadając na pytanie, sprowadza się do ostatniego akapitu: „Nie mam pojęcia, myślę, że to zalecenie dotyczące użyteczności”. Czy na pewno nie możesz znaleźć * żadnego * powodu związanego z bezpieczeństwem? Albo przynajmniej wyjaśnij, dlaczego jest to dobra użyteczność?
-1 To wcale nie odpowiada na pytanie! Zobacz komentarz @TessellatingHeckler's. (tylko nie mogę -1 z moim przedstawicielem, przepraszam).
@TomášZato Myślę, że miał na myśli bardziej "po zresetowaniu hasła * wszystkie * sesje są zakończone, wymuszając w ten sposób nowy login, a tym samym przekierowanie na stronę logowania" zamiast sugerować, że ponowne zalogowanie się magicznie powoduje zmianę sesji zakończenia. Tak przynajmniej piszę systemy radzą sobie z resetowaniem pw - ostatnim krokiem akcji resetowania jest zakończenie wszystkich bieżących sesji tego użytkownika, więc nie pozostaje nic innego jak przekierowanie do strony logowania.
#2
+43
SilverlightFox
2015-11-10 20:16:02 UTC
view on stackexchange narkive permalink

Ochrona sesji na potencjalnie zagrożonym koncie

Nie ma potrzeby przekierowywania do strony logowania, jeśli zarządzanie sesją po zmianie hasła odbywa się w bezpieczny sposób. Oznacza to, że dopóki wszystkie identyfikatory bieżącej sesji są unieważnione, a bieżąca sesja jest dołączona do nowego identyfikatora sesji (zwykle wystawiany jako token w pliku cookie uwierzytelniania - plik cookie jest wysyłany tylko do sesji, która właśnie zmieniła hasło), to tam nie ma ryzyka, że ​​osoba atakująca, która jest już na koncie, pozostanie zalogowana.

Artykuł OWASP

Uzasadnienie artykułu OWASP zostało wyjaśnione poniżej. Nie ma nic złego w aspekcie bezpieczeństwa, jednak występują pewne problemy z użytecznością.

Funkcja resetowania hasła jest często używana, gdy użytkownik chce zabezpieczyć swoje konto.

Poprzez unieważnienie wszystkich istniejące sesje po zresetowaniu hasła, system upewnia się, że tylko osoba z nowym hasłem może się zalogować.

Załóżmy na przykład, że osoba atakująca, która uzyskała dostęp do konta przy użyciu starego hasła, jest zalogowana . Zresetowanie wszystkich sesji spowoduje wylogowanie atakującego.

Słyszę, że po co wylogowywać bieżącego użytkownika?

Powiedzmy, że atakujący korzysta z sesji bieżącego użytkownika, powiedzmy przy użyciu luki w zabezpieczeniach naprawy sesji. Oznacza to, że osoba atakująca ma tę samą sesję co rzeczywisty użytkownik. Zresetowanie bieżącej sesji zapewni również, że na koncie nie ma nikogo, kto nie powinien mieć dostępu.

Przekierowanie do strony logowania w powyższym cytacie tak naprawdę opisuje fakt, że należy wylogować użytkownika bieżącej i wszystkich sesji (ale nie ma ryzyka, że ​​nie przestaniesz ich umieszczać w nowej sesji z nowym identyfikatorem).

W jaki sposób unieważnienie bieżących sesji i umieszczenie go w nowej wymaga odesłania użytkownika do strony logowania?
Wydaje mi się, że nie działa tak długo, jak długo bieżąca sesja i wszystkie inne sesje są unieważnione. Utworzenie nowej sesji z nową wartością tokenu sesji dla bieżącego klienta spełniłoby powyższe wymagania bezpieczeństwa i podporządkowałoby napastnika, który skorzystał z sesji lub uzyskał poprzednie hasło.
Ponieważ jeśli ich właśnie wylogowałeś, będą chcieli zalogować się ponownie!
#3
+34
John Biddle
2015-11-11 00:28:52 UTC
view on stackexchange narkive permalink

Inne odpowiedzi są prawdopodobnie bardziej poprawne z punktu widzenia firmy netsec, ale chciałem dodać, że można również upewnić się, że użytkownik jest w stanie zalogować się przy użyciu nowego hasła. To sprawia, że ​​staje się oczywiste, jeśli coś jest nie tak, na przykład przeglądarka automatycznie wypełnia stare hasło.

Uniemożliwia również użytkownikom używanie resetowania hasła jako loginu. Na jednym z moich kont łatwiej jest odpowiedzieć na pytania zabezpieczające niż zapamiętać hasło, ponieważ za każdym razem, gdy je resetuję, muszę ustawić unikalne hasło i nie mogę ich zapamiętać.

Tak, „OhNoSecond”, w którym zdajesz sobie sprawę, że błędnie wpisałeś hasło podczas resetowania go i nie masz pojęcia, co to jest, jest jednym z najlepszych, zapierających dech w piersiach doświadczeń IT. To jak zaglądanie do zamkniętego samochodu, aby zobaczyć kluczyki na siedzeniu kierowcy.
@nocomprende Ale gdyby tylko drzwi samochodu miały reset przez e-mail
Nie mam pojęcia, jak zamknę klucz w moim samochodzie; potrzebujesz klucza, aby go zamknąć!
@Alex Easy. Zamknij drzwi, włóż klucz do samochodu, zamknij drzwi. Ludzie robią to cały czas. A może w Twoim samochodzie jest coś, co temu zapobiega?
+1 To właściwie odpowiada na pytanie (w przeciwieństwie do dwóch bardziej pozytywnych odpowiedzi).
Bardzo dobra uwaga - jest niewygodna, ale w rzeczywistości potwierdza zamiary użytkownika
#4
+8
Deduplicator
2015-11-11 10:26:31 UTC
view on stackexchange narkive permalink

Jest tylko jeden możliwy powód związany z bezpieczeństwem , aby wysłać Cię na stronę logowania, ponieważ wszystkie stare sesje mogą zostać unieważnione, a Twoja bieżąca aktywna sesja zmieniła hasło z zastąpione automatycznie:
Sprawia, że ​​resetowanie hasła do logowania jest bardziej kłopotliwe, przez co rzadziej go używasz, a tym samym zabezpiecza je przed podsłuchem i przypadkowym ujawnieniem.

Istnieje również powód związany z użytecznością za wysłanie cię tam: upewnia się, że możesz faktycznie użyć nowego hasła, a każda pamięć podręczna haseł w przeglądarce zostanie zaktualizowana.

@Calimo Zaakceptowana odpowiedź w rzeczywistości nie daje powodu do przekierowania na stronę logowania; daje powód do zrobienia czegoś, co jest związane z punktu widzenia programisty, ale wydaje się zupełnie inne dla użytkownika.
#5
+6
supercat
2015-11-11 22:52:31 UTC
view on stackexchange narkive permalink

Jeśli użytkownicy mogą mieć przeglądarkę w celu przechowywania ich haseł, przekierowanie użytkownika na stronę logowania umożliwi przeglądarce przechwycenie nowego hasła na tej stronie. W przeciwnym razie, następnym razem, gdy użytkownik zaloguje się do przeglądarki, „pomocnie” wypełni pole hasła starym hasłem - jest to czynność, która może spowodować zamieszanie, jeśli użytkownik nie zdaje sobie sprawy z tego, co się dzieje.

#6
  0
Sarmad Ajmal
2015-11-11 18:13:20 UTC
view on stackexchange narkive permalink

Jest to bardzo proste, jeśli pamiętamy o środkach zaradczych. W rzeczywistości unieważni wszystkie twoje aktywne sesje, a także urządzenie złodzieja, który spowodował problem.

I nie można tego zrobić w dużo bardziej przyjazny dla użytkownika sposób? Nie widzę tego, gdzie jest część wymagająca ponownego logowania?
#7
  0
Erroneous
2015-11-13 01:49:06 UTC
view on stackexchange narkive permalink

Oprócz zapewnienia prostego mechanizmu tworzenia nowej, ważnej sesji, sprawdzania, czy nowe hasło działa i wylogowywania z bieżących sesji, istnieje również dodatkowa korzyść polegająca na tym, że użytkownik wprowadza hasło po raz trzeci, co ułatwia do zapamiętania.

#8
  0
Bill
2015-11-13 21:28:21 UTC
view on stackexchange narkive permalink

Oprócz wielu innych punktów przedstawionych tutaj, istnieją zalety ograniczenia mechanizmu tworzenia sesji tylko do jednego punktu wejścia z punktu widzenia możliwości utrzymania / wzmocnienia / audytu.

Użytkownik resetujący hasło w stan zablokowania nie powinien być koniecznie traktowany jako zalogowany użytkownik, nawet po przejściu przez wszelkie posiadane pętle potwierdzające tożsamość, w przeciwnym razie masz dodatkową sekwencję do przetestowania podczas przeprowadzania audytu / testów.

#9
  0
hamish
2019-08-11 12:34:30 UTC
view on stackexchange narkive permalink

gdy zalogujesz się ponownie zaraz po zresetowaniu hasła

a) bardziej prawdopodobne jest, że zapamiętasz hasło 3 sekundy później niż 3 dni później.

b) Twoja przeglądarka może wtedy zapytać użytkownika, czy chce zaktualizować swoje zapisane hasło nowym, a następnie zapamięta je na stronie logowania.



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...