Ostatnio miałem czas, aby ponownie przemyśleć, jak powinna działać funkcja bezpiecznego resetowania hasła, najpierw gdy wbudowywałem tę funkcjonalność w , a następnie gdy pomagałem zrealizować coś podobnego innej osobie. W drugim przypadku chciałem dać mu link do kanonicznego źródła ze wszystkimi szczegółami dotyczącymi bezpiecznej implementacji funkcji resetowania. Problem w tym, że takie źródło nie istnieje, przynajmniej nie takie, które opisuje wszystko, co uważam za istotne. Dlatego postanowiłem napisać je samodzielnie.
Widzicie, świat zapomnianych haseł jest w rzeczywistości dość tajemniczy. Istnieje wiele różnych, całkowicie akceptowalnych punktów widzenia oraz mnóstwo dość niebezpiecznych. Istnieje szansa, że jako użytkownik końcowy natknęliście się na każdą z nich wielokrotnie; dlatego postaram się wykorzystać te przykłady, aby pokazać, kto robi wszystko dobrze, a kto nie, oraz na czym należy się skupić przy właściwej implementacji funkcji w swoim aplikacji.
Przechowywanie haseł: haszowanie, szyfrowanie i (och!) czysty tekst
Nie możemy omówić, co robić z zapomnianymi hasłami, zanim nie omówimy sposobu ich przechowywania. W bazie danych hasła przechowuje się w jednym z trzech podstawowych rodzajów:
- Czysty tekst. Jest kolumna z hasłem, które jest przechowywane w zwykłej formie tekstowej.
- Szyfrowane. Zazwyczaj przy użyciu szyfrowania symetrycznego (jeden klucz używany zarówno do szyfrowania, jak i deszyfrowania), a szyfrowane hasła także przechowywane są w jednej kolumnie.
- Haszowane. Proces jednostronny (hasło można haszować, ale nie można go deszyfrować); hasło, należy mieć nadzieję, jest opatrzone solą, a każde z nich znajduje się w osobnej kolumnie.
Zajmijmy się od razu najprostszym pytaniem: nigdy nie przechowuj haseł w czystym tekście! Nigdy. Jedna jedyna podatność na , jedna nieostrożnie wykonana kopia zapasowa lub jeden z dziesiątek innych prostych błędów — i to wszystko, game over, wszystkie twoje hasła — to znaczy, przepraszam, hasła wszystkich twoich klientów staną się publiczną własnością. Oczywiście, będzie to oznaczać ogromne prawdopodobieństwo, że publiczną własnością staną się ze wszystkich ich kont w innych systemach. I to będzie twoją winą.
Szyfrowanie jest lepsze, ale ma swoje słabości. Problem z szyfrowaniem polega na deszyfrowaniu; można wziąć te szalenie wyglądające szyfry i przekształcić je z powrotem w prosty tekst, a kiedy to nastąpi, wracamy do sytuacji z czytelnymi hasłami. Jak do tego dochodzi? Mała wada w kodzie odpowiedzialnym za deszyfrowanie hasła sprawia, że staje się ono publicznie dostępne — to jeden ze sposobów. Hakerzy uzyskują dostęp do maszyny, na której przechowywane są zaszyfrowane dane — to drugi sposób. Jeszcze jednym sposobem jest kradzież kopii zapasowej bazy danych, a ktoś również zdobywa klucz szyfrowania, który często przechowywany jest w bardzo niepewny sposób.
I to prowadzi nas do haszowania. Idea haszowania polega na tym, że działa w jedną stronę; jedynym sposobem porównania wprowadzonego hasła użytkownika z jego haszowaną wersją jest haszowanie wprowadzonego hasła i porównanie ich. Aby zapobiec atakom przy użyciu narzędzi takich jak „tabele tęczowe”, dodajemy do procesu losowość poprzez sól (dla pełnego obrazu przeczytaj mój o kryptograficznym przechowywaniu). Ostatecznie, przy odpowiedniej realizacji możemy z dużą pewnością stwierdzić, że haszowane hasła nigdy więcej nie staną się prostym tekstem (o zaletach różnych algorytmów haszowania opowiem w innym poście).
Krótki argument na temat haszowania i szyfrowania: jedynym powodem, dla którego kiedykolwiek będziesz musiał zaszyfrować, a nie haszować hasło, jest to, kiedy potrzebujesz zobaczyć hasło w prostym tekście, a nie powinieneś tego nigdy chcieć, przynajmniej w przypadku standardowej strony internetowej. Jeśli tego potrzebujesz, prawdopodobnie coś robisz źle!
Uwaga!
Trochę niżej w tekście posta znajduje się część zrzutu ekranu pornograficznej strony internetowej AlotPorn. Jest ona starannie przycięta, i tak nie ma tam nic, czego nie można by zobaczyć na plaży, ale jeśli to wciąż może spowodować jakieś problemy, nie przewijaj strony w dół.
Zawsze resetuj hasło, nigdy nigdy go nie przypominaj
Czy kiedykolwiek proszono cię o stworzenie funkcji przypominania Hasła? Zastanów się przez chwilę nad tą prośbą: dlaczego potrzebne jest to „przypomnienie”? Ponieważ użytkownik zapomniał hasła. Co tak naprawdę chcemy zrobić? Pomóc mu ponownie zalogować się do systemu.
Rozumiem, że słowo „przypomnienie” jest używane (często) w potocznym sensie, ale w rzeczywistości staramy się bezpiecznie pomóc użytkownikowi ponownie być online.. Ponieważ potrzebujemy bezpieczeństwa, istnieją dwa powody, dla których przypomnienie (tzn. wysłanie użytkownikowi jego hasła) nie jest odpowiednie:
- E-mail to niebezpieczny kanał. Tak samo jak nie przekazalibyśmy nic poufnego przez HTTP (użycie HTTPS), nie powinniśmy przekazywać nic przez e-mail, ponieważ jego warstwa transportowa jest niebezpieczna. Naprawdę, jest to znacznie gorsze niż proste przesyłanie informacji przez niezabezpieczony protokół transportowy, ponieważ e-mail często jest przechowywany na nośniku, dostępny dla administratorów systemów, przekazywany i rozpowszechniany, dostępny dla złośliwego oprogramowania itd. Niezaszyfrowany e-mail to niezwykle niebezpieczny kanał.
- W każdym razie nie powinieneś mieć dostępu do hasła. Przeczytaj ponownie poprzednią sekcję o przechowywaniu — powinieneś mieć hasz hasła (z dobrą solą), co oznacza, że nie powinieneś w żaden sposób móc wyciągnąć hasła i wysłać go przez e-mail.
Pozwól, że pokażę problem na przykładzie : Oto typowa strona logowania:
Oczywiście pierwszym problemem jest to, że strona logowania nie ładowana jest przez HTTPS, ale strona dodatkowo oferuje wysłanie hasła („Send Password”). Może to być przykład wspomnianego wyżej potocznego użycia tego terminu, więc zróbmy jeszcze jeden krok i zobaczmy, co się wydarzy:
Niestety, nie wygląda to dużo lepiej; a e-mail potwierdza istnienie problemu:
Mówi nam to o dwóch ważnych aspektach usoutdoor.com:
- Strona nie haszuje haseł. W najlepszym wypadku są one szyfrowane, ale prawdopodobnie są przechowywane w postaci tekstowej; nie widzimy dowodów inaczej.
- Strona wysyła długoterminowe hasło (możemy wracać i używać go wielokrotnie) przez niezabezpieczony kanał.
Po zrozumieniu tego, musimy sprawdzić, czy proces resetowania odbywa się w sposób bezpieczny. Na początek musimy upewnić się, czy osoba składająca wniosek ma prawo do jego wykonania. Innymi słowy, potrzebujemy weryfikacji tożsamości; przyjrzyjmy się, co się dzieje, gdy tożsamość zostaje potwierdzona bez uprzedniego sprawdzenia, czy wnioskodawca naprawdę jest właścicielem konta.
Wymienianie nazw użytkowników i jego wpływ na anonimowość
Najlepiej zilustrować ten problem wizualnie. Problem:
Widzicie? Zwróćcie uwagę na komunikat „Nie ma użytkownika zarejestrowanego na ten adres e-mail” (There is no user registered with this email address). Problem ten oczywiście występuje, jeśli taka strona potwierdza obecność zarejestrowanego użytkownika na ten adres e-mail. Bingo – właśnie odkryliście porno-fetyszy swojego męża/szefa/sąsiada!
Oczywiście, pornografia to dość klasyczny przykład znaczenia prywatności, jednak niebezpieczeństwo powiązania tożsamości z określoną stroną internetową jest znacznie szersze niż opisana powyżej potencjalnie niezręczna sytuacja. Jednym z niebezpieczeństw jest inżynieria społeczna; jeśli atakujący będzie w stanie powiązać osobę z serwisem, uzyska informacje, które może zacząć wykorzystywać. Na przykład może skontaktować się z osobą, podszywając się pod przedstawiciela strony internetowej, i poprosić o dodatkowe informacje, próbując przeprowadzić .
Podobne praktyki prowadzą również do powstania niebezpieczeństwa „wymieniania nazw użytkowników”, przy którym można sprawdzić istnienie całej kolekcji nazw użytkowników lub adresów e-mail na stronie internetowej za pomocą prostych zbiorowych zapytań i analizy na nie odpowiedzi. Masz listę adresów e-mail wszystkich pracowników i kilka minut na napisanie skryptu? Widzisz, na czym polega problem!
Jaka jest alternatywa? W rzeczywistości jest dość prosta i świetnie zrealizowana na :
Tutaj Entropay całkowicie nie ujawnia istnienia w swoim systemie adresu e-mail tym, kto nie jest właścicielem tego adresu. Jeśli wy jesteście jego właścicielem jeśli ten adres nie istnieje w systemie, to otrzymasz podobny e-mail:
Oczywiście, mogą zdarzyć się sytuacje, w których ktoś myśli, że zarejestrował się na stronie internetowej, ale tak nie jest, lub zrobił to z innego adresu e-mail. Powyższy przykład dwojako dobrze radzi sobie z takimi sytuacjami. Oczywiście, jeśli adres był prawidłowy, to otrzymasz e-mail, który ułatwia reset hasła.
Zaletą wybranego rozwiązania Entropay jest to, że weryfikacja tożsamości odbywa się za pośrednictwem adresu e-mail przed jakąkolwiek weryfikacją online. Niektóre strony proszą użytkowników o odpowiedź na pytanie zabezpieczające (więcej na ten temat poniżej) do jak może zacząć się proces resetowania; jednak problem z tym polega na tym, że należy odpowiedzieć na pytanie, jednocześnie podając jakiś rodzaj identyfikacji (e-mail lub nazwę użytkownika), co powoduje, że niemal niemożliwe jest odpowiedzenie w sposób intuicyjny, nie ujawniając istnienia konta anonimowego użytkownika.
W takim podejściu istnieje niewielkie pogorszenie użyteczności, ponieważ w przypadku próby resetowania nieistniejącego konta nie ma natychmiastowej informacji zwrotnej. Oczywiście, to jest cały sens wysyłania wiadomości e-mail, ale z perspektywy zwykłego użytkownika, jeśli wprowadzi błędny adres, dowie się o tym dopiero przy odbiorze wiadomości. To może wywołać pewien niepokój, ale jest to niewielka cena za tak rzadki proces.
Jeszcze jedna uwaga, nieco odbiegająca od tematu: funkcje pomocy w logowaniu, które ujawniają poprawność nazwy użytkownika lub adresu e-mail, mają ten sam problem. Zawsze należy odpowiadać użytkownikowi komunikatem „Niepoprawne połączenie nazwy użytkownika i hasła” (Twoje połączenie nazwy użytkownika i hasła jest nieprawidłowe), a nie potwierdzać wprost istnienie informacji identyfikacyjnych (na przykład „nazwa użytkownika jest poprawna, ale hasło jest błędne”).
Wysyłanie hasła resetującego a wysyłanie URL do resetowania
Następna koncepcja, którą musimy omówić, dotyczy sposobu resetowania hasła. Istnieją dwa popularne rozwiązania:
- Generowanie nowego hasła na serwerze i jego wysyłanie przez e-mail
- Wysyłanie wiadomości e-mail z unikalnym adresem URL, który ułatwia proces resetowania
Mimo to , pierwszy punkt nigdy nie powinien być stosowany. Jego problem polega na tym, że oznacza to obecność przechowywanego hasła, do którego można wrócić i ponownie użyć w dowolnym momencie; zostało przesłane przez niezabezpieczony kanał i pozostaje w twojej skrzynce odbiorczej. Istnieje prawdopodobieństwo, że skrzynka odbiorcza synchronizuje się z urządzeniami mobilnymi i klientem pocztowym, a także może być przechowywana online w serwisie pocztowym przez bardzo długi czas. Chodzi o to, że skrzynka pocztowa nie może być postrzegana jako niezawodne medium do długoterminowego przechowywania.
Ale poza tym pierwszy punkt ma jeszcze jeden poważny problem - on maksymalnie upraszcza blokadę konta w niecnych zamiarach. Jeśli znam adres e-mail kogoś, kto posiada konto na stronie internetowej, mogę zablokować je w każdej chwili, po prostu resetując jego hasło; to atak typu „odmowa usługi”, podany na tacy! Dlatego reset powinien być przeprowadzany tylko po pomyślnej weryfikacji uprawnienia osoby, która o to prosi.
Kiedy mówimy o URL resecie, mamy na myśli adres strony internetowej, który jest unikalny dla tego konkretnego przypadku procesu resetowania. Oczywiście musi być losowy, nie powinien być łatwy do odgadnięcia i nie może zawierać żadnych zewnętrznych linków do konta, które ułatwiają reset. Na przykład, URL resetu nie powinien być po prostu ścieżką typu „Reset/?username=JohnSmith”.
Chcemy stworzyć unikalny token, który można wysłać mailowo jako URL resetu, a następnie zweryfikować go z rekordem na serwerze dla konta użytkownika, potwierdzając w ten sposób, że właściciel konta to w rzeczywistości ta sama osoba, która próbuje zresetować hasło. Na przykład, token może mieć postać „3ce7854015cd38c862cb9e14a1ae552b” i być przechowywany w tabeli razem z ID użytkownika, który wykonuje reset, oraz czasem wygenerowania tokena (więcej na ten temat poniżej). Przy wysyłaniu wiadomości e-mail zawiera ona URL taki jak „Reset/?id=3ce7854015cd38c862cb9e14a1ae552b”, a gdy użytkownik go wczytuje, strona sprawdza istnienie tokena, a następnie potwierdza informacje użytkownika i pozwala na zmianę hasła.
Oczywiście, ponieważ opisany powyżej proces (miejmy nadzieję) pozwala użytkownikowi na stworzenie nowego hasła, należy zapewnić załadowanie adresu URL przez HTTPS. Nie, , ten adres URL z tokenem powinien wykorzystywać bezpieczeństwo warstwy transportowej, aby na formularz wprowadzania nowego hasła nie można było przeprowadzić ataku i stworzone przez użytkownika hasło było przekazywane za pomocą bezpiecznego połączenia.
Ponadto dla adresu URL resetowania należy dodać limit czasowy tokena, aby proces resetowania można było zrealizować w ciągu określonego przedziału czasu, powiedzmy, w ciągu jednej godziny. Gwarantuje to, że okno czasowe resetowania będzie minimalne, aby osoba, która otrzymała ten adres URL resetowania, mogła działać tylko w ramach tego bardzo małego okna. Oczywiście, atakujący może ponownie rozpocząć proces resetowania, ale będzie musiał uzyskać kolejny unikalny adres URL resetowania.
Na koniec musimy zapewnić jednorazowość tego procesu. Po zakończeniu procesu resetowania token należy usunąć, aby adres URL resetowania przestał być aktywny. Poprzedni punkt jest niezbędny, aby atakujący miał bardzo małe okno, w którym może manipulować adresem URL resetowania. Plus, oczywiście, po pomyślnym zakończeniu resetowania token nie jest już potrzebny.
Niektóre z tych kroków mogą wydawać się zbyt przesadne, ale w żadnym stopniu nie przeszkadzają w użyteczności i w rzeczywistości zwiększają bezpieczeństwo, chociaż w sytuacjach, które, miejmy nadzieję, będą rzadkie. W 99% przypadków użytkownik będzie korzystać z resetowania w bardzo krótkim okresie czasu i nie będzie resetował hasła ponownie w najbliższej przyszłości.
Rola CAPTCHA
O, CAPTCHA, środek ochrony, który wszyscy tak chętnie znienawidzą! W rzeczywistości, CAPTCHA jest narzędziem nie tyle do ochrony, co do identyfikacji — czy jesteś człowiekiem, czy robotem (lub zautomatyzowanym skryptem). Jej celem jest zapobieganie automatycznemu przesyłaniu formularzy, co oczywiście, może może być stosowane jako próbę złamania zabezpieczeń. W kontekście resetowania haseł, CAPTCHA oznacza, że funkcji resetowania nie będzie można złamać metodą brute force, aby następnie spamować użytkownika lub próbować określić istnienie kont (co oczywiście będzie niemożliwe, jeśli przestrzegałeś wskazówek z sekcji o weryfikacji tożsamości).
Oczywiście, CAPTCHA sama w sobie nie jest idealna; istnieje wiele przypadków jej programowego 'złamania' i osiągania wystarczających wskaźników sukcesu (60-70%). Ponadto istnieje rozwiązanie, przedstawione w moim poście o , w którym można płacić ludziom kilka centów za rozwiązanie każdej CAPTCHA i uzyskanie wskaźnika sukcesu na poziomie 94%. Oznacza to, że jest ona podatna, jednak (lekko) podnosi próg wejścia.
Przyjrzyjmy się przykładzie PayPal:
W tym przypadku proces resetowania po prostu nie może się rozpocząć, dopóki nie zostanie rozwiązana CAPTCHA, dlatego teoretycznie automatyzacja procesu jest niemożliwa. Teoretycznie.
Jednak dla większości aplikacji internetowych byłoby to przesadą i całkowicie reprezentuje obniżenie użyteczności — ludzie po prostu nie lubią CAPTCHA! Ponadto, CAPTCHA to taki element, do którego w razie potrzeby można łatwo wrócić. Jeśli usługa zaczyna być atakowana (tu przyda się logowanie, ale o tym więcej później), dodanie CAPTCHA jest niezwykle proste.
Pytania i odpowiedzi zabezpieczające
We wszystkich rozpatrywanych przez nas metodach mieliśmy możliwość zresetowania hasła, mając jedynie dostęp do konta e-mail. Mówię 'jedynie', ale oczywiście, nielegalne uzyskanie dostępu do czyjegoś konta e-mail powinno może być skomplikowanym procesem. Jednak .
W rzeczywistości, powyższy link dotyczący złamania konta Sary Palin na Yahoo! służy dwojakim celom; po pierwsze, ilustruje, jak łatwo można łamać (niektóre) konta e-mail, po drugie, pokazuje, jak można w złym celu wykorzystać złe pytania zabezpieczające. Ale wrócimy do tego później.
Problem z resetowaniem haseł w 100% opartym na e-mailu polega na tym, że integralność konta na stronie, którego hasło próbujesz zresetować, staje się w 100% zależna od integralności konta e-mail. Każdy, kto ma dostęp do Twojego e-maila, ma dostęp do każdego konta, które można zresetować, po prostu otrzymując e-mail. Dla takich kont e-mail jest 'kluczem do wszystkich drzwi' Twojego życia w sieci.
Jednym ze sposobów na zmniejszenie tego ryzyka jest wdrożenie wzorca pytania i odpowiedzi zabezpieczającego. Bez wątpienia już je widziałeś: wybierasz pytanie, na które tylko ty powinny znasz odpowiedź, a następnie podczas resetowania hasła jest ono zadawane. To zwiększa pewność, że osoba próbująca dokonać resetu faktycznie jest właścicielem konta.
Wracając do Sary Palin: problem polegał na tym, że odpowiedzi na jej pytanie zabezpieczające/pytania można było łatwo znaleźć. Szczególnie, gdy jesteś tak znaczącą postacią publiczną, informacje o panieńskim nazwisku matki, historii kształcenia czy miejscach zamieszkania w przeszłości nie są wcale tak tajne. W rzeczywistości, większość z nich może być łatwo odnaleziona przez prawie każdego. Tak się stało z Sarą:
Hacker David Kernell uzyskał dostęp do konta Palin, odkrywając szczegóły jej biografii, takie jak uczelnia i data urodzenia, a następnie wykorzystując funkcję odzyskiwania zapomnianych haseł do kont Yahoo!.
Przede wszystkim to błąd projektowania ze strony Yahoo! — wskazując na tak proste pytania, firma w zasadzie sabotowała wartość pytania zabezpieczającego, a co za tym idzie, ochronę swojego systemu. Oczywiście resetowanie haseł do konta e-mail zawsze jest trudniejsze, ponieważ nie możesz potwierdzić jego posiadania, wysyłając e-mail do właściciela (nie mając drugiego adresu), ale na szczęście dzisiaj nie ma zbyt wielu sposobów na stworzenie takiego systemu.
Wracając do pytań zabezpieczających — istnieje opcja, aby dać użytkownikowi możliwość tworzenia własnych pytań. Problem polega na tym, że rezultatem będą strasznie oczywiste pytania:
Jakiego koloru jest niebo?
Pytania stawiające ludzi w niewygodnej sytuacji, kiedy w celu identyfikacji pytanie zabezpieczające używa człowieka (na przykład w call center):
Z kim spałem w Wigilię?
Lub szczerze głupie pytania:
Jak pisze się 'hasło'?
Kiedy chodzi o pytania zabezpieczające, należy uratować użytkowników od samych siebie! Innymi słowy, pytanie zabezpieczające powinno być definiowane przez samą stronę, a jeszcze lepiej, zadawać szereg pytania zabezpieczającego, z których może wybierać użytkownik. I nie tylko wybierać jeden; w idealnym przypadku użytkownik powinien wybrać dwa lub więcej pytań zabezpieczających w momencie rejestracji konta, które następnie będą używane jako drugi kanał identyfikacji. Posiadanie wielu pytań zwiększa stopień pewności w procesie weryfikacji, a także daje możliwość dodania losowości (nie zawsze wyświetlanie tego samego pytania), a także zapewnia pewną nadmiarowość na wypadek, gdyby prawdziwy użytkownik zapomniał hasła.
Jakie więc powinno być dobre pytanie zabezpieczające? Na to wpływa kilka czynników:
- Powinno być zwięzłe — pytanie powinno być jasne i jednoznaczne.
- Odpowiedź powinna być konkretna — nie potrzebujemy pytania, na które jedna osoba może odpowiedzieć w różny sposób.
- Możliwe odpowiedzi powinny być różnorodne — pytanie o ulubiony kolor danej osoby daje bardzo małą podzbiór możliwych odpowiedzi.
- Wyszukiwanie odpowiedź powinna być trudna — jeśli odpowiedź może być łatwo znaleziona przez kogokolwiek (pamiętajmy o osobach zajmujących wysokie stanowiska), to jest słabe
- Odpowiedź powinna być stałym w czasie — jeśli pytamy o ulubiony film, to po roku odpowiedź może być inna.
Jak to bywa, istnieje strona internetowa poświęcona dobrym pytaniom, która nazywa się . Część pytań wydaje się całkiem w porządku, inne nie przechodzą niektórych z opisanych wyżej testów, zwłaszcza testu „łatwości wyszukiwania”.
Pozwól, że pokażę, jak pytania zabezpieczające są realizowane w PayPal i, w szczególności, jakie wysiłki podejmuje strona w celu identyfikacji. Widzieliśmy wcześniej stronę rozpoczęcia procesu (z CAPTCHA), a tutaj pokażemy, co się dzieje po wprowadzeniu adresu e-mail i rozwiązaniu CAPTCHA:
W rezultacie użytkownik otrzymuje taki e-mail:
Na razie wszystko wygląda całkiem normalnie, ale oto co kryje się za tym adresem URL resetowania:
I tak wchodzą w grę pytania zabezpieczające. Tak naprawdę PayPal także pozwala zresetować hasło, potwierdzając numer karty kredytowej, więc istnieje dodatkowy kanał, do którego wiele stron nie ma dostępu. Po prostu nie mogę zmienić hasła, nie odpowiadając na oba pytania zabezpieczające (lub nie znając numeru karty). Nawet jeśli ktoś przechwyci mój e-mail, nie będzie mógł zresetować hasła konta PayPal, jeśli nie wie ode mnie nieco więcej informacji osobistych. Jakie informacje? Oto propozycje pytań zabezpieczających oferowane przez PayPal:
Pytanie dotyczące szkoły i szpitala może budzić pewne wątpliwości pod względem prostoty wyszukiwania, ale pozostałe nie są takie złe. Jednak dla zwiększenia bezpieczeństwa PayPal wymaga dodatkowej identyfikacji w celu zmiany odpowiedzi na tajne pytania:
PayPal to dość utopijny przykład bezpiecznego resetowania hasła: implementuje CAPTCHA, aby zmniejszyć ryzyko ataków typu brute force, wymaga odpowiedzi na dwa tajne pytania, a następnie żąda jeszcze jednego rodzaju zupełnie innej identyfikacji tylko do zmiany tych odpowiedzi — i to po tym, jak użytkownik już się zalogował. Oczywiście tego się spodziewaliśmy od PayPal; to instytucja finansowa, która obraca dużymi sumami pieniędzy. Nie oznacza to, że każde zresetowanie hasła musi przechodzić przez te etapy — w większości przypadków to przesada — jednak jest to dobry przykład w sytuacjach, gdy bezpieczeństwo to poważna sprawa. Zaletą systemu tajnych pytań jest to, że jeśli nie wdrożono go od razu, można go dodać później, jeśli wymaga tego poziom ochrony zasobu. Dobrym przykładem tego jest Apple, które dopiero niedawno wdrożyło ten mechanizm
[artykuł napisany w 2012 roku] . Rozpocząwszy pewnego dnia aktualizację aplikacji na iPadzie, zobaczyłem następujące pytanie:Następnie zobaczyłem ekran, na którym można było wybrać kilka par tajnych pytań i odpowiedzi, a także zapasowy adres e-mail:
Jeśli chodzi o PayPal, pytania są wybierane z góry, a niektóre z nich są naprawdę całkiem dobre:
Każda z trzech par pytań i odpowiedzi stanowi odrębny zbiór możliwych pytań, dzięki czemu istnieje wystarczająca liczba sposobów konfiguracji konta.
Kolejnym aspektem, który trzeba rozważyć w kontekście odpowiedzi na tajne pytanie, jest przechowywanie. Znajdowanie się w bazie danych w postaci czystego tekstu stwarza prawie te same zagrożenia, co w przypadku hasła, a mianowicie — ujawnienie bazy danych natychmiast ujawnia wartość i naraża na ryzyko nie tylko aplikację, ale i potencjalnie zupełnie inne aplikacje korzystające z tych samych tajnych pytań (to znowu
kwestia jagód acai ). Jednym z rozwiązań jest bezpieczne haszowanie (odporny algorytm i kryptograficznie losowa sól), jednak w przeciwieństwie do większości przypadków przechowywania haseł, może być uzasadniony powód, aby odpowiedź była widoczna jako zwykły tekst. Typowym scenariuszem jest weryfikacja tożsamości przez żywego operatora przez telefon. Oczywiście, w tym przypadku haszowanie również jest stosowane (operator może po prostu wprowadzić odpowiedź podaną przez klienta), ale w najgorszym przypadku sekretną odpowiedź należy przechowywać na jakimś poziomie w bezpiecznym magazynie kryptograficznym, nawet jeśli to tylko szyfrowanie symetryczne. Podsumujmy: traktuj sekrety jak sekrety!
I ostatni aspekt sekretnych pytań i odpowiedzi — są one bardziej podatne na inżynierię społeczną. Próba bezpośredniego wyciągnięcia hasła do cudzego konta to jedno, a prowadzenie rozmowy o jego wykształceniu (popularne pytanie sekretne) to zupełnie inna sprawa. Tak naprawdę, możesz w realistyczny sposób rozmawiać z kimś o wielu aspektach jego życia, które mogą stanowić pytanie sekretne, nie budząc przy tym podejrzeń. Oczywiście, istotą sekretnego pytania jest to, że wiąże się z czyimś doświadczeniem życiowym, dlatego jest zapamiętywane, a to właśnie w tym tkwi problem — ludzie uwielbiają opowiadać o swoim doświadczeniu życiowym! Niewiele można z tym zrobić, chyba że wybierzesz takie opcje sekretów, które z mniejszym prawdopodobieństwem mogłyby być wyciągnięte inżynierią społeczną.
[Ciąg dalszy nastąpi.]
Reklama
VDSina oferuje niezawodne , każdy serwer podłączony jest do łącza internetowego o prędkości 500 Megabitów i jest bezpłatnie chroniony przed atakami DDoS!
Źródło: habr.com
