Maciej Wierzchowski Mariusz Sołtysiak. Założenia  Autentykacja użytkownia  Autentykacja dostawcy  Zapewnienie bezpiecznego połączenia.

Prezentacja na temat: "Maciej Wierzchowski Mariusz Sołtysiak. Założenia  Autentykacja użytkownia  Autentykacja dostawcy  Zapewnienie bezpiecznego połączenia."— Zapis prezentacji:

1 Maciej Wierzchowski Mariusz Sołtysiak

2 Założenia  Autentykacja użytkownia  Autentykacja dostawcy  Zapewnienie bezpiecznego połączenia

3 Rodzaje  Plain text Bez szyfrowania Szyfrowanie w trakcie autentykacji Całkowite szyfrowanie połączenia  HMAC  DIGEST  NTML  Open ID

4 Plain Text Bez szyfrowania Klient Rządanie zasobu 401 Unauthorized Nazwa użytkownika i hasło Rządany zasób Źródło: Opracowanie własne.

5 Plain Text Bez szyfrowania  Nazwa użytkownika i hasło enkodowane do Basic64 w postaci: Użytkownik:Hasło  Nie zapewnia żadnego bezpieczeństwa  Łatwo przechwycić nazwę użytkownika i hasło

6 Plain Text Szyfrowanie w trakcie autentykacji  Połączenie szyfrowane tylko w trakcie autentykacji  Po udanej autentykacji użytkownik dostaje swój identyfikator sesji.  Nazwa użytkownika i hasło są bezpieczne, jednak łatwo przechwycić sesje.

7 Plain text Połączenie szyfrowane  Cała komunikacja pomiędzy serwerem a klientem jest szyfrowana.  Wysokie bezpieczeństwo, jednak jak każde inne- nie daje 100% bezpieczeństwa. (np. Man in the middle)

8 HMAC Zasada działania Źródło: http://www.networkworld.com/subnets/cisco/102208-ch2-ssl-vpn-technology.html

9 HMAC  Zapewnia integralność i autentyczność wiadomości  W niektórych środowiskach bywa trudna w implementacji

10 DIGEST Autoryzacja Digest  Sposób autoryzacji działający w oparciu o mechanizm challenge/respons  Wzmocniona wersja uwierzytelniania podstawowego  Stosowana przez serwery sieci Web do uwierzytelniania przy dostępie do stron  Wykorzystywane przez min. Internet Information Services (IIS) na platformach Microsoft Windows Server, open source Apache Web Server, serwer WWW, Jigsaw opracowane przez W3C i innych platformach

11 DIGEST  Podstawowe elementy uwierzytelnienia digest Nazwa użytkownika Nazwa obszaru np. ‘Administrative Area’ Skrót MD5 nazwy użytkownika, hasła, oddzielonych dwukropkami  Przykład: someUser:Some Realm:fde17b91c3a510ecbaf7db d37f59d4f8

12 DIGEST Schemat autoryzacji DIGEST Źródło: http://www.cgisecurity.com/owasp/html/ch06.html

13 NTML Pakiet uwierzytelnienia NTLM (NT LAN Manager) dostarczany z Microsoft Windows zawiera implementacje trzech protokołów uwierzytelnienia:  LAN Manager, oraz jego wersje rozwojowe  NT LAN Manager v1 (Windows NT 4.0),  NT LAN Manager v2 (Windows NT 4.0 SP4).

14 NTML Kiedy klient próbuje uzyskać dostęp do zasobu umieszczonego na serwerze:  serwer wysyła do klienta losowy ciąg oktetów – challenge.  Klient (przeglądarka) w oparciu o challenge tworzy odpowiedź do serwera poprzez wyliczenie skrótu od challenge połączonego z hasłem, który jest przesyłany do serwera.  Po stronie serwera wykonywana jest dokładnie ta sama operacja.  Jeśli wynikowy ciąg znaków odpowiada zawartości komunikatu przesłanego przez klienta, tożsamość klienta jest pozytywnie zweryfikowana.

15 NTML Jak wygląda autoryzacja z wykorzystaniem NTLM  Nawiązanie połączenia HTTP serwer klient (ważne: w trybie keep-alive)  Przeglądarka IE prosi o zasób HTTP, przedstawiając przy tym swoją wersję w nagłówku User-Agent  Serwer WWW rozpoznaje przeglądarkę IE i informuje ją, że do obejrzenia zasobu potrzebne jest uwierzytelnianie NTLM lub Basic  IE wysyła do serwera komunikat inicjujący uwierzytelnianie oraz negocjujący właściwości połączenia (wiadomość typu 1)

16 NTML  Serwer odsyła wiadomość w której znajduje się challenge code oraz wynegocjowane opcje połączenia (wiadomość typu 2)  IE odsyła ostatnią wiadomość uwierzytelniającą, zawiera ona w sobie dane logowania, takie jak login, nazwę stacji roboczej, nazwę domeny oraz skrót hasła wygenerowanego przy pomocy challenge code otrzymanego w poprzedniej wiadomości (jest to wiadomość typu 3)  Po zweryfikowaniu danych serwer zwraca zawartość zasobu HTTP

17 NTML  Schemat Autoryzacji NTLM

18 NTML Ważną informacją jest też to, że ani serwer WWW, ani przeglądarka klienta, nie sprawdzają w żaden sposób, czy nie padły ofiarą ataku Man-in-the-middle. Za:  Może zostać użyte z połączeniu z Kerberos, dzięki czemu istnieje możliwość delegowania poświadczeń bezpieczeństwa;  Najlepszy mechanizm dla aplikacji działających w środowisku Intranetowym; Przeciw:  Nie obsługuje poświadczenia zintegrowanego systemu Windows dla zewnętrznych źródeł danych.

19 Open ID  W momencie logowania do pożądanego serwisu użytkownik podaje identyfikator OpenID, który ma postać adresu URL będącego równocześnie adresem serwera OpenID i wskazaniem konkretnego użytkownika (np. user.openid.pl albo http://openid.pl/user/).URL  Serwis przekierowuje użytkownika na stronę serwera OpenID z żądaniem określonych danych użytkownika. Serwer OpenID udostępnia je przez przekierowanie z powrotem do serwisu, który ich zażądał. Udostępnienie danych wymaga zwykle interakcji użytkownika, by udostępnić tylko te dane, na których udostępnienie godzi się użytkownik i tylko temu serwisowi, który użytkownik akceptuje. Użytkownik dokonuje więc logowania i wyboru zakresu danych. Możliwe jest też ustalenie, że pewne dane będą udostępniane serwisowi bez konieczności każdorazowego logowania np. przez pewien czas. Udostępniane dane mogą być użyte np. do podpisywania komentarzy użytkownika na forach dyskusyjnych czy w blogach.  W wersji 2.0 protokołu OpenID identyfikatorem użytkownika może być także XRI.XRI

20 Open ID Źródło: http://en.wikipedia.org/wiki/OpenID

21 Open ID- Zagrożenia  Kradzież tożsamości  Koncentracja danych

22