Autentizační mechanismy webových služeb

Součástí bezpečnosti webových služeb jsou autentizační a autorizační mechanismy, dovolující přístup k datům pouze pro odpovídající osoby. Otázkou je, nakolik dobře jsou známá omezení. Součástí těchto nastavení by měla být i odpovídající architektura, ochranné a detekční prostředky. Dnes se webové portály používají ve všech organizacích a nevhodná ochrana dat má své důsledky.

Autentizační mechanismy webových prohlížečů

Další volné pokračování autentizačních mechanismů se tentokrát věnuje problematice webových prohlížečů. Jejich přístup k ochraně autentizačních údajů je značně volný a spoléhá hlavně na transportní šifrování. Bohužel vrstva SSL/TLS má svoje omezení, které je nutné brát v potaz. Proto je nutné začít s vysvětlením, jaké pracuje vlastní ověřování v protokolu HTTP, co nabízí vrstva SSL/TLS a kde se tyto metody potkávají.
Nejčastěji podceňovaným dopadem na bezpečnost autentizačních mechanismů je předávání parametrů v rámci URL, kdy jsou předávané hodnoty ukládané například v záznamech provozu. Další nectností je podceňování nutného zabezpečení, část stránek může mít nastavenou ochranu, ale u přesměrování na autentizační portál tato ochrana chybí. Stejně tak je problematické zabezpečení pomocí SSL/TLS, kdy není nastavena ochrana proti případné SSL Inspekci. Jako poslední vliv je nutné také započítat telemetrické informace prohlížeče, schopnost automatické korektury textu nebo různé plugin moduly, zasílající informace jejich autorům. Prohlížeče proto není možné brát jako bezpečné prostředí a autentizační algoritmy by z uvedených důvodů měly vždy vyžadovat další faktor.

Principy ověřování pomocí HTTP protokolu

V případě přístupu k webové adrese je běžná odpověď na GET dotaz od webové stránky 200 OK. Následně jsou zaslány požadované data. V případě přístupu na chráněný obsah je ale komunikace mírně odlišná. Na GET dotaz vrátí stránka kód 401 Unauthorized, který vynutí autentizaci ze strany klienta. Pokud autentizace skončí chybou, je vrácen kód 403 Forbidden. Samozřejmě, jsou možné i další kódy, například kód 404 Not Found, ale to již nesouvisí s ověřováním.

Dostupné autentizační mechanismy

V současnosti jsou nejčastěji používané mechanismy z tabulky níže dostupné jak pro prohlížeče Brave, Chrome, Chromium, Edge, Firefox, Opera, Safari, Vivaldi a další. Na straně web serverů, jako je Apache, Apache Tomcat LightHttp, Microsoft IIS a NGINX se jedná o stejnou sadu. Rozdíl zde vytváří podpora pro interní infrastrukturu, kde jsou podporovány navíc mechanismy jako je Kerberos, LDAP a SAML.

HTTP Basic Authentication

Jedná se o nejjednodušší formu ověřování. V případě detekce požadavku na ověření, tedy návratu chybové zprávy 401 Unauthorized spolu s informací WWW-Authenticate: Basic realm="Secure Area" se při dalším HTTP dotazu do hlavičky požadavku přidává hodnota:
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQK
Textový řetězec za definicí typu ověření obsahuje řetězec uživatelské_jméno:heslo kódovaný pomocí Base64. Protože se jedná o kódování nikoliv o šifrování, je nutné použít ochranu pomocí transportního šifrování (SSL/TLS). V jiném případě je možné extrémně snadno získat původní uživatelské jméno a heslo.

Channel Binding: Ne
Realms: Ne
Kryptoprimitiva: Ne
Účastníků autentizace: 2
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Na straně serveru
Tokenizace: Ne
Jedinečnost: Ne
Ochrana credentials: Ne
Ochrana proti Replay: Ne
Ochrana proti Relay: Ne
Ochrana proti Hijack: Ne
Ochrana proti Forge: Ne
Podpora MFA: Možné, musí existovat podpora na aplikační úrovni
Ochrana integrity: Ne
Typ šifrování: Ne, nezbytné použít SSL/TLS

HTTP Digest Authentication

Jedná se o mírně vylepšenou, ale stále zastaralou formu ověřování. Na rozdíl od plaintext autentizace dochází k využití hash funkce MD5. Slabiny uvedené hash funkce vedly v roce 2015 k vydání nového RFC 7616, které umožnilo nahrazení funkce MD5 některou z hash funkcí rodiny SHA2 (SHA2-256, SHA2-384, SHA2-512, SHA2-512/256). V případě použití HTTP Digest Authentication s hash funkcí SHA2 tak dochází k výraznému zlepšení bezpečnostních vlastností. Při vlastním přihlašování opět dochází v případě přístupu k zamítnutí přístupu pomocí chybové zprávy 401 Unauthorized spolu s těmito informacemi:
WWW-Authenticate: Digest
realm="Secure Area", nonce="000102030405060708090a0b0c0d0e0fff",
qop="auth", opaque="5ccc069c403ebaf9f0171e9517f40e41"

