Jaka jest różnica między uwierzytelnieniem podstawowym a podstawowym?


Odpowiedzi:


196

Uwierzytelnianie szyfrowane komunikuje poświadczenia w postaci zaszyfrowanej poprzez zastosowanie funkcji skrótu do: nazwy użytkownika, hasła, wartości nonce podanej przez serwer, metody HTTP i żądanego identyfikatora URI.

Podczas gdy uwierzytelnianie podstawowe wykorzystuje niezaszyfrowane kodowanie base64.

Dlatego podstawowego uwierzytelnienia należy zasadniczo używać tylko wtedy, gdy zapewnione jest bezpieczeństwo warstwy transportowej, takie jak https.

Zobacz RFC-2617, aby poznać wszystkie krwawe szczegóły.


1
jak podstawowe uwierzytelnianie nie jest szyfrowane? użyłem tej strony do zdekodowania nazwy użytkownika i hasła base64decode.org
Dot Freelancer

65
Kodowanie i szyfrowanie to nie to samo. Fakt, że możesz dekodować dane uwierzytelniające przy użyciu tej witryny, pokazuje, że nie są one szyfrowane.
Andy,

@Andy Czy istnieje różnica między uwierzytelnianiem szyfrowanym a uwierzytelnianiem kryptograficznym? A może odnoszą się do tego samego? Dzięki.
user224567893

1
@Andy, co rozumiesz przez „dekodowanie poświadczeń”? Zaszyfrowanych danych uwierzytelniających nie można odkodować ...
Alexander Suraphel

8
Zgadza się, a podstawowe uwierzytelnianie nie używa skrótów, są one zakodowane w standardzie base64.
Andy

112

Uwierzytelnianie dostępu podstawowego HTTP

  • KROK 1 : klient żąda informacji, wysyłając nazwę użytkownika i hasło do serwera w postaci zwykłego tekstu
  • KROK 2 : serwer odpowiada żądaną informacją lub błędem

Uwierzytelnianie podstawowe wykorzystuje kodowanie base64 (nie szyfrowanie) do generowania naszego ciągu kryptograficznego, który zawiera informacje o nazwie użytkownika i haśle. HTTP Basic nie musi być implementowany przez SSL, ale jeśli nie, to wcale nie jest bezpieczny. Więc nawet nie zamierzam bawić się bez tego.

Plusy:

  • Jest prosty do wdrożenia, więc programiści klienta będą mieli mniej pracy do wykonania i zajmą mniej czasu, więc programiści mogą chcieć korzystać z interfejsu API
  • W przeciwieństwie do Digest, możesz przechowywać hasła na serwerze dowolną metodą szyfrowania, taką jak bcrypt, dzięki czemu hasła są bezpieczniejsze
  • Potrzebne jest tylko jedno połączenie z serwerem, aby uzyskać informacje, dzięki czemu klient jest nieco szybszy niż bardziej złożone metody uwierzytelniania

Cons:

  • SSL działa wolniej niż podstawowy HTTP, więc powoduje to nieco wolniejszą pracę klientów
  • Jeśli nie masz kontroli nad klientami i nie możesz zmusić serwera do korzystania z protokołu SSL, programista może nie używać protokołu SSL, powodując zagrożenie bezpieczeństwa

Podsumowując - jeśli masz kontrolę nad klientami lub możesz upewnić się, że używają protokołu SSL, HTTP Basic jest dobrym wyborem. Powolność protokołu SSL można anulować przez szybkość wysłania tylko jednego żądania

Składnia podstawowego uwierzytelnienia

Value = username:password
Encoded Value =  base64(Value)
Authorization Value = Basic <Encoded Value> 
//at last Authorization key/value map added to http header as follows
Authorization: <Authorization Value>

