Co to jest uwierzytelnianie za pomocą skrótu?

101

Czym różni się uwierzytelnianie szyfrowane od uwierzytelniania podstawowego innego niż wysyłanie poświadczeń w postaci zwykłego tekstu?

digest-authentication

— SoftwareGeek
źródło

Świetne wyjaśnienie od @Gumbo tutaj: stackoverflow.com/a/5288679/591487

— inorganik

Coś, czego NIGDY nie powinieneś używać. Nie chroni hasła podczas przesyłania i wymaga od serwera przechowywania zwykłych haseł.

— CodesInChaos

Digest zapewnia lepsze bezpieczeństwo podczas przesyłania niż uwierzytelnianie podstawowe dla ruchu niezaszyfrowanego , ale jest słabe. ZNACZNIE bezpieczniej jest zamiast tego używać uwierzytelniania podstawowego w połączeniu z SSL / TLS, ponieważ w ten sposób można również przechowywać hasła na serwerze w postaci zaszyfrowanej.

— rustyx

Odpowiedzi:

179

Główną różnicą jest to, że nie wymaga przesyłania nazwy użytkownika i hasła przez sieć w postaci zwykłego tekstu. Jest również odporny na ataki typu replay, ponieważ wykorzystuje jednorazowy numer z serwera.

Serwer nadaje klientowi jednorazowy numer (numer jednorazowy), który łączy z nazwą użytkownika, dziedziną, hasłem i żądaniem URI. Klient uruchamia wszystkie te pola za pomocą metody mieszania MD5, aby utworzyć klucz skrótu.

Wysyła ten klucz skrótu do serwera wraz z nazwą użytkownika i domeną w celu próby uwierzytelnienia.

Po stronie serwera ta sama metoda jest używana do generowania klucza mieszającego, tylko zamiast używać hasła wpisanego w przeglądarce, serwer wyszukuje oczekiwane hasło użytkownika z jego bazy danych użytkownika. Wyszukuje zapisane hasło dla tej nazwy użytkownika, przechodzi przez ten sam algorytm i porównuje je z tym, co przesłał klient. Jeśli są zgodne, dostęp jest przyznawany, w przeciwnym razie może odesłać 401 Unauthorized (brak logowania lub nieudane logowanie) lub 403 Forbidden (odmowa dostępu).

Uwierzytelnianie szyfrowane jest znormalizowane w dokumencie RFC2617 . W Wikipedii jest ładny przegląd :

Możesz o tym myśleć w ten sposób:

Klient zgłasza żądanie
Klient odzyskuje nonce z serwera i żądanie uwierzytelnienia 401
Klient odsyła następującą tablicę odpowiedzi (nazwa użytkownika, dziedzina, generacja_md5_key (nonce, nazwa użytkownika, dziedzina, URI, hasło_given_by_user_to_browser)) (tak, to jest bardzo uproszczone)
Serwer pobiera nazwę użytkownika i dziedzinę (dodatkowo zna identyfikator URI, którego żąda klient) i wyszukuje hasło dla tej nazwy użytkownika. Następnie przechodzi i wykonuje własną wersję generatora kluczy (nonce, nazwa użytkownika, dziedzina, URI, hasło_I_have_for_this_user_in_my_db)
Porównuje dane wyjściowe wygenerowane przez generowanie_md5 () z tym, które wysłał klient, jeśli pasują one do klienta, który przesłał prawidłowe hasło. Jeśli nie pasują do wysłanego hasła, było nieprawidłowe.

— Ian C.
źródło

Niezłe wyjaśnienie. Czy nazwa użytkownika i pwd są dla użytkownika systemu Windows? Skąd są generowane?

— SoftwareGeek

Są to, co użytkownik wpisze w przeglądarce. Hasło musi być zgodne z tym, co serwer zapisał dla hasła tego użytkownika. Bardziej prawdopodobne jest, że jest to coś specyficznego dla tej aplikacji internetowej, a nie hasło do systemu Windows. W dużej mierze zależy to od sposobu złożenia aplikacji internetowej.

— Ian C.

Ta odpowiedź ma 6 lat, ale wydaje mi się, że wszystkie systemy świadome bezpieczeństwa przechowują już hasła w formacie zasolonego skrótu. Nie ma i nie powinno być żadnej metody uzyskania oryginalnego hasła z bazy danych, która uniemożliwia autoryzację skrótu.

— Ramon de Klein

Jeśli skrót skrótu nazwy użytkownika i hasła jest przechowywany w bazie danych zamiast zwykłych haseł, nadal można użyć skrótu auth @RamondeKlein

— karakays

@BlueBockser Myślę, że karakays oznaczało, że zamiast używania zwykłego hasła, hash wynikający z połączenia zarówno nazwy użytkownika, jak i jego hasła powinien być przechowywany na serwerze podczas rejestracji i obliczany po stronie klienta przed uwierzytelnieniem. Można to również zrobić za pomocą skrótu hasła.

— logo_writer

Skrót poświadczeń jest przesyłany przez sieć.

HA1 = MD5(username:realm:password)

Wikipedia ma świetny artykuł na ten temat

— Philip Fourie
źródło

od klienta do serwera? Czy mógłbyś podać kroki dotyczące interakcji? Artykuł w Wikipedii jest dobry, ale potrzebuję lepszego wyjaśnienia lub przykładu.

— SoftwareGeek

Tak, klient generuje wartość skrótu i wysyła ją na serwer. Artykuł w Wikipedii szczegółowo opisuje protokół, sugeruję odwołanie się do niego, aby uzyskać więcej informacji.

— Philip Fourie

Jedynym sposobem uzyskania skrótu HA1 poświadczeń jest znajomość hasła. Serwer zna HA1, ale nie zna hasła, które go wygenerowało. Jeśli HA1 był znany atakującemu, mógłby dostać się do systemu. Więc nie jest wysyłany w dół. Kolejny hash oparty na liczbach jednorazowych itp. Jest wykonywany przed wykonaniem tej czynności i musi być zgodny z podobnymi obliczeniami wykonanymi na serwerze. Tak więc, dopóki serwer utrzymuje prywatność HA1, system jest bezpieczny.

— Chris Oakley
źródło

To jest wyjaśnienie dotyczące uwierzytelniania Digest, w którym hasło nie jest wysyłane w postaci zwykłego tekstu (tak jest w przypadku uwierzytelniania podstawowego)

— Erik Oppedijk