Szyfrowanie hasła

Edytuj w trybie z połączeniem

Serwer IBM® Tivoli® Directory Server umożliwia uniemożliwienie dostępu bez uprawnień do haseł użytkowników. Administrator może skonfigurować serwer do szyfrowania wartości atrybutów userPassword przy użyciu szyfrowania jednokierunkowego lub szyfrowania dwukierunkowego. Zaszyfrowane hasła są oznaczane nazwą algorytmu szyfrowania, dzięki czemu hasła zaszyfrowane w różnych formatach mogą współistnieć w jednym katalogu. Jeśli konfiguracja szyfrowania zostanie zmieniona, istniejące zaszyfrowane hasła pozostaną niezmienione i będą działać.

Dzięki jednokierunkowym algorytmom szyfrowania, hasła użytkowników mogą zostać zaszyfrowane i zapisane w katalogu, co uniemożliwi dostęp do jawnych haseł użytkownikom, w tym administratorom systemu. W przypadku korzystania z dwukierunkowych algorytmów szyfrowania, hasła są szyfrowane podczas ich przechowywania w bazie danych, a następnie są one deszyfrowane przy ich zwracaniu do autoryzowanego klienta. Zastosowanie szyfrowania dwukierunkowego zabezpiecza hasło zapisane w bazie danych, a jednocześnie obsługuje metody uwierzytelniania, takie jak DIGEST-MD5, które wymagają, aby serwer miał dostęp do hasła w postaci jawnego tekstu, oraz obsługuje aplikacje, które mogą korzystać tylko z haseł podanych w postaci jawnego tekstu.

Hasła zaszyfrowane jednokierunkowo mogą być używane do dopasowywania hasła, ale nie mogą być deszyfrowane. Podczas logowania się użytkownika podane przez niego hasło logowania jest szyfrowane i porównywane z zapisaną wersją w celu weryfikacji zgodności.

Nawet jeśli serwer został skonfigurowany do przechowywania nowych haseł w określonym formacie, będzie akceptować hasła zaszyfrowane wcześniej przy użyciu innej metody. Na przykład serwer można skonfigurować tak, aby używał algorytmu szyfrowania haseł AES256, ale nadal będzie on zezwalał administratorowi na ładowanie danych z innego serwera, który zawiera hasła zaszyfrowane przy użyciu SHA-1. Oba zestawy haseł mogą być używane do uwierzytelniania na serwerze przy wykorzystaniu mechanizmu prostego uwierzytelniania, ale hasła SHA-1 będą zwracane jako łańcuchy zaszyfrowane i nie można ich używać z uwierzytelnianiem DIGEST-MD5.

Algorytmy szyfrowania jednokierunkowego to:

  • SHA-1 z solą
  • SHA-1
  • MD5
  • crypt
  • SHA-2
  • SHA-2 z solą

Po skonfigurowaniu serwera wszystkie nowe hasła (dla nowych użytkowników) lub zmodyfikowane hasła (dla istniejących użytkowników) zostaną zaszyfrowane przed ich zapisaniem w bazie danych katalogu. Kolejne wyszukiwania LDAP będą zwracać oznaczoną i zaszyfrowaną wartość.

W przypadku aplikacji, które wymagają pobrania haseł w postaci jawnego tekstu, takich jak agenty uwierzytelniania warstwy pośredniej, administrator katalogu musi skonfigurować serwer w taki sposób, aby mógł on obsługiwać dwukierunkowe szyfrowanie haseł użytkowników. W tym przypadku jawne hasła zwracane przez serwer są chronione przez mechanizm listy ACL katalogu.

Algorytmy szyfrowania dwukierunkowego to:

  • Brak
  • AES

Dostępny jest algorytm szyfrowania dwukierunkowego (AES), który umożliwia zaszyfrowanie wartości atrybutu userPassword przechowywanych w katalogu i ich pobieranie wraz z innymi danymi pozycji w oryginalnym, nieszyfrowanym formacie. Można go skonfigurować do używania kluczy o długości 128, 192 i 256 bitów. Niektóre aplikacje, takie jak serwery uwierzytelniania warstwy pośredniej, wymagają pobierania haseł w postaci jawnego tekstu. Jednak strategie bezpieczeństwa korporacyjnego mogą zabraniać przechowywania jawnych haseł w dodatkowej pamięci trwałej. Ta opcja spełnia oba wymagania.

Dodatkowo, gdy hasła zaszyfrowane przy użyciu AES są używane w sieci z replikacją, jeśli wszystkie serwery zostaną skonfigurowane z użyciem tej samej frazy hasła i dodatkowych danych szyfrujących (salt) dla AES, dane haseł będą również replikowane w postaci zaszyfrowanej, co zapewnia wyższy poziom zabezpieczeń. Jeśli serwer nie obsługuje AES lub ma skonfigurowane inne informacje AES, hasła będą deszyfrowane i replikowane w postaci jawnego tekstu.