Na základě odpovědi je možné detekovat, zda je použit standardní algoritmus MD5, nebo nový standard s podporou SHA2. V případě podpory hash funkce SHA2 je totiž odpověď rozšířena o údaj algorithm=SHA-256. Klient detekující požadavek na ověření následně znovu požádá o připojení. Do hlavičky tentokrát přidá část údajů ze zamítnutí přístup spolu s informacemi, díky kterým může server provést jeho ověření. Jedná se o následující data:
Authorization: Digest username="user", realm="Secure Area",
nonce="000102030405060708090a0b0c0d0e0fff", uri="/secure",
response="123456789abcdef123456789abcdefff", qop=auth, nc=00000001, cnonce="02468ace"

Odpověď se spočítá jako výsledek hash funkce (příklad pro MD5) s následujícím obsahem.
response = MD5(MD5(username:realm:password)+nonce+nc+cnonce+qop+MD5(method:uri))

Channel Binding: Ne
Realms: Ne
Kryptoprimitiva: MD5, SHA2
Účastníků autentizace: 2
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Na straně serveru
Tokenizace: Ne
Jedinečnost: Ne
Ochrana credentials: Ano
Ochrana proti Replay: Ano
Ochrana proti Relay: Ne
Ochrana proti Hijack: Ne
Ochrana proti Forge: Ano
Podpora MFA: Možné, musí existovat podpora na aplikační úrovni
Ochrana integrity: Ne
Typ šifrování: Hash, nezbytné použít SSL/TLS

TLS Client Certificate Authentication

V případě ověřování pomocí klientského certifikátu je nejčastějším problémem možné pomýlení s mTLS (mutual TLS), protože se jedná o extrémně podobné technologie. Při běžném navazování TLS spojení dochází k poskytnutí serverového certifikátu za účelem inicializace zabezpečeného spojení. I v této oblasti je snadný omyl, nedochází totiž k ověření serveru zda má správný certifikát, ale dochází k ověření jeho platnosti a některých vlastností certifikátu. To jsou dvě rozdílné informace s jiným významem.

V případě detekce požadavku na ověření, dochází k návratu chybové zprávy 401 Unauthorized spolu s informací:
WWW-Authenticate: TLS-Cert Dalšími alternativami, vyžadujícími splnění určitých podmínek jsou odpovědi, obsahující mimo požadavku na certifikát ještě další upřesnění jejich různé kombinace:
• Příslušnost certifikátu ke konkrétní CA
  WWW-Authenticate: TLS-Cert, CA="CN=TrustedAuthority, O=Organization, C=Country"
• Požadovaný atribut
  WWW-Authenticate: TLS-Cert, Subject="CN=Name Surname, O=Organization"
• Požadovaná konkrétní politika
  WWW-Authenticate: TLS-Cert, Policy="1.2.840.113549.1.1.11"
• Požadovaný konkrétní algoritmus podepisování certifikátu
  WWW-Authenticate: TLS-Cert, Alg="ECDSA"
Mezi další parametry patří SAN (Subject Alternate Name), Serial Number a otisk certifikátu. Na základě získaných informací klient ukončuje spojení a vytváří nové, kde serveru poskytuje informaci o svém klientském certifikátu.
V průběhu navazování dochází k výměně výzvy, kterou klient podepisuje. Klient serveru na základě jeho požadavku (Certificate Request) navíc odpovídá s požadovanými informacemi o svém certifikátu.
Client Certificate: [Base64-encoded X.509 certificate] Signature: [Digitally signed challenge]
Jedná se vlastně o klasickou Client Certificate message v průběhu inicializace TLS spojení. Následně server provádí kontrolu, zda je klientský certifikát platný a splňuje definované podmínky. Poté klient znovu zažádá o přístup ke zdroji, server na základě dostupných informací spáruje klientský certifikát proti požadavkům na ověření zdroje. Jedná se tedy o volitelné ověření klienta, zpravidla se používá pro VPN a zabezpečené weby. Pro navázání spojení na komunikační kanál (Channel Binding) se může použít tls-unique a tls-server-end-point, kde tls-unique v TLS 1.3 již není podporováno.
V případě mTLS dochází při navazování spojení na úrovni TLS vrstvy k poskytnutí serverového certifikátu za účelem inicializace zabezpečeného spojení. I v průběhu této inicializace server vyžaduje certifikát, zde se ale jedná o povinné ověření klienta. Zpravidla se používá pro různá API, mikroservisní komunikace nebo i Kubernetes.
Zajímavostí u TLS Client Certificate Authentication je možnost ověření uživatele a konkrétní vazby na certifikát například pomocí databáze uživatelů, Active Directory nebo LDAP databáze, OAuth 2.0 a OpenID Connect. V takovém případě je možné pokračovat s dalším porovnáním vlastností certifikátu na aplikační vrstvě.