Uwierzytelnianie dostępu Digest HTTP Uwierzytelnianie dostępu
Digest wykorzystuje metody mieszania (tj. Skrót oznacza cięcie na małe kawałki) w celu wygenerowania wyniku kryptograficznego. Uwierzytelnianie dostępu HTTP Digest jest bardziej złożoną formą uwierzytelniania, która działa w następujący sposób:

  • KROK 1 : klient wysyła żądanie do serwera
  • KROK 2 : serwer odpowiada specjalnym kodem (zwanym atzn. n umber użyty tylko raz ), kolejny ciąg reprezentujący sferę (skrót) i prosi klienta o uwierzytelnienie
  • KROK 3 : klient odpowiada tym numerem i zaszyfrowaną wersją nazwy użytkownika, hasła i dziedziny (skrótu)
  • KROK 4 : serwer odpowiada żądanymi informacjami, jeśli skrót klienta pasuje do własnego skrótu nazwy użytkownika, hasła i dziedziny lub błąd, jeśli nie

Plusy:

  • Żadne nazwy użytkownika ani hasła nie są wysyłane do serwera w postaci zwykłego tekstu, dzięki czemu połączenie bez protokołu SSL jest bezpieczniejsze niż żądanie HTTP Basic, które nie jest wysyłane za pośrednictwem protokołu SSL. Oznacza to, że protokół SSL nie jest wymagany, co sprawia, że ​​każde połączenie jest nieco szybsze

Cons:

  • Dla każdego potrzebnego połączenia klient musi wykonać 2, co czyni proces nieco wolniejszym niż HTTP Basic
  • HTTP Digest jest podatny na atak bezpieczeństwa typu man-in-the-middle, co w zasadzie oznacza, że ​​można go zhakować
  • HTTP Digest zapobiega użyciu silnego szyfrowania haseł, co oznacza, że ​​hasła przechowywane na serwerze mogą zostać zhakowane

Podsumowując , HTTP Digest jest z natury podatny na co najmniej dwa ataki, podczas gdy serwer używający silnego szyfrowania haseł z HTTP Basic przez SSL ma mniejsze szanse na udostępnienie tych luk.

Jeśli nie masz kontroli nad klientami, mogą oni jednak spróbować przeprowadzić uwierzytelnianie podstawowe bez SSL, co jest znacznie mniej bezpieczne niż Digest.

RFC 2069 Składnia uwierzytelnienia dostępu szyfrowanego

Hash1=MD5(username:realm:password)
Hash2=MD5(method:digestURI)
response=MD5(Hash1:nonce:Hash2)

RFC 2617 Składnia uwierzytelnienia dostępu szyfrowanego

Hash1=MD5(username:realm:password)
Hash2=MD5(method:digestURI)
response=MD5(Hash1:nonce:nonceCount:cnonce:qop:Hash2)
//some additional parameters added 

źródło i przykład

W Postman wygląda następująco:

wprowadź opis zdjęcia tutaj

Uwaga:

  • Te systemy podstawowe i trawienia są przeznaczone do uwierzytelniania przy użyciu nazwy użytkownika i tajemnicy.
  • Schemat okaziciela jest dedykowany do uwierzytelniania przy użyciu tokena.

1
Czy na swoim serwerze internetowym możesz nie tylko przekierowywać do https dla wszystkich żądań HTTP, nawet jeśli nie masz kontroli nad klientami?
10cool

Im więcej o tym myślę, tym bardziej rozumiem twój punkt widzenia. Zakładając, że podadzą tam poświadczenia za pośrednictwem http i przejdą na twoją stronę, możesz przekierować, ale jeśli trafią na złośliwą stronę, nie możesz pomóc.
10cool

3
Dlaczego dzięki Digest nie możesz zaszyfrować hasła przed zapisaniem go w bazie danych, a po jego wyciągnięciu odszyfrować?
papiro

Chociaż wybrana odpowiedź jest bliższa pytaniu, podoba mi się ta odpowiedź, ponieważ daje wady i zalety dla nas niewtajemniczonych.
coder0h1t

1
@ 10cool po wejściu na stronę za pomocą http, jest już za późno ... niestety. użytkownik: przepustka została już wysłana w trybie jawnym, nawet jeśli zaraz zostaniesz przekierowany do httpS.
Julien

