Bezpieczeństwo - Uwierzytelnianie
Uwierzytelnianie
Główne zagadnienia wykładu
Słowo autentyczny (authentic) oznacza wg słownika Webstera być rzeczywiście i dokładnie tym, czym się twier-
dzi, że się jest. Uwierzytelnianie (authentication) jest procesem stwierdzania autentyczności, czyli wiarygodności, weryfi-
kacji tożsamości użytkownika.
Użytkownicy mogą być uwierzytelniani na podstawie jednej lub kilku informacji pochodzących z następujących zbiorów:
1. Tego, co użytkownik wie. Tajny tekst np. hasło znane tylko użytkownikowi i systemowi. W procesie rejestracji jest
ono wprowadzane przez użytkownika i sprawdzane przez system.
2. Tego, co użytkownik posiada. Klucz, plakietka, karta pomagające w weryfikacji użytkownika. W metodzie hasło-
odzew (challenge-response) użytkownik dysponuje kartą wyświetlającą identyfikator liczbowy. Można stosować rów-
nież metodę haseł jednokrotnych.
Użytkownik
Karta
Generowanie
hasła
Weryfikacja metodą
hasło - odzew
System
docelowy
3. Tego, kim użytkownik jest. Cechy fizyczne (odciski palców, odciski dłoni, wzorzec siatkówki) lub behawioralne
(wzorzec głosu, podpis), które można zapamiętać i porównać. Weryfikacja polega na ponownym zbadaniu użytkow-
nika i porównaniu wyników badań z zapamiętanymi w systemie. Ta metoda umożliwia również ewentualną identyfi-
kację włamywacza. W przypadku metod behawioralnych istnieje możliwość odrzucenia prawidłowego użytkownika
(błąd ujemny) i pozytywnej identyfikacji niewłaściwej osoby (błąd dodatni). W chwili obecnej techniki tego typu są
zwykle stosowane jako dodatkowe (obok hasła). Dwustopniowa weryfikacja zwiększa bezpieczeństwo.
Hasła mogą zostać ukradzione z bazy haseł lub przechwycone podczas przesyłania poprzez sieć. Do odgadnięcia hasła
może być wykorzystywana metoda słownikowego łamania brutalnego. Polega ona na sprawdzeniu każdego słowa w
słowniku, czy nie jest hasłem. Wyniki eksperymentu mających na celu analizę słabości haseł pokazują jak łatwo odgad-
nąć hasło dysponując informacją o użytkowniku. Wynika z tego, że hasła powinny być trudne do odgadnięcia i ukradzenia
Techniki ochrony haseł można podzielić następująco:
Nadzorowanie haseł (wybór, pielęgnacja)
Komunikaty systemowe: wyświetlany jest komunikat przed i po rejestracji użytkownika określający dane
systemu. Komunikaty takie mogą dostarczyć intruzowi pewnych wskazówek i dlatego powinny zostać wyłą-
czone lub ograniczone.
Wprowadzanie hasła: hasła nie powinny być widoczne w momencie wprowadzania.
Ograniczanie ilości prób rejestracji: po osiągnięciu limitu nieudanych logowań konto użytkownika powinno
zostać zablokowane (uniemożliwienie dalszych prób). Odblokowanie możliwe po weryfikacji przez admini-
stratora przy pomocy innej metody niż hasło. Uniemożliwia to stosowanie metody brutalnego łamania haseł.
Informacja o nieudanych logowaniach powinna być zachowywana.
Starzenie się haseł: hasło powinno mieć określony czas życia, po którym musi zostać zmienione. Możliwa
może być również zmiana hasła przed upływem ważności (w pewnych granicach). Wykorzystane hasła po-
winny być pamiętane ( w określonym zakresie). Administrator, w przypadku zagrożenia, powinien mieć możli-
wość natychmiastowej zmiany hasła.
Systemy z dwoma hasłami: Drugie hasło jest zwykle wykorzystywane podczas próby dostępu do szczegól-
nie chronionych zasobów.
Opracował: Zbigniew Suski 1
1
W
u
r
2
e
y
m
P
s
u
r
ł
n
a
o
a
e
ł
n
i
ś
s
n
b
i
a
e
a
t
h
a
y
e
i
z
i
d
o
c
n
4
e
e
e
u
n
z
z
n
r
w
d
u
t
P
W
e
a
y
m
z
w
d
f
3
o
y
i
o
e
5
r
k
s
p
e
r
a
i
ł
n
W
a
z
t
W
a
o
t
n
6
k
y
r
y
i
z
a
a
e
c
s
e
r
I
t
z
n
ł
D
r
8
a
y
u
P
n
m
7
i
W
e
e
9
r
y
h
u
s
a
ł
s
P
a
ł
a
n
o
i
t
e
w
o
i
e
d
r
z
d
e
z
w
e
n
u
i
e
r
e
j
e
s
t
r
a
c
j
i
Bezpieczeństwo - Uwierzytelnianie
Minimalna długość hasła: Krótkie hasła są łatwiejsze do odgadnięcia. Wymaga się aby miały co najmniej 6
lub 8 znaków i występowały w nich określone kombinacje grup znaków.
Blokowanie konta użytkownika: blokować należy konta nie używane. Usuwanie blokady po weryfikacji przez
administratora.
Ochrona hasła administratora: Ze względu na znacznie większe uprawnienia, w porównaniu do innych użyt-
kowników, jest częściej atakowane i powinno być lepiej chronione. Można wymagać aby było ciągiem znaków
heksadecymalnych. Nie powinno być przesyłane przez sieć i powinno być często zmieniane.
Generowanie hasła przez system: niektóre systemu oferują użytkownikowi kilka haseł do wyboru. Są to
zwykle hasła trudne do zapamiętania, co powoduje że użytkownicy je zapisują. Hasła generowane powinny
być łatwe do wymówienia.
Zabezpieczanie przed odgadnięciem poprzez odrzucanie zbyt łatwych haseł  sprawdzanie haseł
Sprawdzanie bierne. Realizowane jest po wprowadzeniu haseł do użytku za pomocą programu uruchamia-
nego w ustalonych odstępach czasu. Program taki (cracker) porównuje istniejące hasła z listą haseł łatwych
do odgadnięcia. Hasła łatwe są unieważniane a informacja o tym powinna zostać przesłana do użytkownika.
Przykładem jest program CRACK. Metoda bierna wymaga zużycia znacznych zasobów. Ponadto łatwe hasła
funkcjonują w systemie do momentu ich wykrycia stwarzając potencjalne niebezpieczeństwo.
Sprawdzanie aktywne. Podczas zmiany hasła przez użytkownika, podane przez niego nowe hasło jest wery-
fikowane zgodnie z wbudowanym algorytmem. Hasło zbyt łatwe jest odrzucane a użytkownik jest proszony o
podanie nowego. W tego typu algorytmie istotne jest zapewnienie równowagi pomiędzy użytecznością i bez-
pieczeństwem. Zbyt restrykcyjny algorytm będzie powodował niezadowolenie użytkowników. Zbyt liberalny al-
gorytm obniży bezpieczeństwo systemu.
Bezpieczne przechowywanie haseł
Hasła są najczęściej przechowywane w postaci zaszyfrowanej. Do przechowywania haseł wiele systemów
używa jednokierunkowej funkcji skrótu. Zapamiętywany jest wyliczony skrót. Oznacza to, że oryginalnego ha-
sła nie można uzyskać z jego postaci zaszyfrowanej. Sprawdzenie polega na wyliczeniu skrótu hasła podane-
go przez użytkownika podczas logowania i jego porównaniu ze skrótem przechowywanym w systemie. Tego
typu mechanizm wykorzystywany jest w UNIXie
Hasła jednorazowe
1 Identyfikator
użytkownika
5 Haslo
jednorazowe
Stacja
Użytkownik
robocza
Karta z haslami
jednokrotnego
Uwierzytelnianie za
użytku
pomocą kart z haslami
jednorazowymi
Serwer
Metoda haseł jednorazowych (one-time passwords) polega na jednorazowym wykorzystaniu wygenerowanego hasła.
Wobec tego kradzież hasła nie stanowi zagrożenia. Najczęściej są to liczby wygenerowane na stacji klienckiej i weryfiko-
wane na serwerze. Mogą one być również generowane na specjalnym serwerze. Można również wyposażyć użytkownika
w specjalną kartę. Przy pomocy klawiatury wprowadza on swój PIN. Procesor karty wylicza liczbę, która zostanie wyświe-
tlona a następnie wprowadzona przez użytkownika jako hasło. Serwer na podstawie podanego identyfikatora użytkowni-
ka potrafi wygenerować taki sam kod i dzięki temu zweryfikować użytkownika.
Procedury uwierzytelniania dwustronnego
Zakładamy, że użytkownik potrzebuje usług serwera. W procesie uwierzytelnienia dwustronnego (two-party authenti-
cation) uczestniczy klient i serwer.
Opracował: Zbigniew Suski 2
2
N
I
I
P
d
d
e
e
o
n
w
K
o
6
t
z
y
3
a
f
r
H
i
o
k
n
a
a
d
e
s
t
j
o
l
o
o
l
r
s
u
a
j
e
H
ż
d
y
4
n
t
k
o
o
r
w
a
z
n
o
i
k
w
a
e
Bezpieczeństwo - Uwierzytelnianie
1 Klient jest uwierzytelniony
wobec serwera
Klient
2 Serwer jest uwierzytelniony IBM Compatible
wobec klienta
Serwer
1: Uwierzytelnienie jednokierunkowe
1, 2: Uwierzytelnienie dwukierunkowe
Uwierzytelnienie
dwustronne
Uwierzytelnienie jednokierunkowe polega na sprawdzeniu tożsamości użytkownika. Nie jest sprawdzana tożsa-
mość serwera. Polega na wysłaniu przez użytkownika żądania rejestracji, identyfikatora i hasła.
Uwierzytelnienie dwukierunkowe wymaga dodatkowo potwierdzenia tożsamości serwera, czyli musi on podać
swoje hasło. W sieci rozbudowanej, liczącej kilkudziesięciu użytkownik uwierzytelnienie dwukierunkowe będzie wy-
magało utrzymywania dużej ilości haseł na każdym węz
le. Listy te muszą być skoordynowane. Stwarza to duże pro-
blemy pielęgnacyjne.
Procedury uwierzytelniania z udziałem strony trzeciej
Występująca zaufana strona trzecia (trusted third-party) poświadcza tożsamość klienta i serwera. Jest nazywana
serwerem bezpieczeństwa (security serwer). Jego zadaniem jest przechowywanie haseł wykorzystywanych podczas
weryfikacji użytkowników i serwerów. Jest to jedyne miejsce przechowywania haseł.
Wymagania:
Zapewnienie dwustronnego uwierzytelnienia dwukierunkowego. Zadaniem trzeciej strony jest przechowywanie i pie-
lęgnacja haseł.
Hasła nie powinny być przesyłane poprzez sieć.
Hasła nie powinny być przechowywane na stacji klienckiej.
Zarejestrowany użytkownik powinien otrzymać tymczasowy klucz tajny. Jest on wykorzystywany przez klienta przy
wszystkich dostępach.
System powinien pozwalać na bezpieczne przesyłanie kluczy szyfrowania pomiędzy klientami i serwerami.
Przykładem uwierzytelniania z udziałem strony trzeciej jest system Kerberos.
Uwierzytelnianie w standardzie X.509
Zalecenia X.509 komitetu CCITT przedstawiają model usług uwierzytelniających wykorzystujący metodę klucza
publicznego. Określają schemat sprawdzania tożsamości uzytkowników w systemach opartych na standardzie X.500.
X.500 definiuje standard usług katalogowych (directory services). Standard X.509 przewiduje przechowywanie informacji
o użytkownikach wg standardu X.500.
Uwierzytelnianie dokonywane jest za pomocą certyfikatów. Certyfikat jest wydawany przez urząd poświadczania
certyfikatów CA (Certificate Authority). Wykorzystywana jest metoda szyfrowania z kluczem publicznym i podpis cyfro-
wy. Zalecany jest algorytm RSA. Struktura certyfikatu:
Numer wersji  numer wersji formatu certyfikatu
Numer seryjny  numer przydzielony certyfikatowi przez CA. Unikalny w obrębie funkcjonowania CA.
Identyfikator algorytmu  określa algorytm użyty do podpisania certyfikatu i jego parametry
Identyfikator wystawcy  nazwa CA, który wydał i podpisał certyfikat
Okres ważności  data początku i końca ważności certyfikatu
Użytkownik certyfikatu  określa użytkownika
Informacja o kluczu publicznym  klucz publiczny użytkownika oraz identyfikator algorytmu, który będzie ten klucz
wykorzystywał.
Podpis cyfrowy  uwierzytelnia pochodzenie certyfikatu.
Certyfikat jest przechowywany w katalogu X.500. Każdy użytkownik ma do niego dostęp i może dzięki temu otrzymać
klucz publiczny innego użytkownika. Certyfikat może być unieważniony przed upływem ważności jeżeli:
- Istnieje podejrzenie, że klucz prywatny CA lub użytkownika został ujawniony,
- Użytkownik przestał podlegać danemu CA.
Opracował: Zbigniew Suski 3
Bezpieczeństwo - Uwierzytelnianie
Certyfikaty X.509 są wykorzystywane w PEM (Privacy Enhanced Mail), PGP (Pretty Good Privacy), SSL (Secure Socket
Layer), S-HTTP (Secure HyperText Transfer Protocol).
Procedury uwierzytelniania X.509
Uwierzytelnianie jednokierunkowe  informacja jest przesyłana od jednego użytkownika do drugiego. Przesyłana
wiadomość zawiera:
- Nazwę nadawcy.
- Nazwę odbiorcy.
- Znaczniki czasu określające czas utworzenia i ważności wiadomości.
- Liczbę losową wygenerowaną przez nadawcę. Jest ona ważna do wygaśnięcia ważności i jest przechowywana przez
odbiorcę. Każda inna wiadomość zawierająca tą liczbę zostanie odrzucona.
- Podpis cyfrowy nadawcy.
Można również umieścić inne informacje podpisane przez nadawcę.
Uwierzytelnianie dwukierunkowe  dodatkowo odbiorca uwierzytelnia się wobec nadawcy. Wysyła podobne infor-
macje jak wymienione wyżej. Wysyła również odebraną liczbę losową, liczbę wygenerowaną przez siebie oraz
znaczniki czasu. Można również umieścić inne informacje i je podpisać.
Uwierzytelnianie trzykierunkowe  dodatkowo od nadawcy do odbiorcy przesyłana jest jeszcze wiadomość końco-
wa. Zawiera ona podpisaną kopię liczby losowej wygenerowanej przez odbiorcę. Nie jest wymagany znacznik czasu.
Zamiast niego przesyłane są zwrotnie podpisane liczby losowe.
System Kerberos
System Kerberos powstał w czasie realizacji projektu Athena na uniwersytecie MIT. Projekt miał na celu integra-
cję komputerów uniwersyteckich.
System weryfikacji autentyczności jest oparty na znajomości haseł zapisanych w serwerze Kerberosa. W proce-
sie uwierzytelniania wykorzystuje się tajny dzielony klucz (shared secret), który pozwala na identyfikację użytkowników
bez eksponowania informacji narażających bezpieczeństwo sieci. W systemie uwierzytelniania wyróżnić można cztery
komponenty.
KERBEROS
Serwer uwierzytelniający
KLIENT
3 Bilet do uslugi przyznawania biletów
5 Bilet do uslugi
Serwer przyznawania biletów
Serwer aplikacji
Pierwszy poziom to klient czyli użytkownik lub aplikacja reprezentująca użytkownika. Jest to miejsce, z którego
użytkownik prowadzi pracę, wprowadza identyfikator i hasło.
Drugim poziom to serwer uwierzytelniający (authentication server) służący do przechowywania haseł i spraw-
dzania tożsamości użytkownika. W czasie wymiany informacji z klientem dostarcza on klientowi bilet uprawniający do
korzystania z usługi przyznawania biletów (ticket-granting ticket).
Poziom trzeci to serwer przepustek lub serwer przyznawania biletów (ticket-granting server), który dostarcza
klientowi bilet uprawniający do skorzystania z serwera aplikacji.
Poziom czwarty to serwer aplikacji (application server) czyli zasób, który chce się upewnić, że dany klient jest
poprawny. Dostarcza klientowi żądanej przez niego usługi.
Konto w bazie zawiera dane dotyczące tożsamości oraz klucze główne (np. hasła) wszystkich klientów i serwe-
rów z danego obszaru. Ponadto klucz główny serwera sieciowego służy do szyfrowania wszystkich kluczy głównych
klientów udaremniając nieautoryzowany dostęp do serwera. Hasła są szyfrowane konwencjonalnym algorytmem DES
(mogą być odszyfrowane).
Opracował: Zbigniew Suski 4
a
k
i
n
w
w
ó
o
t
k
e
t
l
i
y
b
ż
u
a
i
n
a
j
a
c
w
a
a
r
t
n
s
z
e
y
j
z
e
r
p
R
i
g
1
u
l
s
u
o
d
t
e
l
i
B
2
5
B
i
l
e
t
d
o
u
s
6
l
u
g
U
i
s
l
u
g
a
d
l
a
k
l
i
e
n
t
a
Bezpieczeństwo - Uwierzytelnianie
Poważną wadą systemu jest jego dostęp do zaszyfrowanych haseł użytkowników, gdyż nie używana jest metoda
klucza publicznego. Powoduje to, że zawarte są w nim dane krytyczne dla bezpieczeństwa i powinien być on chroniony w
sposób szczególny.
Serwer Kerberosa jest bezstanowy. Odpowiada po prostu na żądania użytkowników i wydaje przepustki (żetony,
bilety). Ułatwia to tworzenie replikowanych serwerów zapasowych. Funkcjonowanie systemu z punktu widzenia użytkow-
nika niczym nie różni się od systemu tradycyjnego.
Obecnie (1997) na rynku funkcjonują dwie wersje systemu (4 i 5). Kerberos 4 jest bardziej sprawny niż 5 ale bardziej
ograniczony. Może współpracować tylko z sieciami TCP/IP. W Kerberosie 5 usunięto drobne usterki w protokole i jest on
bardziej odporny na ataki poprzez sieć. Może współpracować z różnymi rodzajami sieci. Może wykorzystywać również
inne systemy kryptograficzne niż DES (np. potrójny DES). Zaimplementowano w nim ponadto szereg interesujących
funkcji jak:
" delegowanie autoryzacji,
" długie czasy przeterminowania,
" przepustki odnawialne,
" przepustki zaplanowane na przyszłość.
Kerberos - wymiana informacji między klientem (C1) i serwerem uwierzytelniającym (AS)
C1>AS: C1, TGS, T
2
Klient C1 wysyła niezaszyfrowany komunikat do AS prosząc o bilet (ticket) na komunikację z serwerem TGS. Komunikat
zawiera identyfikator klienta (C1), identyfikator serwera przyznającego bilety i znacznik czasowy umożliwiający synchro-
nizację zegarów C1 i AS.
AS>C1: {TGS, K , T
C1,TGS 2, L2 , {TGT C1,TGS} K AS,TGS } KC1
AS odsyła do C1 komunikat zaszyfrowany kluczem wytworzonym na podstawi hasła klienta C1. Komunikat ten zawiera
identyfikator serwera przyznającego bilety (TGS), klucz sesyjny (klucz znany klientowi C1 i TGS), znacznik czasu (T
2),
okres ważności biletu (L
2).
Druga część komunikatu zawiera przepustkę udzielającą przepustki (Ticket Granting Ticket - TGT) zaszyfro-
waną kluczem wspólnym AS i TGS. TGT nie jest odszyfrowywana przez klienta C1. Będzie wykorzystywana do otrzymy-
wania zezwolenia uzyskania określonych usług wewnątrz obszaru odpowiedzialności Kerberosa. TGT eliminuje potrzebę
ponawiania procesu identyfikacji przy każdej następnej prośbie.
TGT zawiera: identyfikator i adres klienta, identyfikator serwera TGS, klucz sesyjny (K
C1,TGS), znacznik czasu
(T
2), okres ważności biletu (L2).
Klucze wykorzystywane przy szyfrowaniu mają długość 56 bitów i są uzyskiwane na podstawie hasła określonej jednost-
ki.
Kerberos - wymiana informacji między klientem (C1) i serwerem przepustek (TGS)
Po otrzymaniu przepustki udzielającej przepustki (TGT) użytkownik może wykonywać operacje wymagające
uwierzytelnienia (np. dostęp do pliku). Kiedy użytkownik po raz pierwszy próbuje uzyskać dostęp do serwera aplikacji
(S1) zabezpieczonego przez Kerberos, oprogramowanie jego stacji komunikuje się z serwerem przepustek (TGS) i prosi
o przepustkę do serwera aplikacji.
C1>TGS: {S1, C1, T
3 } KC1,TGS ,
{TGT
C1,TGS} K AS,TGS
Prośba jest zakodowana kluczem sesyjnym (K
C1,TGS) otrzymanym poprzednio od AS. Zawiera nazwę serwera S1 i
poświadczenie (authentikator) klienta (nazwę i adres klienta oraz znacznik czasu). Poświadczenie ma bardzo krótki okras
ważności i nie może być wykorzystywane wielokrotnie. Klient przedstawia również TGT zakodowany kluczem wspólnym
AS i TGS. Zawarty w TGT klucz sesyjny umożliwia rozszyfrowanie prośby.
TGS w odpowiedzi tworzy klucz sesyjny, którym będą się posługiwały C1 i S1 (K
C1,S1). Tworzy też specjalną przepust-
kę (B
C1,S1) uprawniającą do dostępu do serwera S1 i wysyła komunikat do klienta C1.
TGS>C1: { K }K
C1,S1, S1, T4, {BC1,S1 }KS1,TGS C1,TGS
Opracował: Zbigniew Suski 5
Bezpieczeństwo - Uwierzytelnianie
Uzyskany bilet jest przedstawiany serwerowi plików razem z żądaniem dostępu. Bilet ten zawiera sesyjny klucz szyfro-
wania K
C1,S1, identyfikator i adres klienta, identyfikator serwera S1, znacznik czasu i okres ważności biletu. Jest zaszy-
frowany kluczem współdzielonym przez TGS i S1.
Kerberos - wymiana informacji między klientem (C1) i serwerem aplikacji (S1)
C1>S1:{B , { C1 , T
C1,S1 }KS1,TGS 5 }KC1,S1
Bilet zawiera m.in. klucz sesyjny K
C1,S1. Jest on odszyfrowywany przez serwer plików. W ten sposób serwer uzyskuje
klucz sesyjny i może odczytać (odszyfrować dane identyfikacyjne klienta i znacznik czasu).
S1>C1:{ T
5 + 1} KC1,S1
Serwer koduje i wysyła oryginalny znacznik czasu klienta zwiększony o 1. C1 po odszyfrowaniu komunikatu uzyskuje
pewność co do autentyczności serwera, gdyż tylko on mógł dokonać odszyfrowania biletu, uzyskać klucz sesyjny i użyć
go do zakodowania znacznika czasu.
Wszystkie przesyłane żądania i przepustki są szyfrowane. Informacja o porze dnia (znacznik czasu) jest umieszczana w
przepustce aby uniemożliwić atak przez powtarzanie (podsłuchanie, przechwycenie, ponowienie żądania w póz
niejszym
czasie).
Serwer przepustek jest w stanie ustalić tożsamość użytkownika gdyż:
" Żądanie przepustki do serwera plików jest zaszyfrowane kluczem sesyjnym K
C1,TGS
" Użytkownik może poznać ten klucz sesyjny poprzez odszyfrowanie komunikatu odebranego z AS.
" Aby odszyfrować ten komunikat należy znać hasło użytkownika.
Serwer aplikacji może ustalić tożsamość użytkownika gdyż:
" Przepustka przedstawiana przez użytkownika jest szyfrowana za pomocą klucza dzielonego przez serwera aplikacji i
TGS.
" Przepustka zawiera adres IP i nazwę użytkownika.
" W/w. dane są umieszczane w przepustce przez TGS, który jest pewny tożsamości użytkownika, a to wystarcza serwe-
rowi plików.
System Kerberos to system weryfikacji autentyczności, który może być wykorzystywany z wieloma schematami RPC.
Może być również wykorzystywany do samej wymiany kluczy. Istnieje taka wersja polecenia telnet. Istnieje również taka,
zmodyfikowana przez MIT, wersja NFS.
Wady systemu:
" Każda usługa wykorzystywana z Kerberosem musi być indywidualnie modyfikowana. Wymaga to dostępu do
kodu z
ródłowego. Proces nazywa się kerberosowaniem programu (kerberizing).
" Kerberos nie działa poprawnie w środowisku wieloużytkownikowym. Przepustki są przechowywane w katalogu
/tmp, co umożliwia ich kradzież w przypadku pracy wielu użytkowników na jednym komputerze.
" Wymagany jest bezpieczny serwer. Najlepiej gdyby spełniał jedynie tę funkcję.
" Serwer musi być ciągle dostępny.
" Wszystkie hasła są szyfrowane jednym kluczem. Jest to klucz serwera ulokowany w tym samym miejscu co za-
szyfrowane hasła. Po skompromitowaniu serwera wszystkie hasła należy zmienić.
" Kerberos nie chroni przed końmi trojańskimi.
" Kerberos może być powodem kaskadowej utraty zaufania.
Definicja Kerberos 5 znajduje się w RFC 1510.
Atrybuty biletów w systemie Kerberos
Każdy bilet zawiera zbiór znaczników określających atrybuty biletów. Serwer systemu Kerberos włącza i wyłącza znacz-
niki w zależności od bieżącej konfiguracji serwera i sposobu w jaki klient uzyskał bilet.
Bilety początkowe (flaga INITIAL): bilet został wydany przy użyciu protokołu serwera uwierzytelniającego (AS) a nie na
podstawie biletu TGT. Niektóre serwery aplikacji wymagają ustawienia tej flagi. W ten sposób upewniają się, że
klucz klienta był niedawno sprawdzany.
Opracował: Zbigniew Suski 6
Bezpieczeństwo - Uwierzytelnianie
Bilety nieważne (flaga INVALID): są odrzucane przez serwery aplikacji. Muszą one zostać uwiarygodnione przez serwer
uwierzytelniający. Uwiarygodnione zostaną tylko te, którym minął czas początkowy i nie znajdują się na tzw. go-
rącej liście. Zapobiega to kradzieży i wykorzystaniu biletów postdatowanych.
Bilety odnawialne (flaga RENEWABLE): są stosowane dla ograniczenia konsekwencji kradzieży biletów o długim czasie
ważności. Używane są w przypadku gdy użytkownik chce uruchomić szczególnie długi proces. Częste zdoby-
wanie biletów o długim czasie ważności wymagałoby od klienta posiadania długotrwałego dostępu do swojego
klucza, co jest bardzo niebezpieczne. Dla tych biletów definiuje się dwa terminy ważności. Jeden dotyczy waż-
ności danej instancji biletu, a drugi najdalszy termin wygaśnięcia. Przed upływem pierwszego terminu bilet musi
zostać przedstawiony do odnowienia. Po upływie drugiego terminu jest trwale unieważniany. Podczas każdego
odnowienia sprawdzana jest gorąca lista. Flaga RENEWABLE jest zwykle interpretowana tylko przez serwer
TGS. Proces odnawiania nie modyfikuje żadnego pola w bilecie.
Bilety postdatowane (flagi MAY_POSTDATE, POSTDATED): są wykorzystywane dużo póz
niej niż wydawane. Ich prze-
chowywanie naraża je na kradzież. Są one nieważne do momentu dodatkowego, póz
niejszego uwiarygodnienia
przez KDC. Niektóre serwery aplikacji mogą odrzucać bilety postdatowane lub przyjmować je tylko przez pe-
wien czas od pierwotnej weryfikacji tożsamości.
Bilety upełnomocniające się i upełnomocnione (flagi PROXIABLE i PROXY): służą do przekazania pełnomocnictwa
serwerowi, który dzięki temu będzie mógł wykonać zdalne żądanie w imieniu klienta. Klient udostępnia serwe-
rowi informacje o swojej tożsamości ze wskazaniem określonego ich przeznaczenia. Bilety w systemie Kerberos
są zatwierdzane tylko wtedy, gdy są nadsyłane z miejsca o adresie sieciowym zapisanym w bilecie. Bilet z flagą
PROXIABLE nie ma tego adresu. Adres jest ustawiany w momencie upełnomocnienia (flaga PROXY).
Bilety przekazywalne (flagi FORWARDABLE i FORWARD): umożliwiają przekazywanie weryfikacji tożsamości bez ko-
nieczności ponownego wprowadzania hasła. Serwer otrzymuje pełny dostęp do tożsamości użytkownika. Naj-
częściej ma to miejsce wtedy, gdy użytkownik loguje się do systemu zdalnego i chce uzyskać uwiarygodnienie
umożliwiające pracę z systemu zdalnego tak jakby zalogował się lokalnie.
System Kerberos w Windows NT 5.0
W Windows NT 5.0 Kerberos jest zaimplementowany w każdym kontrolerze domeny. System integruje KDC z
usługą katalogową. KDC używa jej jako bazy kont klientów, ich nazw i haseł.
Klient (C1) jest implementowany jako usługa SSP (Security Service Provider) zapisana w SSPI (Security Support
Provider Interface). Usługa WinLogon wywołuje SSP podczas wciskania sekwencji Ctrl+Alt+Del.
Jeżeli C1 loguje się w domenie lub obszarze KDC, to uzyskuje zaszyfrowany bilet TGT. Jest zapamiętywany na
stacji roboczej z pozostałymi danymi z logowania. Gdy C1 chce próbuje skontaktować się z usługą sieciową, aplikacja
klienta sprawdza ważność wcześniejszego biletu (jeżeli istnieje) na dany serwer. Jeżeli jest on nieaktualny, to TGT jest
wysyłany do KDC w celu uzyskania nowego biletu.
Założenia systemu bezpieczeństwa domeny NT określają czas ważności biletu. Standardowo wartość tego pa-
rametru wynosi 8 godzin. Jeżeli wygaśnięcie nastąpi w czasie aktywnej sesji, to klient (SSP) zwraca automatycznie kod
błędu i realizuje procedurę odnowienia biletu. Wszystko to dzieje się bez udziału użytkownika.
W Windows NT w bilecie ustawiane są dodatkowe flagi, które mogą być przesyłane dalej. NT używa tej cechy
aby umożliwić serwerom (z biletami klientów) komunikację z innymi serwerami w imieniu swoich klientów. A
ańcuch takich
odwołań może być kontynuowany na kolejne serwery. Jest to opcja istotna dla rozproszonych aplikacji klient-serwer ta-
kich jak np. SMS (System Management Server) czy Exchange Server.
Możliwa jest współpraca z innymi systemami operacyjnymi, gdyż zapewniona jest obsługa wiadomości zdefinio-
wanych w RFC 1510 i formatach ochronnych GSS API (Generic Security Service) - RFC 1964.
Administrator systemu może dokonać mapowania kont z innych systemów klienckich (np. Unix) na konta NT i
dzięki temu możliwe będzie tworzenie i wydawanie biletów dla klientów obcych.
Aktualnie prowadzone są prace (wspólnie z grupą Common Authentication Technology z Internet Engineering
Task Force) nad wprowadzeniem do RFC 1515 rozszerzeń umożliwiających zastosowanie technologii klucza publiczne-
go/prywatnego. Takie rozszerzenie umożliwi administratorom nadawanie praw do korzystania z zasobów NT, użytkowni-
kom spoza usługi katalogowej NT.
Jednokrotna rejestracja w systemie wielokomputerowym
Pojęcie to oznacza, że użytkownik pracujący w systemie wielokomputerowym, tylko raz wprowadza swój identyfi-
kator i hasło i w ten sposób uzyskuje dostęp do wszystkich komputerów w sieci (np. serwera poczty, serwera plików, ser-
wera bazy danych). Przesyłanie haseł do serwerów powinno być bezpieczne.
W systemach z wielokrotną rejestracją użytkownik musi posługiwać się wieloma hasłami, co powoduje, że je za-
pomina lub przechowuje w sposób niedozwolony.
Z jednokrotną rejestracją związane są następujące problemy:
koordynacja i pielęgnacja identyfikatorów i haseł użytkowników na wszystkich serwerach,
bezpieczne przechowywanie identyfikatorów i haseł,
bezpieczne przesyłanie identyfikatorów i haseł podczas rejestracji.
Opracował: Zbigniew Suski 7
Bezpieczeństwo - Uwierzytelnianie
Jednokrotną rejestrację można zorganizować na wiele sposobów: Każdy z nich musi jednak zawierać podstawową se-
kwencję wymiany informacji między użytkownikiem, stacją roboczą i serwerem.
Podstawowa procedura
1. Żądanie wprowadzenia
identyfikatora i hasła
jednokrotnej rejestracji
7. Uwierzytelnienie
2. Wprowadzenie 3. Uwierzytelnienie
uzytkownika przez
identyfikatora i hasła użytkownika
6. Wysłanie identyfikatora i
aplikację
hasła do aplikacji
4. Prezentacja listy
dostepnych aplikacji
5. Wybranie aplikacji
8. Informacja o
Stacja robocza
uwierzytelnieniu
- klient
użytkownika
9. Informacja o
Serwer
uwierzytelnieniu
użytkownika
Kroki 4-9 są powtarzane przy każdej rejestracji w nowej aplikacji.
Jednokrotna rejestracja z wykorzystaniem stacji roboczej
W metodzie tej identyfikator użytkownika i hasło są przechowywane na stacji roboczej. Przechowywanie hasła na
stacji roboczej naraża je na kradzież. Liczba transmisji hasła jest taka sama jak w przypadku sieci bez jednokrotnej reje-
stracji. Nie jest eliminowane wobec tego niebezpieczeństwo przechwycenia hasła.
Bezpieczna jednokrotna rejestracja z wykorzystaniem stacji roboczej i strony trzeciej
Hasło nie jest przechowywane na stacji klienta, lecz na zaufanym serwerze strony trzeciej. Można oprzeć się na
systemie Kerberos. Hasło nie jest przesyłane przez sieć.
Bezpieczna jednokrotna rejestracja z wykorzystaniem haseł jednorazowych
Wykorzystywany jest serwer bezpieczeństwa strony trzeciej. Służy on do generowania haseł jednorazowych. Zaletą jest
krótki czas życia hasła. Ograniczeniem jest konieczność współpracy aplikacji z programem weryfikacji haseł.
Literatura:
1) V. Ahuja. Network & Internet Security. Academic Press, Inc, 1996.
2) P. Brown. ICL Extends Access Manager to Sun Platforms. Communications Week. Oct. 1994.
3) D. A. Curry. UNIX System Security: A Guide for Users and System Administrators. Addison-Wesley 1992.
4) J. Edwards. Single Sign-on Technologu Streamlines Network Access. Software Magazine. Nov. 1993.
5) M. Hurwicz. Under Lock and Key. Special Report, LAN Magazine. March 1995.
6) J. T. Johnson, K. Tolly. Token Authentication: The Safety Catch. Data Communication, May 1995.
7) L.Klander. Hacker Proof. Jamsa Press, 1997 (tłum. MIKOM 1998).
8) D. V. Klein. Foiling the Cracker: A Survey of, and Improvements to, Password Security. UNIX Security Workshop,
Portland 1990.
9) J. Kohl, B. Neuman. The Kerberos Network Authentication Service. RFC 1510. Sep. 1993.
10) S. J. Lunt. Experiences with Kerberos. UNIX Security Workshop USENIX Assoc. Portland 1990.
11) R. Morris, K. Thompson. Password Security: A Case History. Comm. Of the ACM, v22, n.11, Nov. 1979.
12) National Computer Security Center, Department of Defence Password Management Guideline. CSC-STD-002-85.
13) R. M. Needham, M. D. Schroeder. Using Encryption for Authentication in Large Networks of Computers. Communica-
tions of the ACM, v. 21, n. 12, Dec 1978.
14) T.M. Raleigh, R.W. Underwood. CRACK: A Distributed Password Advisor. UNIX Security Workshop. Portland 1988.
15) D. Russell, G.T. Gangemi. Computer Security Basics. O Reilly&Associates, 1991.
16) E. H. Spafford. Observing Reusable Password Choices. Proc. 1992 Usenix Security Workshop, 1992.
17) W. Stallings. Network and Internetwork Security: Principles and Practice. Prentice Hall 1995.
18) J. G. Steiner, C. Neuman, J. I. Schiller. Kerberos: An Authentication Service for Open Network Systems. Proc. of the
Winter 1988 USENIX Conf. Feb. 1988.
Opracował: Zbigniew Suski 8