Samo hasło niekoniecznie jest weryfikowalne. W szczególności, jeśli serwer działa poprawnie, nie przechowuje samych haseł, ale dane wyjściowe funkcji mieszania haseł obliczone na podstawie hasła. Funkcja mieszania haseł (w przeciwieństwie do zwykłej funkcji skrótu) zawiera kilka dodatkowych funkcji, w tym sól (z bardzo dobrych powodów związanych z bezpieczeństwem). Weryfikacja hasła wymaga wtedy znajomości odpowiedniej soli. Ponieważ sól jest specyficzna dla instancji (chodzi o to, że różni użytkownicy mają swoje własne sole), wymagana jest tożsamość użytkownika (tożsamość użytkownika jest używana jako klucz indeksujący dla soli).

Po pierwsze, serwer nie wiedziałby, gdyby samo hasło pasowało do jakichkolwiek kont.

W bezpiecznym systemie hasła są zaszyfrowane, a następnie zaszyfrowane.

W uproszczonej wersji demonstracyjnej, przypuśćmy, że miałem trzech użytkowników:

  Nazwa użytkownika Hasłobob foobaralice foobarmaggie foobar  

Po ustawieniu tych haseł dodawana jest sól i generowany jest skrót:

  Nazwa Salt Wartość do mieszania hash resultbob ABCDEF ABCDEFfoobar 778f9aab91717e420e447d7e4cdd84f1alice 123456 123456foobar 17e9191daecc5b8be26779209769b275maggie ZXCVBN ZXCVBNfoobar 527cb07b112559cf9c1aff19d28074fa  

Jak widać, celem soli jest to, że nie ma dwóch haseł są przechowywane tak samo, nawet jeśli hasło może się zgadzać. Jest to ważny krok bezpieczeństwa, który należy podjąć, aby zapobiec używaniu tęczowych tablic na wyodrębnionej liście haseł.

Uniemożliwia to określenie, na które konto jest logowane na podstawie samego hasła, ponieważ sól do użycie nie jest znane. Dzieje się tak, ponieważ nazwa użytkownika jest używana jako klucz do wyszukiwania, a bez podania tego do serwera hasła wprowadzonego w kroku pierwszym nie można dopasować bez sprawdzania każdego skrótu w tabeli użytkowników, dopóki nie zostanie znalezione dopasowanie. W prawidłowo skonfigurowanym systemie byłoby to zbyt wolne, ponieważ używasz powolnego algorytmu (patrz przypis).

Ponadto byłby to ogromny wyciek informacji o bezpieczeństwie, gdyby system powiedział, że Twoje hasło jest używany przez inną osobę.

_{Powyższy przykład służy wyłącznie do celów ilustracyjnych i używa MD5. Nigdy nie używaj MD5 do haszowania haseł - użyj bcrypt, scrypt lub pbkdf2.}

Czy nie pytasz po prostu „Czy jest jakiś powód, dla którego nie mamy publicznych haseł i prywatnych nazw użytkowników?”

Oba są po prostu ciągami tekstowymi. Twój pomysł na wymuszanie unikalnych haseł polega tak naprawdę na tym, że nazwy użytkowników są niepowtarzalne. Etykieta, którą zastosujesz do pola tekstowego, nie ma znaczenia. Ciąg, który jest prywatny, nazywamy hasłem, a unikalny nazwą użytkownika lub identyfikatorem użytkownika, ponieważ jest unikalny.

Pod względem bezpieczeństwa i patrząc na to w normalnej kolejności Login / Hasło : Jeśli chcesz, aby oba były unikalne, otworzyłbyś atak na bazę danych, ponieważ każde sprawdzane hasło byłoby sprawdzane pod kątem każdego użytkownika w bazie danych ponieważ wymagałeś, aby Twoje hasła były unikalne . Więc jedno i drugie nie działa. Obie wartości nieunikatowe nie działają, ponieważ nie wiesz, do którego konta uzyskiwany jest dostęp. Pozostaje więc tylko jeden unikalny ciąg. Jeśli tworzysz pojedynczy unikalny ciąg tekstowy, równie dobrze możesz uczynić go publicznym fragmentem danych i najpierw to sprawdzić (i nazywamy te dane Login / ID / Nazwa użytkownika).

