Niedawno miałem czas, aby ponownie przemyśleć, jak powinna działać funkcja bezpiecznego resetowania hasła, najpierw kiedy budowałem tę funkcję , a potem, gdy pomógł innej osobie zrobić coś podobnego. W drugim przypadku chciałem dać mu link do kanonicznego zasobu ze wszystkimi szczegółami, jak bezpiecznie wdrożyć funkcję resetowania. Problem jednak w tym, że takiego zasobu nie ma, a przynajmniej nie takiego, który opisuje wszystko, co wydaje mi się istotne. Postanowiłem więc napisać to sam.
Widzisz, świat zapomnianych haseł jest w rzeczywistości dość tajemniczy. Istnieje wiele różnych, całkowicie akceptowalnych punktów widzenia i wiele dość niebezpiecznych. Prawdopodobnie spotkałeś się z każdym z nich wiele razy jako użytkownik końcowy; dlatego postaram się użyć tych przykładów, aby pokazać, kto robi to dobrze, a kto nie, i na czym należy się skupić, aby uzyskać tę funkcję bezpośrednio w swojej aplikacji.
Przechowywanie haseł: mieszanie, szyfrowanie i (och!) zwykły tekst
Nie możemy omówić, co zrobić z zapomnianymi hasłami, zanim nie omówimy, jak je przechowywać. Hasła przechowywane są w bazie danych w jednym z trzech głównych typów:
- Prosty tekst. Istnieje kolumna z hasłem, która jest przechowywana w postaci zwykłego tekstu.
- Zaszyfrowane. Zwykle stosuje się szyfrowanie symetryczne (jeden klucz służy zarówno do szyfrowania, jak i deszyfrowania), a zaszyfrowane hasła są również przechowywane w tej samej kolumnie.
- Hashowane. Proces jednokierunkowy (hasło można zaszyfrować, ale nie można go usunąć); hasło, Chciałbym mieć nadzieję, po którym następuje sól i każdy z nich znajduje się w osobnej kolumnie.
Przejdźmy od razu do najprostszego pytania: Nigdy nie przechowuj haseł w postaci zwykłego tekstu! Nigdy. Jedna podatność na , jedno nieostrożne wykonanie kopii zapasowej lub jeden z dziesiątek innych prostych błędów - i tyle, koniec gry, wszystkie hasła - czyli przepraszam, hasła wszystkich Twoich klientów staną się domeną publiczną. Oczywiście oznaczałoby to ogromne prawdopodobieństwo, że ze wszystkich swoich kont w innych systemach. I to będzie twoja wina.
Szyfrowanie jest lepsze, ale ma swoje słabe strony. Problem z szyfrowaniem polega na odszyfrowaniu; możemy wziąć te szalenie wyglądające szyfry i przekonwertować je z powrotem na zwykły tekst, a kiedy to się stanie, wrócimy do sytuacji z hasłem czytelnym dla człowieka. Jak to się stało? Do kodu, który odszyfrowuje hasło, udostępniając je publicznie, dostaje się niewielka luka - jest to jeden ze sposobów. Hakerzy uzyskują dostęp do maszyny, na której przechowywane są zaszyfrowane dane – to druga metoda. Innym sposobem jest kradzież kopii zapasowej bazy danych, w wyniku której ktoś otrzymuje również klucz szyfrujący, który często jest przechowywany w bardzo niepewny sposób.
A to prowadzi nas do haszowania. Ideą mieszania jest to, że jest ono jednokierunkowe; jedynym sposobem porównania hasła wprowadzonego przez użytkownika z jego zaszyfrowaną wersją jest zaszyfrowanie danych wejściowych i porównanie ich. Aby zapobiec atakom z narzędzi takich jak Rainbow Tables, dodajemy proces losowości (przeczytaj mój o przechowywaniu kryptograficznym). Ostatecznie, jeśli zostaną poprawnie wdrożone, możemy być pewni, że zaszyfrowane hasła nigdy więcej nie staną się zwykłym tekstem (o zaletach różnych algorytmów mieszających będę mówić w innym poście).
Krótki argument na temat mieszania a szyfrowania: jedynym powodem, dla którego kiedykolwiek będziesz musiał szyfrować zamiast hashować hasło, jest sytuacja, gdy musisz zobaczyć hasło w postaci zwykłego tekstu i nigdy nie powinieneś tego chciećprzynajmniej w standardowej sytuacji na stronie internetowej. Jeśli tego potrzebujesz, najprawdopodobniej robisz coś złego!
Ostrzeżenie!
Poniżej w tekście wpisu znajduje się fragment zrzutu ekranu serwisu pornograficznego AlotPorn. Jest starannie przycięty, więc na plaży nie ma niczego, czego nie byłoby widać, ale jeśli nadal może powodować problemy, nie przewijaj w dół.
Zawsze resetuj swoje hasło nigdy nie przypominaj mu
Czy kiedykolwiek poproszono Cię o utworzenie funkcji przypomnienia hasło? Cofnij się o krok i pomyśl o tej prośbie w odwrotnej kolejności: dlaczego potrzebne jest to „przypomnienie”? Ponieważ użytkownik zapomniał hasła. Co tak naprawdę chcemy zrobić? Pomóż mu zalogować się ponownie.
Zdaję sobie sprawę, że słowo „przypomnienie” jest używane (często) w znaczeniu potocznym, ale tak naprawdę staramy się bezpiecznie pomóc użytkownikowi ponownie być online. Ponieważ potrzebujemy bezpieczeństwa, istnieją dwa powody, dla których przypomnienie (tj. wysłanie użytkownikowi hasła) nie jest właściwe:
- E-mail to niepewny kanał. Tak jak nie wysyłalibyśmy niczego poufnego przez HTTP (użylibyśmy HTTPS), tak nie powinniśmy wysyłać niczego poufnego przez e-mail, ponieważ jego warstwa transportowa jest niepewna. W rzeczywistości jest to znacznie gorsze niż zwykłe wysyłanie informacji za pośrednictwem niezabezpieczonego protokołu transportowego, ponieważ poczta jest często przechowywana na urządzeniu pamięci masowej, dostępna dla administratorów systemu, przesyłana dalej i dystrybuowana, dostępna dla złośliwego oprogramowania itd. Nieszyfrowana poczta e-mail to niezwykle niebezpieczny kanał.
- I tak nie powinieneś mieć dostępu do hasła. Przeczytaj ponownie poprzednią sekcję dotyczącą przechowywania - powinieneś mieć skrót hasła (z dobrą, mocną solą), co oznacza, że nie powinieneś w żaden sposób wyodrębnić hasła i wysłać go pocztą.
Pozwólcie, że zademonstruję problem na przykładzie : Oto typowa strona logowania:
Oczywiście pierwszym problemem jest to, że strona logowania nie ładuje się przez HTTPS, ale witryna prosi również o przesłanie hasła („Wyślij hasło”). Może to być przykład potocznego użycia wspomnianego powyżej terminu, więc pójdźmy o krok dalej i zobaczmy, co się stanie:
Niestety, nie wygląda to dużo lepiej; i e-mail potwierdzający, że wystąpił problem:
To mówi nam o dwóch ważnych aspektach usoutdoor.com:
- Strona nie hashuje haseł. W najlepszym przypadku są one szyfrowane, ale prawdopodobnie są przechowywane w postaci zwykłego tekstu; Nie widzimy dowodów przeciwnych.
- Strona wysyła hasło długoterminowe (możemy do niego wracać i używać go wielokrotnie) niezabezpieczonym kanałem.
Mając to na uwadze, musimy sprawdzić, czy proces resetowania odbywa się w bezpieczny sposób. Pierwszym krokiem w tym celu jest upewnienie się, że osoba żądająca ma prawo wykonać reset. Innymi słowy, wcześniej potrzebujemy sprawdzenia tożsamości; przyjrzyjmy się, co się dzieje, gdy tożsamość jest weryfikowana bez uprzedniego sprawdzenia, czy osoba żądająca jest rzeczywiście właścicielem konta.
Lista nazw użytkowników i jej wpływ na anonimowość
Problem ten najlepiej zilustruje wizualnie. Problem:
Czy ty widzisz? Zwróć uwagę na komunikat „Nie ma zarejestrowanego użytkownika o tym adresie e-mail”. Problem oczywiście pojawia się, jeśli taka strona potwierdzi dostępność użytkownik zarejestrowany przy użyciu takiego adresu e-mail. Bingo - właśnie odkryłaś porno fetysz swojego męża/szefa/sąsiadki!
Oczywiście porno jest dość ikonicznym przykładem znaczenia prywatności, ale niebezpieczeństwa związane z skojarzeniem danej osoby z konkretną witryną internetową są znacznie szersze niż opisana powyżej potencjalnie niezręczna sytuacja. Jednym z zagrożeń jest inżynieria społeczna; Jeśli atakującemu uda się dopasować osobę do usługi, wówczas będzie miał informacje, z których będzie mógł zacząć korzystać. Na przykład może skontaktować się z osobą podającą się za przedstawiciela strony internetowej i poprosić o dodatkowe informacje, próbując popełnić przestępstwo .
Praktyki takie stwarzają również ryzyko „wyliczania nazw użytkowników”, w ramach którego można zweryfikować istnienie całego zbioru nazw użytkowników lub adresów e-mail w witrynie internetowej, po prostu przeprowadzając zapytania grupowe i sprawdzając odpowiedzi na nie. Masz listę adresów e-mail wszystkich pracowników i kilka minut na napisanie scenariusza? Wtedy zobaczysz, w czym tkwi problem!
Jaka jest alternatywa? W rzeczywistości jest to dość proste i wspaniale zaimplementowane :
W tym przypadku Entropay nie ujawnia absolutnie nic na temat istnienia adresu e-mail w swoim systemie osobie, która nie jest właścicielem tego adresu... Jeśli ty własny ten adres, a nie istnieje on w systemie, to otrzymasz takiego maila:
Oczywiście mogą zaistnieć akceptowalne sytuacje, w których ktoś myśliże zarejestrowałeś się na stronie. ale tak nie jest lub zrobiłem to z innego adresu e-mail. Przykład pokazany powyżej dobrze radzi sobie z obiema sytuacjami. Oczywiście, jeśli adres się zgadza, otrzymasz wiadomość e-mail ułatwiającą zresetowanie hasła.
Subtelność rozwiązania wybranego przez Entropay polega na tym, że weryfikacja tożsamości odbywa się wg e-mail przed jakąkolwiek weryfikacją online. Niektóre witryny proszą użytkowników o odpowiedź na pytanie zabezpieczające (więcej na ten temat poniżej) do jak można rozpocząć resetowanie; jednak problem polega na tym, że musisz odpowiedzieć na pytanie, podając jakąś formę identyfikacji (adres e-mail lub nazwę użytkownika), co sprawia, że intuicyjna odpowiedź bez ujawniania istnienia konta anonimowego użytkownika jest prawie niemożliwa.
Z takim podejściem tak mały zmniejszona użyteczność, ponieważ próba zresetowania nieistniejącego konta nie powoduje natychmiastowej reakcji. Oczywiście na tym polega sens wysyłania wiadomości e-mail, ale z perspektywy prawdziwego użytkownika końcowego, jeśli wprowadzi błędny adres, dowie się o tym dopiero po otrzymaniu wiadomości e-mail. Może to wywołać pewne napięcie z jego strony, ale jest to niewielka cena za tak rzadki proces.
Kolejna uwaga, trochę nie na temat: funkcje pomocy przy logowaniu, które ujawniają, czy nazwa użytkownika lub adres e-mail są prawidłowe, mają ten sam problem. Zawsze odpowiadaj użytkownikowi komunikatem „Twoja nazwa użytkownika i hasło są nieprawidłowe”, zamiast wyraźnie potwierdzać istnienie poświadczeń (na przykład „nazwa użytkownika jest poprawna, ale hasło jest nieprawidłowe”).
Wysyłanie hasła resetowania a wysyłanie adresu URL resetowania
Następną koncepcją, którą musimy omówić, jest sposób resetowania hasła. Istnieją dwa popularne rozwiązania:
- Wygenerowanie nowego hasła na serwerze i przesłanie go e-mailem
- Wyślij e-mail z unikalnym adresem URL, aby ułatwić proces resetowania
Mimo , pierwszego punktu nie należy nigdy używać. Problem w tym, że to oznacza, że istnieje zapisane hasłodo którego w każdej chwili możesz wrócić i z którego ponownie skorzystasz; został wysłany przez niezabezpieczony kanał i pozostaje w Twojej skrzynce odbiorczej. Istnieje prawdopodobieństwo, że skrzynki odbiorcze są synchronizowane pomiędzy urządzeniami mobilnymi i klientem poczty e-mail, a ponadto mogą być przechowywane online w internetowej usłudze poczty e-mail przez bardzo długi czas. Chodzi o to, że skrzynki pocztowej nie można uważać za niezawodny sposób długoterminowego przechowywania.
Ale poza tym pierwszy punkt ma inny poważny problem - to upraszcza tak bardzo, jak to możliwe blokowanie konta w złych zamiarach. Jeśli znam adres e-mail osoby posiadającej konto w serwisie, to w każdej chwili mogę ją zablokować, po prostu resetując jej hasło; To atak typu „odmowa usługi” podany na srebrnej tacy! Dlatego reset należy przeprowadzić dopiero po pomyślnej weryfikacji uprawnień wnioskodawcy do niego.
Kiedy mówimy o resetowanym adresie URL, mamy na myśli adres strony internetowej unikalny dla tego konkretnego przypadku procesu resetowania. Oczywiście powinien być losowy, nie łatwy do odgadnięcia i nie powinien zawierać żadnych zewnętrznych linków do konta ułatwiających reset. Na przykład resetowany adres URL nie powinien być po prostu ścieżką typu „Reset/?username=JohnSmith”.
Chcemy stworzyć unikalny token, który można wysłać pocztą jako adres URL resetowania, a następnie porównać z rekordem serwera konta użytkownika, potwierdzając w ten sposób, że właścicielem konta jest w rzeczywistości ta sama osoba, która próbuje zresetować hasło. Na przykład tokenem może być „3ce7854015cd38c862cb9e14a1ae552b” i przechowywany w tabeli wraz z identyfikatorem użytkownika wykonującego reset i czasem wygenerowania tokena (więcej na ten temat poniżej). Gdy wiadomość e-mail zostanie wysłana, zawiera adres URL taki jak „Reset/?id=3ce7854015cd38c862cb9e14a1ae552b”, a gdy użytkownik ją pobierze, strona wyświetli monit o istnienie tokena, po czym potwierdzi dane użytkownika i umożliwi mu zmianę hasło.
Oczywiście, ponieważ powyższy proces (miejmy nadzieję) pozwala użytkownikowi na utworzenie nowego hasła, musimy upewnić się, że adres URL jest ładowany przez HTTPS. NIE, , ten adres URL tokenu musi korzystać z zabezpieczeń warstwy transportowej, aby nie można było zaatakować nowego formularza hasła a hasło utworzone przez użytkownika zostało przesłane bezpiecznym połączeniem.
Również w przypadku adresu URL resetowania należy dodać limit czasu tokena, aby proces resetowania mógł zostać zakończony w określonym przedziale czasu, powiedzmy w ciągu godziny. Dzięki temu okno czasowe resetowania jest ograniczone do minimum, dzięki czemu odbiorca resetowanego adresu URL może działać tylko w tym bardzo małym oknie. Oczywiście osoba atakująca może ponownie rozpocząć proces resetowania, ale będzie musiała uzyskać inny unikalny adres URL resetowania.
Wreszcie musimy zadbać o to, aby proces ten był jednorazowy. Po zakończeniu procesu resetowania token należy usunąć, aby resetowany adres URL przestał działać. Poprzedni punkt jest niezbędny, aby atakujący miał bardzo małe okno, w którym może manipulować resetowanym adresem URL. Dodatkowo, oczywiście, gdy reset się powiedzie, token nie będzie już potrzebny.
Niektóre z tych kroków mogą wydawać się zbyteczne, ale nie zakłócają użyteczności i w rzeczywistości poprawić bezpieczeństwo, choć w sytuacjach, które, mamy nadzieję, będą rzadkie. W 99% przypadków użytkownik umożliwi reset w bardzo krótkim czasie i nie będzie już w najbliższej przyszłości resetował hasła ponownie.
Rola CAPTCHA
Och, CAPTCHA, funkcja bezpieczeństwa, której wszyscy nienawidzimy! W rzeczywistości CAPTCHA jest nie tyle narzędziem ochrony, co narzędziem identyfikacji – niezależnie od tego, czy jesteś osobą, czy robotem (lub automatycznym skryptem). Ma to na celu uniknięcie automatycznego przesyłania formularzy, co oczywiście może być wykorzystane jako próba złamania zabezpieczeń. W kontekście resetowania hasła CAPTCHA oznacza, że funkcja resetowania nie może zostać brutalnie wymuszona w celu spamowania użytkownika lub próby ustalenia istnienia kont (co oczywiście nie będzie możliwe, jeśli zastosujesz się do porad z rozdziału o weryfikacja tożsamości).
Oczywiście samo CAPTCHA nie jest doskonałe; Istnieje wiele precedensów „hakowania” oprogramowania i osiągania wystarczających wskaźników sukcesu (60–70%). Dodatkowo istnieje rozwiązanie pokazane w moim poście na temat , gdzie możesz zapłacić ułamki centa za rozwiązanie każdego CAPTCHA i osiągnąć wskaźnik sukcesu na poziomie 94%. Oznacza to, że jest podatny na zagrożenia, ale (nieznacznie) podnosi barierę wejścia.
Rzućmy okiem na przykład PayPal:
W takim przypadku proces resetowania po prostu nie może się rozpocząć, dopóki CAPTCHA nie zostanie rozwiązany, tj teoretycznie nie da się zautomatyzować tego procesu. W teorii.
Jednak w przypadku większości aplikacji internetowych będzie to przesada i dokładnie tak oznacza spadek użyteczności - ludzie po prostu nie lubią CAPTCHA! Poza tym CAPTCHA to coś, do czego możesz łatwo wrócić w razie potrzeby. Jeśli usługa zaczyna być atakowana (w tym miejscu przydaje się logowanie, ale o tym później), dodanie CAPTCHA nie może być łatwiejsze.
Tajne pytania i odpowiedzi
Dzięki wszystkim rozważanym metodom udało nam się zresetować hasło, po prostu mając dostęp do konta e-mail. Mówię „tylko”, ale oczywiście uzyskiwanie dostępu do cudzego konta e-mail jest nielegalne. musi być złożonym procesem. Jednakże .
W rzeczywistości powyższy link dotyczący włamania do witryny Yahoo! Sarah Palin! służy dwóm celom; po pierwsze, ilustruje, jak łatwo można zhakować (niektóre) konta e-mail, a po drugie, pokazuje, jak złe pytania zabezpieczające mogą zostać wykorzystane w złośliwych zamiarach. Ale wrócimy do tego później.
Problem ze XNUMX% resetowaniem hasła za pomocą poczty e-mail polega na tym, że integralność konta witryny, którą próbujesz zresetować, zależy w XNUMX% od integralności konta e-mail. Każdy, kto ma dostęp do Twojej poczty e-mail ma dostęp do dowolnego konta, które można zresetować, po prostu otrzymując wiadomość e-mail. W przypadku takich kont e-mail jest „kluczem do wszystkich drzwi” Twojego życia online.
Jednym ze sposobów ograniczenia tego ryzyka jest wdrożenie wzorca pytań i odpowiedzi zabezpieczających. Bez wątpienia już je widziałeś: wybierz pytanie, na które tylko Ty możesz odpowiedzieć mieć znasz odpowiedź, a gdy zresetujesz hasło, zostaniesz o nie poproszony. Daje to pewność, że osoba próbująca zresetować jest rzeczywiście właścicielem konta.
Wracając do Sarah Palin: błąd polegał na tym, że można było łatwo znaleźć odpowiedzi na jej pytanie/pytania zabezpieczające. Zwłaszcza gdy jesteś tak znaczącą osobą publiczną, informacje o panieńskim nazwisku twojej matki, jej edukacji lub miejscu, w którym dana osoba mogła mieszkać w przeszłości, nie są aż tak tajne. Tak naprawdę większość z nich może znaleźć prawie każdy. Oto co przydarzyło się Sarah:
Haker David Kernell uzyskał dostęp do konta Palin, znajdując szczegółowe informacje na temat jej pochodzenia, takie jak uniwersytet i data urodzenia, a następnie korzystając z funkcji odzyskiwania zapomnianego hasła Yahoo!.
Przede wszystkim jest to błąd projektowy ze strony Yahoo! — zadając tak proste pytania, firma zasadniczo sabotowała wartość pytania bezpieczeństwa, a tym samym ochronę swojego systemu. Oczywiście resetowanie hasła do konta e-mail jest zawsze trudniejsze, ponieważ nie można udowodnić własności, wysyłając wiadomość e-mail do właściciela (bez posiadania drugiego adresu), ale na szczęście obecnie nie ma wielu zastosowań tworzenia takiego systemu.
Wróćmy do pytań zabezpieczających – istnieje możliwość umożliwienia użytkownikowi tworzenia własnych pytań. Problem w tym, że spowoduje to strasznie oczywiste pytania:
Jakiego koloru jest niebo?
Pytania, które sprawiają, że ludzie czują się niekomfortowo, gdy do identyfikacji używa się pytania zabezpieczającego ludzie (na przykład w call center):
Z kim spałem w Boże Narodzenie?
Albo szczerze głupie pytania:
Jak przeliterujesz „hasło”?
Jeśli chodzi o kwestie bezpieczeństwa, użytkownicy muszą być chronieni przed sobą! Innymi słowy, pytanie zabezpieczające powinno zostać określone przez samą witrynę lub, jeszcze lepiej, zadane seria pytania zabezpieczające, spośród których użytkownik może wybierać. A wybór nie jest łatwy jeden; w idealnym przypadku użytkownik powinien wybrać dwa lub więcej pytań zabezpieczających w momencie rejestracji konta, który będzie następnie używany jako drugi kanał identyfikacyjny. Posiadanie wielu pytań zwiększa pewność procesu weryfikacji, a także zapewnia możliwość dodania losowości (nie zawsze wyświetlanie tego samego pytania), a także zapewnia pewną redundancję w przypadku, gdy rzeczywisty użytkownik zapomni hasła.
Jakie jest dobre pytanie zabezpieczające? Wpływ na to ma kilka czynników:
- Powinno być krótki — pytanie musi być jasne i jednoznaczne.
- Odpowiedź musi brzmieć konkretny — nie potrzebujemy pytania, na które jedna osoba może odpowiedzieć inaczej
- Możliwe odpowiedzi powinny być różnorodny - pytanie o ulubiony kolor daje bardzo mały podzbiór możliwych odpowiedzi
- Wyszukiwanie odpowiedź musi być złożona – jeśli można ją łatwo znaleźć dowolny (pamiętajcie o ludziach na wysokich stanowiskach), to jest zły
- Odpowiedź musi brzmieć stały z czasem – jeśli zapytasz czyjś ulubiony film, to za rok odpowiedź może być inna
Tak się składa, że istnieje strona poświęcona zadawaniu dobrych pytań, tzw . Niektóre pytania wydają się całkiem dobre, inne nie przechodzą niektórych opisanych powyżej testów, zwłaszcza testu „łatwości wyszukiwania”.
Pozwólcie, że zademonstruję, jak PayPal implementuje pytania zabezpieczające, a w szczególności wysiłek, jaki witryna wkłada w uwierzytelnianie. Powyżej widzieliśmy stronę, na której można rozpocząć proces (z CAPTCHA), a tutaj pokażemy, co się stanie po wpisaniu adresu e-mail i rozwiązaniu CAPTCHA:
W rezultacie użytkownik otrzymuje następujący list:
Jak dotąd wszystko jest całkiem normalne, ale oto, co kryje się za tym resetowanym adresem URL:
W grę wchodzą więc kwestie bezpieczeństwa. W rzeczywistości PayPal umożliwia także zresetowanie hasła poprzez weryfikację numeru karty kredytowej, więc istnieje dodatkowy kanał, do którego wiele witryn nie ma dostępu. Po prostu nie mogę zmienić hasła bez odpowiedzi oba pytanie zabezpieczające (lub nieznajomość numeru karty). Nawet gdyby ktoś przejął moją pocztę e-mail, nie byłby w stanie zresetować hasła do mojego konta PayPal, chyba że znałby trochę więcej informacji osobistych na mój temat. Jaka informacja? Oto opcje pytań ochronnych oferowane przez PayPal:
Pytanie o szkołę i szpital może być nieco niepewne pod względem łatwości wyszukiwania, ale pozostałe nie są takie złe. Jednak w celu zwiększenia bezpieczeństwa PayPal wymaga dodatkowej identyfikacji zmiany odpowiedzi na pytania zabezpieczające:
PayPal to dość utopijny przykład bezpiecznego resetowania haseł: implementuje CAPTCHA, aby zmniejszyć niebezpieczeństwo ataków typu brute-force, wymaga dwóch pytań bezpieczeństwa, a następnie wymaga innego rodzaju zupełnie innej identyfikacji tylko po to, aby zmienić odpowiedzi – i to po tym, jak użytkownik już się zalogował. Oczywiście, właśnie o to nam chodzi spodziewany z PayPala; jest instytucją finansową, która zajmuje się dużymi sumami pieniędzy. Nie oznacza to, że przy każdym resetowaniu hasła należy wykonać poniższe kroki — w większości przypadków jest to przesada — ale jest to dobry przykład w przypadkach, gdy bezpieczeństwo to poważna sprawa.
Wygoda systemu pytań ochronnych polega na tym, że jeśli nie wdrożyłeś go od razu, możesz go dodać później, jeśli wymaga tego poziom ochrony zasobów. Dobrym tego przykładem jest Apple, które dopiero niedawno wdrożyło ten mechanizm [artykuł napisany w 2012 roku]. Kiedy zacząłem aktualizować aplikację na iPadzie, zobaczyłem następujące żądanie:
Następnie zobaczyłem ekran, na którym mogłem wybrać kilka par pytań i odpowiedzi zabezpieczających, a także ratunkowy adres e-mail:
Jeśli chodzi o PayPal, pytania są wstępnie wybrane i niektóre z nich są całkiem niezłe:
Każda z trzech par pytanie/odpowiedź reprezentuje inny zestaw możliwych pytań, więc sposobów konfiguracji konta jest mnóstwo.
Kolejnym aspektem, który należy wziąć pod uwagę przy udzielaniu odpowiedzi na pytanie ochronne, jest przechowywanie. Posiadanie w bazie danych bazy danych zawierającej zwykły tekst stwarza prawie takie same zagrożenia jak hasło, a mianowicie ujawnienie bazy danych natychmiast ujawnia wartość i naraża nie tylko aplikację na ryzyko, ale potencjalnie zupełnie inne aplikacje korzystające z tych samych pytań zabezpieczających (znowu ). Jedną z opcji jest bezpieczne mieszanie (silny algorytm i kryptograficznie losowa sól), ale w przeciwieństwie do większości przypadków przechowywania haseł może istnieć dobry powód, dla którego odpowiedź jest widoczna w postaci zwykłego tekstu. Typowym scenariuszem jest weryfikacja tożsamości przez operatora telefonicznego na żywo. Oczywiście hashowanie również ma zastosowanie w tym przypadku (operator może po prostu wpisać odpowiedź nazwaną przez klienta), ale w najgorszym przypadku tajna odpowiedź musi znajdować się na jakimś poziomie przechowywania kryptograficznego, nawet jeśli jest to tylko szyfrowanie symetryczne . Podsumować: traktuj sekrety jak sekrety!
Ostatnim aspektem pytań i odpowiedzi dotyczących bezpieczeństwa jest to, że są one bardziej podatne na inżynierię społeczną. Próba bezpośredniego wyciągnięcia hasła do cudzego konta to jedno, ale rozpoczęcie rozmowy na temat jego utworzenia (popularne pytanie zabezpieczające) to zupełnie co innego. W rzeczywistości możesz bardzo dobrze komunikować się z kimś na temat wielu aspektów jego życia, które mogą stanowić tajne pytanie bez wzbudzania podejrzeń. Oczywiście istotą pytania zabezpieczającego jest to, że odnosi się ono do czyjegoś doświadczenia życiowego, więc zapada w pamięć i na tym polega problem: ludzie uwielbiają rozmawiać o swoich doświadczeniach życiowych! Niewiele możesz z tym zrobić, jedynie jeśli wybierzesz takie opcje pytań ochronnych, że tak się stanie pomniejszy prawdopodobnie można by to wyciągnąć za pomocą inżynierii społecznej.
[Ciąg dalszy nastąpi.]O prawach reklamy
VDSina oferuje niezawodne , każdy serwer jest podłączony do kanału internetowego o przepustowości 500 Megabitów i jest chroniony przed atakami DDoS za darmo!
Źródło: www.habr.com