Uwierzytelnianie wieloskładnikowe

Paweł Kraszewski
XKCD $5 cryptography

3 podstawowe typy uwierzytelniania

  • Użytkownik wie
  • Użytkownik ma
  • Użytkownik jest

Użytkownik wie

Użytkownik wie

Podstawowy typ uwierzytelniania, stosowany od zarania informatyki:

login + hasło

Użytkownik wie

Najprostszy w realizacji, nie wymaga dodatkowego sprzętu.

Użytkownik wie

Bazuje tylko na wiedzy i pamięci użytkownika.

Użytkownik wie

Hasła łatwo przechwycić przez keyloggery, sniffery, wysłanie użytkownika na fałszywą stronę logowania do usługi albo kradzież bazy haseł (hash+salt!).

Pojawiła się koncepcja haseł maskowanych

Użytkownik wie

Dobre hasła są trudne do zapamiętania. Hasła łatwe do zapamiętania są łatwe do złamania.
XKCD password strength estimation

Użytkownik wie

Aby poprawić jakość haseł pojawiły się generatory haseł

Aby ułatwić życie pojawiły się menadżery haseł

Użytkownik wie

Nigdy nie używaj takiego samego albo podobnego hasła w różnych serwisach i usługach

Nigdy nie wiesz, jaki idiota projektował moduł uwierzytelnienia

Użytkownik ma

Użytkownik ma

Obecne najpopularniejszy typ uwierzytelniana w systemach klasy enterprise i coraz popularniejszy „w cywilu”.

Użytkownik ma

Poza wiedzą o loginie i haśle (traktowanych jako jeden element uwierzytelnienia), użytkownik ma dodatkowe urządzenie albo przedmiot dostarczające drugiego elementu uwierzytelnienia, zawsze o charakterze zmiennym.

Użytkownik ma

Ten dodatkowy element, tzw „drugi składnik” (ang. „second factor”) jest tym, co użytkownik musi mieć przy sobie, żeby móc się zalogować do systemu bądź usługi. Mechanizm nazywa się „uwierzytelnieniem dwuskładnikowym”, „Two Factor Authentication”, w skrócie 2FA

Użytkownik ma

  • Karty kodów i haseł jednorazowych
  • Kody i hasła jednorazowe przez SMS i usługi voice
  • Kody jednorazowe generowane według standardu OATH-HOTP/OATH-TOTP
  • Tokeny kryptograficzne

Karty kodów i haseł jednorazowych

  • Najtańszy typ 2FA
  • Limitowana ilość logowań na kartę
  • Łatwo zapewnić rozliczalność użycia
  • Źle zabezpieczona karta (bez farby maskującej) jest podatna na kopiowanie
  • Występują karty losowe i algorytmiczne.
  • Problem logistyczny z bezpiecznym dostarczeniem nowej karty przed końcem ważności starej.
  • Da się zrealizować „w domu”

Kody przez SMS/voice

  • Koszt zależy od liczby logowań w ciągu miesiąca
  • Nie ma niebezpieczeństwa, że „skończą się hasła”, nie ma problemów z dystrybucją
  • Jest niebezpieczeństwo przechwycenia przez złośliwe aplikacje w telefonie, podsłuch linii (voice przez linię PSTN), ataki na sieć GSM
  • Praktycznie niewykonalne dla osoby fizycznej przy większym wolumenie ruchu.

Kody jednorazowe HOTP/TOTP

Praktycznie zawsze jest to kod o długości 6-10 cyfr (wyjątek – YubiKey, 44 znaki alfanumeryczne)

Kody jednorazowe HOTP

Kody jednorazowe „per use” (bez zegara).

Każde użycie generuje nowy kod. Najprostsze, ale można „ukraść” następny kod

RFC-4226

Odmianą HOTP jest Yubikey-OTP

Kody jednorazowe TOTP

Kody jednorazowe zmienne w czasie.

Najczęściej raz na 30 sekund generowany jest nowy kod, ważny tylko w trakcie tych 30 sekund.

RFC-6238.

Google authenticatior, RSA-SecurID (własny standard)

RSA SecurID done wrong

Kody jednorazowe, robisz to źle

Kody jednorazowe HOTP/TOTP

Koszt od 0 (HOTP/TOTP na darmowej bibliotece po stronie serwera, wykorzystanie Google Authenticatora albo odpowiednika po stronie klienta) do bardzo dużo (bardzo droga infrastruktura RSA SecurID z rocznymi opłatami licencyjnymi)

RSA SecurID

Kody jednorazowe HOTP/TOTP

HOTP/TOTP oparte są o współdzielony sekret (RSA to tylko nazwa firmy, nie ma tam algorytmu klucza publicznego). Kompromitacja serwera pozwala przewidzieć wszystkie kody wszystkich użytkowników do momentu wymiany wszystkich kluczy.

Użytkownik ma

Kryptografia asymetryczna

  • Karty/tokeny mikroprocesorowe zgodne ze standardem PKCS#11 – certyfikaty x509 i klucze RSA/ECDSA
  • Tokeny mikroprocesorowe zgodne ze standardem FIDO/U2F

Tokeny PKCS#11

  • Token zabezpieczony PINem
  • Certyfikat w tokenie służy do uwierzytelnienia całego tunelu SSL/TLS między klientem a serwerem
  • Wymagają infrastruktury PKI

Tokeny PKCS#11

Gemalto eToken Pro 5100Feitian ePass 2003
  • Wymagają wsparcia w przeglądarce
  • Wymagają sterowników i działającej usługi pośredniczącej

Tokeny FIDO/U2F

'FIDO U2F certified' logo
  • Token nie jest zabezpieczony przed niepowołanym użyciem
  • Uwierzytelnienie challenge-response
  • Nie wymaga PKI (nie do końca prawda)

Tokeny FIDO/U2F

YubiKey familyKedo FIDO U2F key
  • Nie wymagają sterowników (protokół USB-HID)
  • Wymagają wsparcia w przeglądarce (bridge z silnika JavaScript do usług HID)

Architektura

FIDO U2F architecture

Rejestracja

FIDO U2F registration

Weryfikacja

FIDO U2F authentication

Użytkownik jest

Użytkownik jest

To sam użytkownik jest składnikiem uwierzytelnienia. Jest to dziedzina metod biometrycznych

Użytkownik jest

  • Odcisk palca
  • Skan tęczówki i/lub siatkówki
  • Skan termiczny naczyń głębokich dłoni i/lub twarzy
  • Analiza głosu
  • Rozpoznawanie twarzy

wygoda ⋅ bezpieczeństwo ⋅ cena-1 = const

Dziękuję