Wyobraźmy sobie analogię ...

Jestem posłańcem wysłanym przez mojego króla, aby dostarczyć wiadomość do pewnego zamku w Dolinie Zamków. Wiem, jak wygląda zamek, do którego chcę się udać, i otrzymałem hasło, aby powiedzieć strażnikowi, żebym mógł wejść do zamku.

Mam dwie możliwości, jak to zrobić:

1. Jak można się bez wątpienia spodziewać, konwencjonalnym sposobem na to jest pojechanie do zamku, do którego zostałem wysłany, a następnie podanie hasła dostępu. Najpierw jest to użycie moje informacje publiczne (zamek, widoczne dla każdego, kto chce go obejrzeć), aby zalogować się przy użyciu moich prywatnych informacji (hasła).

2. Ale jest odwrotny sposób, aby Zrób to. Mogę wziąć klakson i wykrzyczeć moje hasło po całej dolinie, aby publiczność mogła go słuchać. Ponieważ zamek, który zamierzam odwiedzić, usłyszał moje hasło (wraz ze wszystkimi innymi zamkami i potencjalnie nikczemnymi mieszkańcami doliny), zamek, który odwiedzam, powinien wiedzieć, że mnie oczekuje.

   Następnie kontynuuję konno do właściwego zamku i przejedź przez otwarty most zwodzony. Ale wpuściliby każdego przez ten otwarty most zwodzony! Teraz, gdy moje prywatne informacje zostały udostępnione światu, każdy może jeździć między zamkami i wejść do tego z otwartą bramą.

   Jeśli mnie tu nie ma, żeby krzyczeć to w róg, mieszkańcy doliny mogli stać na szczycie wzgórza z własnym rogiem, wykrzykując bełkot przez dolinę, aż usłyszą łoskot otwieranego mostu zwodzonego; wiedząc, że odgadli poprawnie hasło, muszą po prostu jeździć między zamkami, aż znajdą otwarte.

Pierwsza opcja jest taka, jak zwykle się to robi. Nie ma powodu, aby zmieniać tę konwencję. Alternatywa jest możliwa, ale udostępniając najpierw swoje prywatne informacje, znacznie ułatwiasz odgadnięcie hasła wszystkich naraz przed uwierzytelnieniem za pomocą informacji publicznych, tj. Jazdy do każdego zamku lub wypróbowania wszystkich publicznie nazwy kont. Przy tysiącach zamków w tej dolinie lub kontach na stronie internetowej jest całkiem prawdopodobne, że ktoś odgadnie łatwe hasło, a wtedy o wiele łatwiej będzie po prostu dopasować je do jednego z kilku tysięcy zamków lub nazw kont publicznych.

Firma Google nie wymaga podania adresu e-mail w pierwszej kolejności ze względów bezpieczeństwa. Musisz wpisać swój adres e-mail / nazwę użytkownika, więc jeśli logujesz się do domeny służbowej lub edukacyjnej, która chce mieć własną stronę docelową dla logowania jednokrotnego / SAML

Jeśli najpierw poprosisz o hasło, musisz w pewnym stanie zachować wartość „sekret”, czekając na nazwę użytkownika. W przypadku aplikacji internetowej zazwyczaj trzeba w jakiś sposób zrobić to miejsce, aby nowy proces mógł odczytać wartość, ponieważ nazwa użytkownika pojawiłaby się przy drugim żądaniu. Zwiększa to szansę na ujawnienie ciągu hasła, zarówno pod względem czasu, jak i sposobów dostępu do danych.