Channel Binding: Možný
Realms: Ne
Kryptoprimitiva: dle ciphersuites SSL/TLS
Účastníků autentizace: 2
PQC/QRC: Standardně ne, možné u TLS 1.3
ZKP: Ne
Podpora crypt interface: Ne
Tokenizace: Ne
Jedinečnost: Ano
Ochrana credentials: Ano
Ochrana proti Replay: Ano
Ochrana proti Relay: Ano
Ochrana proti Hijack: Ano
Ochrana proti Forge: Ano
Podpora MFA: Možné, musí existovat podpora na aplikační úrovni
Ochrana integrity: Ano
Typ šifrování: SSL/TLS, součástí autentizace

WebAuthn

V současnosti je nejvíce propagovaný autentizační standard WebAuthn, který dovoluje používat různé způsoby pro ověření klíčového materiálu nebo podporu biometrického ověření. Cílem je minimalizovat používání hesel, která se často vyznačují nízkou entropií, nedostatečnou náhodností a nepředvídatelností, ve prospěch klíčového materiálu. Klíčový materiál je jedinečný pro kombinaci uživatel/server. Tím se zároveň snižuje riziko vícenásobného používání identických hesel napříč různými systémy. Na straně serveru tak není potřeba databáze hesel, což snižuje pravděpodobnost jejich úniku. Veřejné klíče jsou útočníkovi k ničemu, z principu jsou dostupné pro každého. Dále tento protokol vyžaduje použití alespoň TLS 1.2 nebo vyšší verze pro ochranu přenášených informací.
Velice zjednodušeně funguje WebAuthn pomocí asymetrické kryptografie. Na začátku klient vygeneruje pár klíčů. Privátní klíč zůstává lokálně uložen (TPM, token, secure enclave, strongbox). Veřejný klíč následně registruje na straně serveru. Díky tomu má server informace o uživateli a jemu odpovídajícímu veřejnému klíči. V případě použití biometrického ověřování se biometrie používá pouze k povolení přístupu ke klíčovému materiálu. Pokud se uživatel chce přihlásit, pošle informaci o žádosti serveru. Ten následně odešle výzvu, kterou klient podepíše a odešle zpět na server. Tam je díky možnosti ověření podpisu za pomoci veřejného klíče možné získat informaci, zda se přihlašuje odpovídající uživatel.

Registrace:
Server → Client:  C_S = RND (32B)
Client:        M = C_S || CredentialID || K_Public
Client:        Signature = DSA (K_Private, M)
Client → Server:  Response={M, Signature}

Přihlášení:
Server → Client:  C_S=RND(32B)
Client:        M=C_S∥ClientData∥AuthenticatorData
Client:        Signature=DSA(K_Private,M)
Client → Server:  Response={C_S,AuthenticatorData,Signature,credentialId}

Channel Binding: Možný
Realms: Ne
Kryptoprimitiva: dle ciphersuites SSL/TLS
Účastníků autentizace: 2
PQC/QRC: Standardně ne, možné u TLS 1.3
ZKP: Ne
Podpora crypt interface: Ne
Tokenizace: Ne
Jedinečnost: Ano
Ochrana credentials: Ano
Ochrana proti Replay: Ano
Ochrana proti Relay: Ano
Ochrana proti Hijack: Ano
Ochrana proti Forge: Ano
Podpora MFA: Možné, musí existovat podpora na aplikační úrovni
Ochrana integrity: Ano
Typ šifrování: SSL/TLS, součástí autentizace

OAuth 2.0

Mimo nastupujícího WebAuth, který je oblíben zvláště kvůli spojení s různými tokeny (Yubikey, Titan …) nebo TPM, jsou další oblíbenou metodou autentizace systémy třetích stran. Ty zajišťují autentizaci a poskytují autorizační informace pro přístup k webovým portálům nebo aplikacím. V případě OAuth 2.0 je možné využít funkcionalitu federovaného ověřování. Tento algoritmus je popsán mezi SASL mechanismy v jiném článku, takže zde budu popisovat jenom základní rozdíl při využití webového rozhraní. V případě potřeby pochopit princip provozu doporučuji využít odkaz věnující se tomuto protokolu Rozhraní OAuth 2.0 vyžaduje použití TLS 1.2+ pro zajištění bezpečné komunikace. Na rozdíl od OpenID Connect dovoluje použití refresh tokenu pro tvorbu žádosti o nový token. Postup pak vypadá přibližně následovně. Klient se pokusí přihlásit s konkrétním tokenem nebo přistupuje bez tokenu: Authorization: Bearer <expired_token>