Uwaga:
  1. Algorytm AES nie jest obsługiwany na serwerach LDAP w wersjach wcześniejszych niż IBM i 6.1. W szczególności replikacja danych zaszyfrowanych przez AES nie jest obsługiwana na serwerze LDAP w wersji wcześniejszej niż 6.1.
  2. Na innych platformach, gdy wybrano opcję 'Brak', w bazie danych zapisywane będą hasła w postaci jawnego tekstu. Jeśli serwer ten jest częścią sieci, która zawiera serwer IBM Tivoli Directory Server na innych platformach, zaleca się użycie jednej z opcji szyfrowania AES.

Proste powiązanie powiedzie się, jeśli hasło podane w żądaniu powiązania będzie zgodne z dowolną spośród wielu wartości atrybutu userPassword.

Podczas konfigurowania serwera za pomocą programu Web Administration, można wybrać jedną z następujących opcji szyfrowania:

Brak
Hasła są zapisywane jako zaszyfrowane dwukierunkowo na liście sprawdzania i mogą być pobierane jako część pozycji w oryginalnym formacie jawnego tekstu.
crypt
Hasła są szyfrowane przez algorytm szyfrowania UNIX crypt, zanim zostaną zapisane w katalogu. Gdy używany jest algorytm crypt, używane jest tylko pierwsze 8 znaków podanego hasła. Hasła dłuższe niż 8 znaków są obcinane.
MD5
Hasła są szyfrowane za pomocą algorytmu mieszającego MD5 przed ich zapisaniem w katalogu.
SHA-1
Hasła są szyfrowane algorytmem szyfrującym SHA-1, zanim zostaną zapisane w katalogu.
SHA-1 z solą
Hasła są szyfrowane za pomocą algorytmu szyfrowania SHA-1 przed ich zapisaniem w katalogu.
SHA-2
Hasła są szyfrowane przez rodzinę algorytmów szyfrujących SHA-2 przed ich zapisaniem w katalogu. Obsługiwane schematy szyfrowania w ramach rodziny algorytmów szyfrowania SHA-2 są następujące:
  • SHA-224
  • SHA-256
  • SHA-384
  • SHA-512
SHA-2 z solą
Hasła są szyfrowane przez rodzinę algorytmów szyfrowania SHA-2 z solą przed ich zapisaniem w katalogu. Obsługiwane schematy szyfrowania w ramach rodziny algorytmów szyfrowania SHA-2 z solą to:
  • SSHA-224
  • SSHA-256
  • SSHA-384
  • SSHA-512
AES128
Hasła są szyfrowane za pomocą algorytmu AES128 przed ich zapisaniem w katalogu i są pobierane jako część pozycji w oryginalnym formacie zwykłego tekstu.
AES192
Hasła są szyfrowane za pomocą algorytmu AES192 przed ich zapisaniem w katalogu i są pobierane jako część pozycji w oryginalnym formacie zwykłego tekstu.
AES256
Hasła są szyfrowane za pomocą algorytmu AES256, przed ich zapisaniem w katalogu i są pobierane jako część pozycji w oryginalnym formacie zwykłego tekstu.
Uwaga: Format imask, który był dostępny w poprzednich wersjach, nie jest już opcją szyfrowania. Jednak wszystkie istniejące wartości zaszyfrowane przy użyciu imask nadal będą działać.

Domyślną opcją dla serwera Tivoli Directory Server dla systemu IBM i jest SHA-1, która jest kompatybilna z wcześniejszymi wersjami i nie wymaga ustawiania hasła i klucza dodatkowego AES.

Oprócz wartości userPassword również wartości atrybutu secretKey są zawsze szyfrowane w katalogu przy użyciu algorytmu AES256. W przeciwieństwie do atrybutu userPassword, to szyfrowanie jest wymuszane dla wartości secretKey. Nie jest dostępna żadna inna opcja. Atrybut secretKey jest schematem zdefiniowanym przez IBM . Aplikacje mogą używać tego atrybutu do przechowywania danych poufnych, które muszą być zawsze szyfrowane w katalogu, oraz do pobierania danych w postaci jawnego tekstu przy użyciu kontroli dostępu do katalogu.

Aby zmienić typ szyfrowania za pomocą wiersza komend, na przykład zmieniając wartość na crypt, należy uruchomić następującą komendę:

ldapmodify -D <adminDN> -w <adminPW> -i <filename>

gdzie <filename> zawiera:
dn: cn=configuration 
changetype: modify 
replace: ibm-slapdPWEncryption 
ibm-slapdPWEncryption: crypt

Aby zaktualizowane ustawienia zostały uwzględnione dynamicznie, należy wprowadzić następującą komendę ldapexop:

ldapexop -D <adminDN> -w <adminPW> -op readconfig -scope single
"cn=configuration" ibm-slapdPWEncryption
Uwaga: Aby zmienić konfigurację, należy uwierzytelnić się przy użyciu nazwy wyróżniającej i hasła użytkownika rzutowanego dla profilu użytkownika systemu IBM i z uprawnieniami specjalnymi *ALLOBJ i *IOSYSCFG. Jest to to samo uprawnienie, które jest wymagany do zmiany konfiguracji serwera za pomocą innych interfejsów.