Pytając najpierw o nazwę użytkownika, weryfikacja hasła za pomocą zasolonego haszowania (lub nie) może już mieć dostęp do wszystkiego, co jest niezbędne do natychmiastowej weryfikacji hasła, a system musi mieć dostęp do samego hasła tylko przez minimalny czas. Generalnie najlepiej jest mieć dostęp do poufnych danych przez jak najkrótszy czas.

I taka jest konwencja. Pytając najpierw o hasło, w końcu przeszkolisz użytkowników, jak przypadkowo wpisują swoje hasło w polach nazwy użytkownika w innym miejscu, co prawdopodobnie skutkuje ujawnieniem ich w dziennikach.

Nie rób tego. :)

Aby dodać; o mechanizmie identyfikacji vs uwierzytelniania / weryfikacji decyduje się podczas tworzenia aplikacji. Identyfikacja to 1: wiele , weryfikacja / uwierzytelnienie to 1: 1

  1: 1 - dopasowanie do jednego wstępnie wybranego zestawu wyników; 1: wiele - pasuje do wszystkich wyników w bazie danych  

Nazwy użytkowników, takie jak Gmail, są unikalne. Nie jest to obowiązkowe dla wszystkich aplikacji, ale z pewnością ułatwia życie algorytmowi weryfikacji w przeciwieństwie do algorytmu identyfikacji.

Weź pod uwagę popularną nazwę użytkownika, a następnie hasło uwierzytelniania dla Gmaila:

1. wprowadź nazwę użytkownika;

   gmail dopasowuje unikalną nazwę użytkownika do wszystkich innych unikalnych nazw użytkowników; Tak, dopasuj, wprowadź hasło; Brak dopasowania, brak dostępu.

2. Wpisz hasło.

   Gmail dopasowuje po prostu 1 nazwę użytkownika do 1 hasła przechowywanego w dowolnym formacie; Brak dopasowania, uwierzytelnianie nie powiodło się. Tak, dopasuj, uzyskaj dostęp do swojej poczty.

Całkiem proste IMHO.

Po drugiej stronie, identyfikacja (1: wiele), proces dopasowywania z gmail wyglądałoby tak:

1. wprowadź hasło; i jak jasno wskazał @SilverlightFox, wiele kont może mieć to samo hasło.

     algorytm dopasowania dopasowuje hasło do WSZYSTKICH nazw użytkowników zarejestrowanych w bazie danych Gmaila.  

   Zbyt konserwatywny zestaw wyników może zawierać 10 nazw użytkowników.

2. Wpisz nazwę użytkownika;

To, czy nazwy użytkowników są unikalne, czy mogą być takie same, zadecyduje o dłuższym czasie procesu uwierzytelniania i liczbie znalezionych dopasowań. Jeśli pasuje więcej niż 1, będziemy musieli wdrożyć 3-etapowe uwierzytelnianie logowania.

Dwuetapowe uwierzytelnianie ułatwia życie programistom i algorytmowi.

W przypadku Google i większości konfiguracji podzielonego uwierzytelniania, system zasadniczo używa identyfikatora użytkownika do zidentyfikowania związanego z nim ryzyka i określenia odpowiedniego procesu logowania, który powinien przeprowadzić dla użytkownika.

W przypadku W większości tych sytuacji identyfikator użytkownika wprowadzony przez osobę jest tylko jednym z rozważanych danych wejściowych. Wraz z nim wiele innych informacji (np. Adres IP, z którego uzyskujesz dostęp, urządzenie, z którego korzysta użytkownik - jest generowany i przekazywany podpis urządzenia wraz z identyfikatorem użytkownika) jest przekazywanych do silnika określania ryzyka (w większości banków ale nie zawsze mogą być używane), co może sugerować proces logowania. Oprócz tego system sprawdza politykę logowania powiązaną z użytkownikiem (tj. Czy ma na przykład włączoną wieloskładnikową). Opierając się na ostatecznym ustaleniu, w większości przypadków możesz otrzymać prosty ekran hasła, ale w niektórych przypadkach możesz zostać poproszony o przejście do wielu procesów uwierzytelniania (np. OTP przez telefon itp.).