Uwierzytelnianie dwuskładnikowe
Wszystko, co przeczytałeś w dotyczy identyfikacji w oparciu o to, co zna osoba żądająca. Zna swój adres e-mail, wie, jak uzyskać do niego dostęp (tzn. zna swoje hasło do e-maila) i zna odpowiedzi na pytania zabezpieczające.
«Wiedza» jest uważana za jeden z czynników uwierzytelniania; dwa inne powszechne czynniki to to, co posiadasz, na przykład fizyczne urządzenie, oraz to, kim jesteś, na przykład odciski palców lub siatkówka oka.
W większości przypadków przeprowadzenie identyfikacji biologicznej jest mało wykonalne, szczególnie gdy mówimy o bezpieczeństwie aplikacji internetowych, dlatego podczas uwierzytelniania dwuskładnikowego (two factor authentication, 2FA) zazwyczaj używa się drugiego atrybutu — «to, co posiadasz». Jednym z popularnych wariantów tego drugiego czynnika jest fizyczny token, na przykład :
Fizyczny token jest często używany do uwierzytelniania w korporacyjnych VPN i usługach finansowych. Aby uwierzytelnić się w usłudze, należy użyć zarówno hasła, jak i kodu na tokenie (który często się zmienia) razem z PIN-em. Teoretycznie, aby się zidentyfikować, atakujący musi znać hasło, mieć token i znać PIN tokena. W scenariuszu resetowania hasła samo hasło jest oczywiście nieznane, jednak posiadanie tokena można wykorzystać do potwierdzenia własności konta. Oczywiście, jak w przypadku każdej realizacji ochrony, , ale z pewnością podnosi barierę wejścia.
Jednym z głównych problemów tego podejścia jest koszt i logistyka wdrożenia; mówimy o przekazaniu fizycznych urządzeń każdemu klientowi i szkoleniu ich w nowym procesie. Ponadto użytkownicy muszą mieć urządzenie przy sobie, co w przypadku fizycznego tokena nie zawsze jest możliwe. Inną opcją jest wdrożenie drugiego czynnika uwierzytelniania za pomocą SMS, które w przypadku 2FA może służyć jako potwierdzenie, że osoba przeprowadzająca proces resetowania ma telefon komórkowy właściciela konta. Oto jak robi to Google:
Należy także włączyć , ale oznacza to, że przy następnym resetowaniu hasła telefon komórkowy może stać się drugim czynnikiem uwierzytelniającym. Pozwól, że pokażę to na przykładzie mojego iPhone'a z powodów, które wkrótce się wyjaśnią:
Po zidentyfikowaniu adresu e-mail konta Google jest jasne, że włączono 2FA i możemy zresetować konto za pomocą weryfikacji wysyłanej przez SMS na telefon komórkowy właściciela konta:
Teraz musimy wybrać początek procesu resetowania:
To działanie prowadzi do wysłania e-maila na zarejestrowany adres:
Ten e-mail zawiera URL do resetowania:
Podczas korzystania z URL do resetowania wysyłany jest SMS, a strona internetowa prosi o jego wprowadzenie:
Oto ten SMS:
Po wpisaniu go w przeglądarkę wracamy na teren klasycznego resetowania hasła:
Możliwe, że wydaje się to nieco rozwlekłe i rzeczywiście tak jest, ale formularz potwierdza, że osoba dokonująca resetu ma dostęp do adresu e-mail oraz telefonu komórkowego właściciela konta. Może to być dziewięć razy bardziej bezpieczne niż resetowanie hasła tylko przez e-mail. Istnieją jednak problemy…
Problem dotyczy smartfonów. Pokazane poniżej urządzenie może potwierdzać tylko jeden czynnik uwierzytelniający – jest zdolne do odbierania SMS-ów, ale nie e-maili:
Jednak to urządzenie może odbierać SMS-y i otrzymywać e-maile o resetowaniu hasła:
Problem polega na tym, że traktujemy e-mail jako pierwszy czynnik uwierzytelniający, a SMS (lub nawet aplikację generującą tokeny) jako drugi, ale dzisiaj są one połączone w jednym urządzeniu. Oczywiście oznacza to, że jeśli ktoś dostanie się do twojego smartfona, to wszystkie te udogodnienia sprowadzą się do tego, że znowu wracamy do jednego kanału; ten drugi czynnik «to, co masz» oznacza, że masz też pierwszy czynnik. A wszystko to jest chronione jednym PIN-em składającym się z czterech cyfr… jeśli telefon w ogóle ma PIN i był zablokowany.
Tak, funkcja 2FA wprowadzona przez Google z pewnością zapewnia dodatkowe zabezpieczenia, ale nie chroni przed «głupcem» i zdecydowanie nie polega na dwóch całkowicie niezależnych kanałach.
Resetowanie na podstawie nazwy użytkownika kontra resetowanie na podstawie adresu e-mail
Czy należy zezwolić na resetowanie hasła tylko za pomocą adresu e-mail? Czy użytkownik powinien mieć możliwość zresetowania hasła także przy użyciu nazwy użytkownika? Problem z resetowaniem za pomocą nazwy użytkownika polega na tym, że nie ma sposobu, aby powiadomić użytkownika o niepoprawnej nazwie użytkownika, nie ujawniając tego, że ktoś inny może mieć konto o tej nazwie. W poprzedniej sekcji resetowanie za pomocą e-maila gwarantowało, że prawowity właściciel tego adresu e-mail zawsze dostanie informację zwrotną bez publicznego ujawniania jego istnienia w systemie. Używając tylko nazwy użytkownika, to nie jest możliwe.
Dlatego odpowiedź jest krótka: tylko e-mail. Jeśli spróbujesz przeprowadzić reset tylko przy użyciu nazwy użytkownika, będą się pojawiać sytuacje, w których użytkownik nie będzie miał pojęcia, co się wydarzyło, lub ujawnisz istnienie kont. Tak, to tylko nazwa użytkownika, a nie adres e-mail i tak, każdy może wybrać dowolną (dostępną) nazwę użytkownika, ale i tak istnieje duże prawdopodobieństwo, że pośrednio ujawnisz właścicieli kont z powodu tendencji użytkowników do wielokrotnego używania tej samej nazwy.
Co się więc dzieje, gdy ktoś zapomina swoją nazwę użytkownika? Zakładając, że nazwa użytkownika nie jest jednocześnie adresem e-mail (co się często zdarza), proces przypomina to, jak zaczyna się reset hasła — wpisujemy adres e-mail, a następnie wysyłamy wiadomość na ten adres, nie ujawniając jego istnienia. Jedyne różnice polegają na tym, że tym razem wiadomość zawiera tylko nazwę użytkownika, a nie link do resetowania hasła. Albo, w e-mailu będzie napisane, że dla tego adresu nie ma konta.
Weryfikacja tożsamości i dokładność adresów e-mail
Kluczowym aspektem resetowania haseł, a nawet prawdopodobnie najważniejszym aspektem jest weryfikacja tożsamości osoby, która próbuje przeprowadzić reset. Czy to naprawdę prawowity właściciel konta, czy ktoś próbuje je złamać lub sprawić właścicielowi kłopot?
Oczywiście, że e-mail jest najwygodniejszym i najpowszechniejszym kanałem weryfikacji tożsamości. Nie jest on odporny na nieumiejętne wykorzystanie („z głupoty”), a przypadków, w których sama możliwość odbierania wiadomości na adres właściciela konta jest niewystarczająca w przypadku potrzeby wysokiego stopnia pewności tożsamości (dlatego stosuje się 2FA), jest wiele. Jednak prawie zawsze jest on punktem wyjścia procesu resetowania.
Jeśli e-mail ma odgrywać rolę w zapewnieniu pewności, to przede wszystkim należy upewnić się, że adres e-mail jest rzeczywiście poprawny. Jeśli ktoś się pomylił w znaku, to oczywiście reset nie rozpocznie się. Proces weryfikacji e-maila w momencie rejestracji to niezawodny sposób na sprawdzenie poprawności adresu. Wszyscy widzieliśmy to w praktyce: rejestrujesz się, otrzymujesz e-mail z unikalnym URL-em, na który musisz kliknąć, co potwierdza, że rzeczywiście jesteś właścicielem tego konta e-mailowego. Niemożność zalogowania się do systemu przed zakończeniem tego procesu zapewnia motywację do potwierdzenia adresu.
Podobnie jak w przypadku wielu innych aspektów bezpieczeństwa, taki model obniża użyteczność w zamian za zapewnienie wyższego stopnia bezpieczeństwa w odniesieniu do pewności tożsamości użytkownika. Może to być akceptowalne dla strony, na której rejestracja jest wysoko ceniona przez użytkownika i z radością doda on jeszcze jeden etap do procesu (usługi płatne, bankowość itp.), ale takie rzeczy mogą zniechęcić użytkownika, jeśli postrzega on konto jako „jednorazowe” i używa go na przykład tylko do komentowania postów.
Identyfikacja tego, kto zainicjował proces resetowania.
Jest oczywiste, że istnieją powody do złośliwego wykorzystania funkcji resetowania, a cyberprzestępcy mogą wykorzystać ją na wiele różnych sposobów. Jednym z prostych trików, które możemy zastosować w celu potwierdzenia źródła żądania (ten sztuczny zwykle działa) — jest dodanie do e-maila z propozycją resetu adresu IP wnioskodawcy. To dostarcza odbiorcy pewnej informacji do identyfikacji źródła żądania.
Oto przykład z funkcji resetowania, którą aktualnie wdrażam w ASafaWeb:
Link „find out more“ („Dowiedz się więcej“) przenosi użytkownika na stronę internetową , podając takie informacje, jak lokalizacja i organizacja żądającego resetu:
Oczywiście, każdy, kto chce ukryć swoją tożsamość, ma wiele sposobów na zatarcie swojego prawdziwego adresu IP, jednak jest to wygodny sposób na dodanie częściowej identyfikacji żądającego, a w większości niektórych przypadkach daje to wystarczający wgląd w to, kto wykonuje żądanie resetu hasła.
Powiadomienie o zmianach za pośrednictwem e-maila
Ten post jest przesycony jedną tematyką — komunikacją; informuj właściciela konta jak najwięcej o tym, co dzieje się na każdym etapie procesu, nie ujawniając nic, co mogłoby zostać wykorzystane w złym celu. To samo dotyczy sytuacji, gdy hasło rzeczywiście zostało zmienione — poinformuj o tym właściciela!
Przyczynami zmiany hasła mogą być dwa źródła:
- Zmiana hasła po zalogowaniu, ponieważ użytkownik chce nowego hasła
- Reset hasła bez logowania, ponieważ użytkownik je zapomniał
Chociaż ten post głównie dotyczy resetu, powiadomienie w pierwszym przypadku zmniejsza ryzyko, że ktoś zmieni hasło bez wiedzy prawowitego właściciela. Jak to może się zdarzyć? Bardzo powszechnym scenariuszem jest uzyskanie hasła prawowitego właściciela (powtórnie używanego hasła, które wyciekło z innego źródła; hasła uzyskanego przez keylogging; łatwego do odgadnięcia hasła itd.), po czym przestępca postanawia je zmienić, blokując w ten sposób właściciela. Bez powiadomienia e-mailowego prawdziwy właściciel nie dowie się o zmianie hasła.
Oczywiście, w przypadku resetowania hasła właściciel powinien już sam zainicjować proces (lub ominąć opisane powyżej środki weryfikacji tożsamości), dlatego zmiana nie powinna być dla niego niespodzianką, jednak potwierdzenie e-mailem będzie pozytywną informacją zwrotną i dodatkową weryfikacją. Dodatkowo zapewnia to spójność z opisanym powyżej scenariuszem.
O, i na wypadek, gdyby to jeszcze nie było oczywiste — nie wysyłaj nowego hasła pocztą! Kogoś to może rozbawić, ale :
Logi, logi, logi i jeszcze trochę logów
Funkcja resetowania hasła jest atrakcyjna dla hakerów: napastnik chce uzyskać dostęp do konta innej osoby lub po prostu sprawić kłopot właścicielowi konta/systemu. Wiele z powyższych praktyk może zmniejszyć ryzyko nadużyć, ale ich nie zapobiega, i na pewno nie powstrzyma ludzi przed próbami wykorzystania funkcji w nieprzewidziany sposób.
Dla rozpoznawania złośliwego zachowania niezwykle cenną praktyką jest logowanie, a mam na myśli bardzo szczegółowe logowanie.Rejestruj nieudane próby logowania, resetu haseł, zmiany haseł (tj. gdy użytkownik już się zalogował) oraz praktycznie wszystko, co może pomóc ci w zrozumieniu, co się dzieje; to będzie bardzo przydatne w przyszłości. Rejestruj w logach nawet osobne elementy procesu, na przykład dobra funkcja resetowania powinna obejmować inicjowanie resetu przez stronę internetową (zarejestruj żądanie i nieudane próby logowania do resetu z niepoprawną nazwą użytkownika lub adresem e-mail), zarejestruj wizytę na stronie pod URL resetu (w tym próby użycia błędnego tokena), a następnie rejestruj w logach sukces lub błąd odpowiedzi na tajne pytanie.
Kiedy mówię o logowaniu, mam na myśli nie tylko zapis faktu załadowania strony, ale także zbieranie jak największej ilości informacji, jeśli nie są one poufne.Ludzie, proszę, nie zapisujcie haseł w logach! W logach należy rejestrować tożsamość autoryzowanego użytkownika (będzie autoryzowany, jeśli on zmienia istniejące hasło lub próbuje zresetować czyjeś hasło po zalogowaniu się), wszelkie próbowane nazwy użytkowników lub adresy e-mail oraz wszelkie tokeny resetu, które próbuje wykorzystać. Ale warto również rejestrować w logach takie aspekty, jak adresy IP, a jeśli to możliwe, nawet nagłówki żądań. To pozwoli ci odtworzyć nie tylko co użytkownik (lub napastnik) próbuje zrobić, ale i kto on jest.
Delegowanie odpowiedzialności innym wykonawcom.
Jeśli uważasz, że to wszystko stanowi ogromną pracę, to nie jesteś sam. W rzeczywistości zbudowanie niezawodnego systemu zarządzania kontami to niełatwe zadanie. Nie chodzi tylko o techniczne trudności, ale o wiele szczegółów. Obejmuje to nie tylko resetowanie, ale także cały proces rejestracji, bezpieczne przechowywanie haseł, obsługę wielu nieudanych prób logowania itp. , poza tym trzeba zrobić jeszcze wiele więcej.
Dzisiaj istnieje wiele zewnętrznych dostawców, którzy z radością biorą na siebie wszystkie trudy i upraszczają to wszystko w jeden zarządzany serwis. Wśród takich serwisów są OpenID, OAuth, a nawet Facebook. Niektórzy ludzie (OpenID okazał się bardzo skuteczny na Stack Overflow), jednak inni .
Bez wątpienia usługa taka jak OpenID rozwiązuje wiele problemów programistów, ale również bez wątpienia wprowadza nowe. Czy odgrywają jakąś rolę? Tak, ale oczywiście nie obserwujemy masowego korzystania z usług dostawców usług uwierzytelniania. Banki, linie lotnicze i nawet sklepy — wszyscy realizują własny mechanizm uwierzytelniania, co oczywiście ma bardzo poważne powody.
Złośliwy reset
Ważnym aspektem każdego z powyższych przykładów jest to, że stare hasło jest uważane za bezwartościowe dopiero po potwierdzeniu tożsamości właściciela konta. Jest to ważne, ponieważ gdyby konto można było zresetować do bez weryfikacji tożsamości, umożliwiłoby to wszelkiego rodzaju złośliwe działania.
Oto przykład: ktoś bierze udział w licytacji na stronie aukcyjnej i na koniec procesu licytacji blokuje konkurentów, inicjując proces resetowania, tym samym eliminując ich z licytacji. Oczywiście, jeśli źle zaprojektowana funkcja resetu mogłaby być niewłaściwie eksploatowana, mogłoby to prowadzić do poważnych negatywnych skutków. Warto zauważyć, że blokowanie kont poprzez nieudane próby logowania to podobna sytuacja, ale to już temat na inny post.
Jak wspomniałem wcześniej, umożliwienie anonimowym użytkownikom resetowania hasła do jakiegokolwiek konta, znając tylko jego adres e-mail, to gotowa sytuacja do przeprowadzenia ataku typu "odmowa usługi". To może nie być ten , o którym przywykliśmy mówić, ale nie ma szybszego sposobu na zablokowanie dostępu do konta niż przez źle zaprojektowaną funkcję resetowania hasła.
Najsłabsze ogniwo
Z perspektywy zabezpieczenia jednego konta wszystko, co napisano powyżej, jest wspaniałe, jednak zawsze należy pamiętać o ekosystemie otaczającym chronione konto. Pozwól, że podam przykład:
ASafaWeb jest hostowane na wspaniałej usłudze oferowanej przez AppHarbor. Proces resetowania konta hostingowego przebiega w następujący sposób:
Etap 1:
Etap 2:
Etap 3:
Etap 4:
Po przeczytaniu wszystkich powyższych informacji, łatwo zrozumieć, które aspekty w idealnym świecie mogliśmy by zrealizować nieco inaczej. Jednak chciałbym powiedzieć, że jeśli opublikuję stronę podobną do ASafaWeb w usłudze AppHarbor, a następnie wymyślę świetne pytania i odpowiedzi zabezpieczające, dodam drugi element uwierzytelniający i zrobię wszystko zgodnie z zasadami, to nie zmienia to faktu, że najsłabsze ogniwo całego procesu będzie w stanie to wszystko zniszczyć. Jeśli ktoś pomyślnie uwierzytelni się w AppHarbor, posługując się moimi danymi, to będzie mógł zmienić hasło do dowolnego konta ASafaWeb na takie, jakie zechce!
Chodzi o to, że odporność implementacji zabezpieczeń należy traktować całościowo: trzeba modelować zagrożenia dla każdego punktu wejścia do systemu, nawet jeśli to powierzchowny proces, jak logowanie się do AppHarbor. To powinno dać mi dobre wyobrażenie o tym, ile wysiłku muszę włożyć w proces resetowania hasła ASafaWeb.
Łącząc wszystko razem
Ten post zawiera dużą ilość informacji, dlatego chcę skupić go w prostej wizualnej schemacie:
Pamiętaj, że powinieneś rejestrować każdy z tych punktów w jak najbardziej szczegółowy sposób. I to wszystko, to proste!
Podsumowanie
Mój post wydaje się wszechstronny, jednak istnieje wiele dodatkowych materiałów, które mogłem by. mógłby włączyć go, ale postanowiłem zrezygnować z tego dla skrótu: rola adresu e-mail ratunkowego, sytuacja, w której tracisz dostęp do przypisanego do konta adresu e-mail (na przykład, gdy odchodzisz z pracy) i tak dalej. Jak już wcześniej powiedziałem, funkcja resetowania nie jest tak skomplikowana, ale istnieje wiele różnych punktów widzenia na nią.
Nawet mimo iż resetowanie nie jest tak trudne, często wdraża się je niewłaściwie. Wyżej widzieliśmy kilka przykładów, kiedy realizacja może prowadziła do problemów, a istnieje znacznie więcej precedensów, kiedy niewłaściwe resetowanie naprawdę spowodowało problemy. Niedawno odkryto, że . To poważny negatywny skutek!
Dlatego zachowaj ostrożność przy swoich funkcjach resetowania, w różnych punktach, a projektując funkcję, nie zdejmuj swojej czarnej kapelusza, ponieważ istnieje duża szansa, że ktoś inny ją założy!
Reklama
VDSina oferuje niedrogie z codzienną płatnością, każdy serwer jest podłączony do kanału internetowego o prędkości 500 Megabitów i bezpłatnie chroniony przed atakami DDoS!
Źródło: habr.com