41

Zobaczmy różnicę między dwoma uwierzytelnieniami HTTP za pomocą Wireshark(Narzędzie do analizy pakietów wysłanych lub odebranych).

1. Podstawowe uwierzytelnianie HTTP

Podstawowy

Gdy tylko klient wpisze prawidłową nazwę użytkownika: hasło , zgodnie z żądaniem serwera WWW, serwer internetowy sprawdza w Bazie danych, czy poświadczenia są poprawne, i zapewnia dostęp do zasobu.

Oto, w jaki sposób pakiety są wysyłane i odbierane:

wprowadź opis zdjęcia tutaj W pierwszym pakiecie klient wypełnia dane uwierzytelniające za pomocą metody POST w zasobie -. lab/webapp/basicauthW zamian serwer odpowiada z powrotem kodem odpowiedzi HTTP 200 ok , tj. Nazwa użytkownika: hasło były poprawne.

Szczegóły pakietu HTTP

Teraz w Authorizationnagłówku pokazuje, że jest to Podstawowa autoryzacja, po której następuje jakiś losowy ciąg. Ten ciąg jest zakodowaną (Base64) wersją poświadczeń admin:aadd(w tym dwukropka).

2) Http Digest Authentication (rfc 2069)

Do tej pory widzieliśmy, że Podstawowe uwierzytelnianie wysyła nazwę użytkownika: hasło w postaci zwykłego tekstu przez sieć. Ale Digest Auth wysyła HASH hasła przy użyciu algorytmu Hash.

Oto pakiety pokazujące żądania wykonane przez klienta i odpowiedzi z serwera.

strawić

Gdy tylko klient wpisze poświadczenia wymagane przez serwer, hasło jest konwertowane na responsealgorytm, a następnie wysyłane do serwera. Jeśli baza danych serwera ma taką samą odpowiedź, jak klient, serwer daje dostęp do zasobu , w przeciwnym razie a błąd 401 .

Szczegółowy pakiet uwierzytelniający W powyższym AuthorizationThe responseciąg jest obliczana na podstawie wartości Username, Realm, Password, http-method,URI i Nonce, jak pokazano na rysunku:

Algorytm odpowiedzi (dwukropki są wliczone)

W związku z tym możemy zobaczyć, że uwierzytelnianie szyfrowane jest bezpieczniejsze, ponieważ obejmuje Hashing (szyfrowanie MD5), więc narzędzia do wykrywania pakietów nie mogą wykryć Hasła, chociaż w Autoryzacji podstawowej dokładne hasło zostało pokazane w Wireshark.


6
To powinna być zaakceptowana odpowiedź, ponieważ jest bardziej pouczająca i docenia wykresy.
mak

Ale w Wireshark wąchasz tylko pakiety przy użyciu protokołu HTTP? Co jeśli korzystasz z protokołu https?
JohnRDOrazio

Wireshark nie decyduje, czy powąchać HTTP czy HTTP. Jest to serwer WWW skonfigurowany z protokołami.
BoRRis,

1
Nonsens. Autoryzacja podstawowa jest przeznaczona tylko do użycia przez HTTPS. Tak więc prawdziwe porównanie to Autoryzacja podstawowa przez HTTPS i Autoryzacja szyfrowana przez HTTP. Ponieważ strony internetowe szyfrują obecnie cały ich ruch, równie dobrze możesz użyć uwierzytelniania podstawowego przez HTTPS.
Gili

-3

Uwierzytelnianie podstawowe wykorzystuje kodowanie podstawowe 64 do generowania ciągu kryptograficznego zawierającego informacje o nazwie użytkownika i haśle.

Uwierzytelnianie dostępu Digest korzysta z metodologii mieszania w celu wygenerowania wyniku kryptograficznego


1
kodowanie podstawowe 64 nie jest kryptograficzne.
Thomas Sobieck,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.