Server vrátí chybovou zprávu, která označuje neplatný nebo expirovaný token. Stejně tak ji vrací i v případě, kdy uživatel ještě nebyl přihlášen.
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="REALM", error="invalid_token", error_description="The access token is expired"

Klient potřebuje získat odpovídající token, proto se musí znovu přihlásit na autentizačním serveru:

Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=<refresh_token>&client_id=<client_id>&client_secret=<client_secret>

Autentizační server vydá nový token:
HTTP/1.1 200 OK
Content-Type: application/json

{
  "access_token": "new_access_token",
  "token_type": "Bearer",
  "expires_in": 3600
}

Klient se opět připojí k aplikačnímu serveru:
Authorization: Bearer new_access_token

A pokud je token správný, aplikační server povolí přístup:
HTTP/1.1 200 OK

Channel Binding: Ne
Realms: Ano
Kryptoprimitiva: Výběhové (RSA), aktuální (SHA256, ECDSA)
Počet stran při autentizaci: 3 až 4
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Za určitých podmínek
Tokenizace: Ano
Jedinečnost: Ano
Ochrana credentials: TLS
Ochrana proti Replay: Ano
Ochrana proti Relay: Ano
Ochrana proti Hijack: Ano
Ochrana proti Forge: Ano
Podpora MFA: Ano
Ochrana integrity: TLS, pro JWT interní
Typ šifrování: TLS, pro JWT navíc interní

OpenID Connect

OpenID Connect je varianta OAuth 2.0 a je také popsán v samostatném článku. I zde jsou popsány základní rozdíly při využití webového rozhraní. V případě potřeby pochopit princip provozu doporučuji využít odkaz věnující se tomuto protokolu Rozhraní OpenID Connect vyžaduje použití TLS 1.2+ pro zajištění bezpečné komunikace. Na rozdíl od OAuth 2.0 vyžaduje nové přihlášení pro tvorbu žádosti o nový token. Postup ověření pak vypadá následujícím způsobem:
Klient se pokusí neúspěšně přihlásit, server požaduje autorizaci
Authorization: Bearer

Server odpovídá požadavkem na OIDC autentizaci
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example", error="invalid_token", error_description="ID Token expired"

Klient je přesměrován na autorizační server, pokud nemá refresh token, musí se znovu přihlásit

GET https://auth.example.com/authorize?client_id=client&response_type=code
&scope=openid profile email&redirect_uri=https://client.example.com/callback
&state=random_state

Autorizační server poskytne autorizační kód:
HTTP/1.1 302 Found
Location: https://client.target.tld/callback?code=code&state=random_state

Klient po přihlášení požádá o ID a access token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=code&redirect_uri=https://client.example.com/callback
&client_id=client&client_secret=client_secret

Po ověření vrací autorizační server ID a access token:
HTTP/1.1 200 OK
Content-Type: application/json

{
   "access_token": "new_access_token",
   "id_token": "new_id_token",
   expires_in": 3600"
}

Klient se znovu přihlásí s odpovídajícími informacemi
Authorization: Bearer new_access_token
A pokud je token správný, je přístup povolen
HTTP/1.1 200 OK

Channel Binding: Ne
Realms: Ano
Kryptoprimitiva: Výběhové (RSA), aktuální (SHA256, ECDSA)
Počet stran při autentizaci: 3 až 4
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Za určitých podmínek
Tokenizace: Ano
Jedinečnost: Ano
Ochrana credentials: TLS
Ochrana proti Replay: Ano
Ochrana proti Relay: Ano
Ochrana proti Hijack: Ano
Ochrana proti Forge: Ano
Podpora MFA: Ano
Ochrana integrity: TLS, pro JWT interní
Typ šifrování: TLS, pro JWT navíc interní

Závěr

Použití integrovaných mechanismů prohlížečů je sice jednoduchou metodou, ale vyžaduje pochopení funkce ochranných mechanismů. Bez znalosti faktů není možné odpovědně nastavit zabezpečení, což může mít fatální dopady na bezpečnost dat. Autentizační mechanismy jsou základní obrannou bariérou, jejich konfigurace je nezbytná, nikoliv však postačující. Stejnou péči je nutné věnovat i přidělování oprávnění a dalším vrstvám ochrany.

Autor článku:

Jan Dušátko

Jan Dušátko se počítačům a počítačové bezpečnosti věnuje již skoro čtvrt století. V oblasti kryptografie spolupracoval s předními odborníky např. s Vlastimilem Klímou, či Tomášem Rosou. V tuto chvíli pracuje jako bezpečnostní konzultant, jeho hlavní náplní jsou témata související s kryptografií, bezpečností, e-mailovou komunikací a linuxovými systémy.