Analýza SASL, díl pátý

Předchozí díly se věnovaly hlavně technickému rozboru a popisu použitých algoritmů. Uvedené algoritmy mají velké množství problematických míst, což vytváří zajímavou situaci v případě potřeby volby požadovaných algoritmů. Protože neexistuje dokonalé řešení, algoritmy jsou v tomto článku rozděleny do skupin s podobnými problémy. Díky tomu je možné si udělat představu o celé situaci a případně se rozhodnout na základě aktuální situace.

Proč jsou autentizační algoritmy tak důležité?

Základní součástí přístupu k informacím je ověření žadatele. Ten se na začátku ohlásí systému, identifikuje se. Aby systém mohl přidělit uživateli nějaká oprávnění, musí ho ověřit, tedy zkontrolovat platnost jeho identity. Právě z tohoto důvodu je autentizace kritickým bodem v přístupu k datům, musí zajistit co nejvyšší správnost. Až teprve po ověření je možnost uživatelům přidělit práva, poskytující jim možnost přístupu ke zvoleným informacím.
Mimo předpokladu pro přidělení oprávnění autentizace podporuje ještě další vlastnosti. Jednak se jedná o jednu z forem zajišťující autenticitu (pravost, originalitu dat), která je vztažená k určitému uživateli. Uvedený důkaz pravosti zajišťuje systém pouze v oblasti své působnosti. Obecným důkazem pravosti může být digitální podpis. Druhou podobnou vlastností je neodmítnutelnost, tedy důkaz o nerozlučném spojení uživatele s konkrétními daty nebo aktivitou.

Problémy algoritmů

Předchozí čtyři díly analýzy autentizačních mechanismů měly za cíl seznámit zájemce s technologiemi použitými v jednotlivých algoritmech. Důvodem je nutnost poskytnout odpovídající data pro ověření kterýmkoliv čtenářem se zájmem o kryptografii. V současnosti dochází k velkému nárůstu množství útoků a také k výraznému nárůstu jejich kvality. Současné autentizační algoritmy nejsou schopné se této situaci přizpůsobit, jsou prakticky za zenitem a náhrady nejsou dostupné. Přestože právě uvedené mechanismy stojí v základu ověřování. Všechny nalezené problémy je tak možné shrnout do následujících bodů:
- žádná kryptoprimitiva.
- zastaralá kryptoprimitiva nebo zastaralé metody užití uvedených kryptoprimitiv.
- žádná nebo nízká odolnost proti útokům za pomoci kvantových počítačů.
- autentizační mechanismy nesplňují podmínky na ochranu přenášených dat před opakováním, přesměrováním, únosem spojení nebo paděláním komunikace, případně nepodporují forward secrecy (v minulosti zachycená komunikace dovoluje odvodit v budoucnosti přenášené informace).
- autentizační mechanismus nezajišťuje plnou ochranu přenášených dat a vazbu na další komunikaci.
- kontrola ověření je prováděna pomocí logické závory (podmínky), kdy splnění podmínky je možné dosáhnout i modifikací vykonávaného kódu.

Metody bez kryptografie

Ověřovací metody, které nepoužívají žádné metody ochrany pomocí kryptografie není možné považovat za bezpečné. Jedná se o podmínku nezbytnou, nikoliv však postačující, jak bude uvedeno dále. Mezi uvedené algoritmy je tak možné zařadit:
- ANONYMOUS (zde nedochází k ověření).
- LOGIN.
- PLAIN (data přenášena jako řetězec kódovaný Base64, nejedná se o ochranu).
- OAUTH, OAUTH10A, XOAUTH (pouze pro HTTP Basic Authentication).
- OAUTH2, OAUTHBEARER, OPENID2 (pouze pro HTTP Basic Authentication).
- SAML (pouze pro přihlašování proti SQL/NoSQL systémům s webovým rozhraním a HTTP Basic Authentication, dále pro ostatní systémy podporující metody PLAIN a LOGIN).
Všechny uvedené metody vyžadují nasazení transportního šifrování (SSL/TLS) a vynucením oboustranného ověření (mTLS – Mutual TLS). V jiném případě je možné provádět SSL inspekci a vlastní přenášené přihlašovací informace odposlechnout. Pro metody OAUTH2, OAUTHBEARER a OPENID20 je do jisté míry podporou využití šifrování JWT tokenů. Další metoda Proof Key for Code Exchange (PKCE) chrání pouze Authorization Code Grant. Nasazení uvedených metod je proto do jisté míry bezpečnostním rizikem a je nutné zajistit důkladné ověřování cílových systémů.

Zastaralá kryptoprimitiva nebo metody

V průběhu vývoje se objevilo velké množství návrhů, které nepodporují nové šifrovací algoritmy. Stejně tak došlo k vývoji i u způsobu použití algoritmů a jejich ochran, šířky klíčového materiálu a dalších parametrů. V této části jsou zmiňovány pouze metody, u kterých není možné přejít na aktuální algoritmy nebo odpovídající šířky klíčů. Řadí se zde:
- 9798-U-DSA-SHA1, 9798-M-DSA-SHA1 (použití zastaralých DSA a SHA1).
- 9798-M-ECDSA-SHA1, 9798-M-RSA-SHA1-ENC, 9798-U-ECDSA-SHA1, 9798-U-RSA-SHA1-ENC, SRP, SCRAM-SHA-1, SCRAM-SHA-1-PLUS (použití zastaralé SHA1, algoritmy SRP a SCRAM jsou stále odolné).
- CRAM-MD5, DigestMD5 a Compuserve RPA (zlomená MD5, ale v tomto případě je díky HMAC konstrukci CRAM-MD5 stále odolná).
- PASSDSS, KERBEROS_V4 (zastaralá DES).
- KERBEROS_V (v případě použití zastaralých nebo zlomených DES, 3DES, RC2, RC4) - NMAS_AUTHEN, NMAS_LOGIN (i v případě použití zastaralých a zlomených MD5 a SHA1 algoritmus díky HMAC funkci stále odolává).
- NMAS_SAMBA-AUTH, NTLM, SPNEGO, SPNEGO-PLUS, GS2-*, GSSAPI, GSS-* (při volání NTLM není možné zajistit bezpečnost).
Při použití těchto algoritmů je opět nutné nasadit transportní šifrování. Důvěra v uvedené algoritmy není opodstatněná, jedná se o výběhové algoritmy s omezeným použitím. V případě SPNEGO, SPNEGO-PLUS, GS2-*, GSSAPI, GSS-* pokud je k dispozici pouze protokol KERBEROS-V5 nikoliv NTLM se jedná o rozumnou metodu ochrany. Dalším, podstatným detailem s vlivem na bezpečnost je použití PLUS metody, případně 9798-M-*. Tyto dvě metody zajišťují vazbu na transportní šifrování pomocí SSL/TLS a přidávají další vrstvu ochrany. To může do jisté míry zajistit alespoň omezenou ochranu před rizikem vytvářeným SSL inspekcí.

Poznámky - zastaralá kryptoprimitiva:
- hash funkce MD5, nalezení kolize pod jednu minutu, HMAC konstrukce prozatím v bezpečí.
- hash funkce SHA1, nalezení kolize v řádu dní, HMAC konstrukce prozatím v bezpečí.
- proudová šifra RC4, úspěšný útok lze dle objemu dat realizovat nejrychleji za 12s.
- DES, 3DES mají šířku bloku pouze 64b a mají zranitelnou konstrukci. Útok je dle objemu dat možné realizovat v řádu hodin.
- RC2 má zastaralou konstrukci a jedná se o výběhový algoritmus.
- DSA má zastaralou konstrukci a jedná se o výběhový algoritmus.

Odolnost proti kvantovým počítačům

V rámci SASL existuje jenom několik algoritmů, schopných odolat kvantovým počítačům. Jedná se o metodu KERBEROS_V5 s použitím algoritmů aes256-cts-hmac-sha384-192 a camellia256-cts-cmac. Za určitých podmínek by k uvedenému účelu mohla sloužit i metoda EXTERNAL, pokud by došlo k ověření např. na úrovni SSL/TLS pomocí algoritmů odolných kvantovým počítačům. Vzhledem k možnosti downgrade na slabší ochranné mechanismy je ale spoléhání se na metody jiné vrstvy poněkud nešťastné.
Poznámky - odolnost proti kvantovým počítačům:
- Současné asymetrické algoritmy nejsou schopné odolat kvantovým počítačům.
- Současné symetrické algoritmy mohou odolat kvantovým počítačům v případě délky klíče alespoň 256b.

Metody ochrany přenášených dat (credentials)

Podle použitých algoritmů a schopnosti ochrany přenášených informací je možné rozdělit algoritmy různými způsoby.
- Nepředvídatelnost. Jedním z ochranných mechanismů je použití náhodné výzvy, časové značky nebo počtu přihlášení k změně obsahu přenášených dat. Tím se zajišťuje jistá míra náhodnosti, která může pomoci v ochraně, bohužel není samospasitelná. Jedná se o rozsáhlý seznam metod 9798-M-DSA-SHA1, 9798-M-ECDSA-SHA1, 9798-M-RSA-SHA1-ENC, 9798-U-DSA-SHA1, 9798-U-ECDSA-SHA1, 9798-U-RSA-SHA1-ENC, CRAM-MD5, DIGEST-MD5, EAP-AES128, EAP-AES128-PLUS, ECDH-X25519-CHALLENGE, ECDSA-NIST256P-CHALLENGE, EXTERNAL, GS2-*, GS2-KRB5, GS2-KRB5-PLUS, GSS-SPNEGO, GSSAPI, KERBEROS_V4, KERBEROS_V5, NEGOEXT, NMAS_AUTHEN, NMAS_LOGIN, NMAS-SAMBA-AUTH, NTLM, PASSDSS, Compuserve RPA, SCRAM-SHA-1, SCRAM-SHA-1-PLUS, SCRAM-SHA-256, SCRAM-SHA-256-PLUS, SPNEGO, SPNEGO-PLUS, SRP a SXOVER-PLUS.
- Autentizační vazba mezi serverem a klientem. Dovoluje vazbu na komunikační kanál mezi klientem a serverem. Těchto ochranných mechanismů je minimum. Slouží pro ochranu komunikačního kanálu před únosem v průběhu autentizace. Jedná se o metody PASSDSS, SRP, ECDH-X25519-CHALLENGE a SXOVER-PLUS.
- Oboustranné ověření, které ověřuje nejenom klienta, ale i server ke kterému se přihlašuje. Podmínkou je dostupnost informace, která poskytuje možnost server ověřit. Uvedené technologie se téměř nepoužívají, podporují je pouze metody PASSDSS, SRP, ECDH-X25519-CHALLENGE a SXOVER-PLUS.
- Ochrana před paděláním kanálu pomocí forward secrecy (dopředné ochrany) chrání možností oddělit minulé zprávy od budoucích. Díky tomu není možné na základě znalostí minulých odpovědí útočit na nové přenosy a dešifrovat je. Důkladné zpracování těchto ochran je minimální a jsou podporované pouze na úrovni SSL/TLS.
- Vazba mezi autentizací a přenosovým kanálem jako ochrana před únosem spojení je dostupná pouze pro PLUS metody. Jedná se o metody 9798-M-DSA-SHA1, 9798-M-ECDSA-SHA1, 9798-M-RSA-SHA1-ENC, EAP-AES128-PLUS, GS2-KRB5-PLUS, SCRAM-SHA-1-PLUS, SCRAM-SHA-256-PLUS, SPNEGO-PLUS, SXOVER-PLUS.

Metody ověření platnosti hesel (ověření)

Až na jednu výjimku všechny v současnosti používané metody používají metodu ověření pomocí logických konstrukcí. SRP Zjednodušeně se jedná o podmínku, kdy pokud strana A je shodná se stranou B. Je uživatel vpuštěn do systému. Naproti tomu kryptografický systém podává důkaz schopností dešifrovat určitá data. Pro ověření tak stačí poskytnout důkaz o uvedené schopnosti. Pokud uživatel neposkytne odpovídající odpověď, není do systému vpuštěn. Do jisté míry se jedná o postup podobný ZKP (Zero Knowledge Protokoly). V takovém případě dojde k podání důkazu, který žádným způsobem nesmí poskytnout informace vedoucí k odhalení dat schopný tento důkaz poskytnout. Uvedená věta je náročná na pochopení, ale příkladem je hledání slova v knize. Máte poskytnout důkaz o nalezení konkrétního slova v některé knize podle vašeho výběru bez možnosti, aby protistrana byla schopna určit o jakou knihu nebo stránku teto knihy jde. Řešení je zcela jednoduché. V krabici je vystřižen otvor o velikosti slova a vy tímto otvorem ukážete zvolené slovo. Protistrana se nemá šanci dozvědět název knihy nebo číslo strany. Obdobným způsobem je možné ověřit autentizační informaci. V případě ověřování platnosti hesel je touto výjimkou metodu SRP.

Metody EXTERNAL, GS2-*, GSS-*, GSSAPI, SPNEGO, SPNEGO-PLUS a NEGOEXT

U těchto metod je je obtížné určit jaké mechanismy budou zvoleny, protože dochází nejprve k vyjednávání metod, až teprve později k ověřování hesel. Z uvedených důvodů tak není možné jednoznačně určit bezpečnostní vlastnosti.

Metody OTP, SKEY a SECUREID

Uvedené metody slouží jako podpůrné metody vhodné pro MFA a není možné je použít samostatně. Použité klíčové materiály mají příliš nízkou entropii a je možné je při rozumném počtu pokusů odhalit. Všechny tři metody jsou dostupné jak se starými kryptoprimitivy MD5 a SHA-1, tak s aktuálními verzemi používajícími SHA2-256. Pokud je nutné uvedené technologie využít, je vhodné používat aktuální verze kryptoprimitiv. Vzhledem ke konstrukci je v současnosti možné nasadit OTP za použití TOTP nebo HOTP algoritmů, ale metody SKEY a SECUREID jsou v současnosti překonané. V případě SKEY se jedná o snadný denial attack, protože token bez napájení ztrácí informaci o přechozích iteracích hash funkcí. U SECUREID došlo v historii k několika problémům se synchronizací tokenů, došlo k únikům seedů (generujících informací) a objevilo se několik MITM zranitelností. Časové a čítačové tokeny jsou tímto způsobem zranitelné podstatně více než tokeny typu výzva-odpověď (Challenge-Response), nebo tokeny vyžadující složitější obsluhu. Na druhou stranu je jejich použití extrémně jednoduché. Díky tomu nejsou náročné na obsluhu.

Metody OAUTH, XOAUTH, OAUTH2, OAUTHBEARER, XOAUTH2, OPENID20, SAML

Uvedené metody nejsou v předchozích odstavcích zmiňovány z jednoduchého důvodu. Uvedené algoritmy zajišťují autorizace na základě jednoduchých autentizačních mechanismů. K autentizaci, která je jenom částí služeb, dochází při přesměrování z aplikace. Klient (uživatel) je touto aplikací přesměrován na autentizační server, poskytující ověření identity, dále se používají již jenom tokeny. Uvedené řešení má velké množství výhod i nevýhod, proto je nutné zmínit omezení těchto mechanismů samostatně. Vzhledem ke komplikovanosti protokolu, zvláště v případě OAUTH2 a podobných se objevují výrazná rizika zastřešovaná:
- Session Fixation, chyba dovolující únos autentizovaného spojení. Je založeno na využití stále stejného Session ID. Útočník tak získal oprávnění oběti.
- Slabiny ve zpracování Atentizačního tokenu. dovoluje jeho únos během začátečního vyjednávání. Pro ochranu tokenu je nutné používat jeho šifrování pomocí PKCE (Proof of Key for Code Exchange), neměl by být používán v čistě textovém tvaru. Dále může token uniknout i v případě jeho lokálního uložení u klienta. Pokud je uložen v localStorage, je možné ho získat XSS útokem. Pokud se token předává přímo v URL, typickou ukázkou je ImplicitFlow, je možné ho získat přímo z referrer logů (Implicit flow raději nepoužívat a nahradit ho Authorization Code Flow spolu s PKCE). Jako obranu lze v tomto případě použít SecureCookies, definovat scopes a podobně.
- Neomezená platnost Access Tokenů je evidentně nevhodným přístupem. V případě jejich úniku pak není možné tyto tokeny zneplatnit, případně se jedná o dlouhou dobu. Z praktických důvodů nemá smysl mít platnost tokenu delší než 10-15 minut, v extrémních případech půl hodiny.
- Stejně jako Access Tokeny jsou zranitelné i Refresh tokeny. Měly by být bezpečně ukládány a pravidelně rotovány.
- Chybějící digitální podpisy v JWT tokenu. Tyto tokeny obecně dovolují vůči textovým tokenům výrazně zvýšit bezpečnost komunikace, podmínkou je ale odpovídající využití kryptografie. Z tohoto důvodu je extrémně nevhodné použití algoritmu „none“, dovolující přenos nešifrovaných informací.
- Ovládnutím aplikace. Legitimní aplikace ovládnutá útočníkem dovoluje získat citlivé informace. To je možné využít k útoku na JWT tokeny (JWT_private_key). Uvedená chyba byla nalezena v průběhu roku 2024 a začátkem roku 2025 odstraněna, důsledkem byla i změna způsobu zpracování.
- Maligní aplikace, které se vydávají za oprávněné aplikace dovolují získat Access tokeny. Z uvedeného důvodu je nutné používat registraci klientů (Client Registration), jedná se o informace o používaných aplikacích (ideálně Client ID a secret) a oprávnění požadovat access tokeny.
- Phishing je záležitostí související hlavně s e-maily, ale jeho cílení na konkrétní uživatele dovoluje přístup k ověřovacím údajům. Jedná se zpravidla o chyby na straně uživatelů, proto je nutné používat MFA a zajistit tak odpovídající ověření dalším kanálem. Navíc je vhodné pro klientské aplikace ověřovat cílové servery pro autentizaci, využít například OAUTH state.
V průběhu vývoje došlo pro OAUTH2 k výrazné obměně celé working group se zajímavými důsledky. Uvedená skupina lidí kritizovala nový standard kvůli následujícím problémům, kde většina z nich stále nebyla uspokojivě vyřešena a část z nich bude implementována v připravovaném OAUTH2.1. Uvedené problémy zároveň popisují bezpečnostní slabiny celého systému a dodnes představují významnou kritiku celého standardu. Více v odkazu pod článkem [1].

Autentizace pro OAUTH a XOAUTH

Metody OAUTH a XOAUTH dovolují autentizaci pouze pomocí mechanismů jako je HTTP Basic Authentication, Digest Authentication, případně s možností dodatečné autentizace pomocí OTP či FIDO2. Na základě autentizace jsou dále poskytovány autorizační tokeny. Protože uvedená technologie není schopná zajistit odpovídající ochranu uživatelských hesel, je nutné ji chránit pomocí SSL/TLS. Bohužel ani tato ochrana není dokonalá, protože nedochází k oboustrannému ověření systémů. Z uvedeného důvodu je metoda zranitelná pomocí SSL inspekce (hraniční firewally).
Ochrana proti Relay útoku: Podmínkou je vazba na certifikát serveru (obousměrné ověření pomocí mTLS – Mutual TLS). Proti tomuto typu útoku MFA nebrání.
Ochrana proti Replay útoku: S výjimkou HTTP Basic Authentication je možné se proti replay útoku bránit a MFA tuto obranu podporuje.
Zajištění Forward secrecy: Je možné pouze na úrovni SSL/TLS
Kryptoprimitiva: V případě použití Digest Authentication je možné použít MD5, SHA1 a SHA256, kde MD5 a SHA1 jsou zastaralé.
Bez použití kryptografie: Pro HTTP Basic Authentication žádná kryptoprimitiva použita nejsou, jedná se o čistý plaintext.
Odolnost proti kvantovým počítačům: Možná pouze v případě použití SSL/TLS s podporou mechanismů odolných kvantovým počítačům.
Zero Knowledge Protokoly: Není podpora pro SRP nebo další obdobné mechanismy.

Autentizace pro OAUTH2, OAUTHBEARER, XOAUTH2 a OPENID20

Metody OAUTH2, OAUTHBEARER, XOAUTH2 a OPENID20 dovolují autentizaci pouze pomocí mechanismů jako je HTTP Basic Authentication, Digest Authentication, případně s možností dodatečné autentizace pomocí OTP či FIDO2. Z dnešního pohledu je zastaralým způsobem zaslat jméno a heslo přímo v POST požadavku přímo (Resource Owner Password Credentials). Další, ale vzácnou metodou je zaslat jméno a heslo v šifrovaném JWT, tento způsob se běžně nepoužívá. Na základě některé z uvedených možností autentizace jsou dále poskytovány autorizační tokeny. Protože uvedená technologie není schopná zajistit odpovídající ochranu uživatelských hesel, je nutné ji chránit pomocí SSL/TLS. Bohužel ani tato ochrana není dokonalá, protože nedochází k oboustrannému ověření systémů. Z uvedeného důvodu je metoda zranitelná pomocí SSL inspekce (hraniční firewally).
Ochrana proti Relay útoku: Podmínkou je vazba na certifikát serveru (obousměrné ověření pomocí mTLS – Mutual TLS). Proti tomuto typu útoku MFA nebrání.
Ochrana proti Replay útoku: S výjimkou HTTP Basic Authentication je možné se proti replay útoku bránit a MFA tuto obranu podporuje.
Zajištění Forward secrecy: Je možné pouze na úrovni SSL/TLS
Kryptoprimitiva: V případě použití Digest Authentication je možné použít MD5, SHA1 a SHA256, kde MD5 a SHA1 jsou zastaralé.
Bez použití kryptografie: Pro HTTP Basic Authentication žádná kryptoprimitiva použita nejsou, jedná se o čistý plaintext.
Odolnost proti kvantovým počítačům: Možná pouze v případě použití SSL/TLS s podporou mechanismů odolných kvantovým počítačům.
Zero Knowledge Protokoly: Není podpora pro SRP nebo další obdobné mechanismy.

Autentizace pro SAML

Tato metoda zastřešuje a využívá další metody, takže dokáže pracovat s širokým rozsahem možných mechanismů. Záleží pouze na vlastnostech Identity Providera (IdP, tj. Autentizačního serveru). Jako autentizační server je možné použít následující:
- LDAP, kde LDAP podporuje SASL mechanismy.
- Active Directory (LDAP+DNS+Kerberos), kde AD podporuje primárně KERBEROS.
- Databáze uživatelů v SQL/NoSQL systémech, kde přihlašování využívá nejčastěji HTTP rozhraní a mechanismy TTP Basic Authentication, Digest Authentication, případně s možností dodatečné autentizace pomocí OTP či FIDO2.
- Externí ověřovací systémy (OAuth 2.0, OpenID Connect, Kerberos, RADIUS). OAUTH20 nebo OPENID20 byli zmíněny a KERBEROS je také jasný. U AAA systémů (Authentication, Authorization, Accounting) jako je RADIUS, TACACS+ a DIAMETER záleží na podpoře autentizačních mechanismů. Protože systémy podporují zpravidla EAP mechanismy, je nutné využít brány pro předávání informací (SAML-to-RADIUS, SAML-to-TACACS+, SAML-to-DIAMETER).

I v případě SAML existuje riziko neoprávněného přístupu k datům. Mezi možné útoky patří:
- Assertion Replay attack. Zpráva je zachycena útočníkem a znovu odeslána. Jako prevenci je možné nastavit lifetime pro assertion v řádu jednotek, maximálně desítek minut. Dále striktně využívat nonce a timestamp, mimo uvedené nastavit pro všechny SAML tokeny One-Time Use Policy. Informace o stavu assertion je možné zkontrolovat ve výpisu saml:Conditions NotBefore a NotOnOrAfter.
- Manipulace s assertion. Pokud není assertion digitálně podepsán a šifrován, útočník s ním může manipulovat. Proto by se plaintext assertion neměly vůbec používat. Všechny přenášené informace by měly být šifrovány, podepsány (ideálně včetně metadat) a měly by být přijímány pouze zprávy obsahující validní podpis.
- E-mail forwarding. Jedná se o chybu související s ověřováním atributů v SAML (saml:Attribute), kdy nedostatečná systémová kontrola příslušnosti e-mailu k doméně může vytvořit nepříjemnou situaci. Za určitých podmínek tak může pomocí platného e-mailu první uživatele získat přístup k datům druhého uživatele. Přestože Identity Provider (autentizační server) vrací správné informace, za problém může chybné ověřování na straně Service Provider (SP, zpravidla aplikace).
- XML Signature Wrapping (XSW) Attack. Zpráva je zachycena a modifikována útočníkem, ten přidává upravený element do XML. Tím může dojít k získání odlišných oprávnění nebo jiného uživatelského ID. Ochranou je nastavení strict XPath validation.
- Signature Stripping Attack. Jedná se o chybu nastavení, zprávy je vždy nutné kontrolovat zda obsahují validní podpis. Pokud uvedená kontrola není použita, je možné buď modifikovat a odeslat upravený požadavek, nebo token upravit a necha podpis v původním tvaru.
- SAML Response Spoofing. Zde dochází k vytvoření upravené nové zprávy s odlišnými uživatelskými oprávněními. Pokud nedochází správně k ověřování popisu, je možné získat práva nad rámec definice. Řešením je důsledná kontrola podpisů a Audience Restriction v SAML assertion.
- Relay Attack na SAML Single Logout (SLO). Jedná se o zlomyslný útok, kdy je upraven požadavek na odhlášení. Díky tomu neodhlásí útočníka, ale jiného uživatele. Ochranou je vynucovat Channel Binding a digitální podpis i pro odhlašování a kontrolovat, pro koho jsou požadavky skutečně určeny.
- Account Takeover pomocí SAML Injection. Pokud je možné upravit obsah SAML requestu a aplikace neověřuje důvěryhodnost zdroje, útočník může získat přístup k jiným datům. Proto je nutné validovat všechny atributy a vynucovat digitální podpis.
- Man-in-the-Middle (MITM) Attack. Jedná se pouze o případy, kdy není zpráva odpovídajícím způsobem chráněna. Proto je nutné používat alespoň SSL/TLS.
- Phishing je záležitostí související hlavně s e-maily, ale jeho cílení na konkrétní uživatele dovoluje stejně jako u OAUTH mechanismů přístup k ověřovacím údajům. Jedná se o chyby na straně uživatelů, proto je nutné používat MFA a zajistit tak odpovídající ověření dalším kanálem. A stejně jako u OAUTH je vhodné pro klientské aplikace ověřovat cílové servery pro autentizaci.

Podpora mechanismů na straně jednotlivých knihoven

Součástí přehledu jsou i informace o současné a minulé podpoře mechanismů v některých známých knihovnách. Uvedený přehled může být zajímavým vodítkem v případě výběru. Z dostupných informací je zřejmá nepříjemná situace. Není moc na výběr, hledá se pouze kombinace naplňující alespoň minimální požadavky na bezpečnost ověření.

Závěr

Z hlediska současného nasazení mechanismů je problém jak zajistit odpovídající ochranu. Dostupné technologie dosluhují a jsou zcela nepřipravené na změny okolo roku 2030. Je nedostatek mechanismů zajišťujících oboustranné ověření (tedy ověření strany klienta a serveru), nedostatek technologií zajišťujících ZKP (Zero Knowledge Proof), technologií využívající aktuální kryptoprimitiva případně algoritmy odolné kvantovým počítačům. Kvůli slabinám technologií založených na OAUTH/OAUTH2 je vhodné se jim vyhnout, ale technologie využívající SAML jsou slibné a dovolují na straně systému definovat odpovídající algoritmy a jejich ochranu. Tím se částečně odstraňují jejich slabiny.
Ze současného pohledu má stále ještě smysl používat technologie jako je SCRAM, SRP nebo SXOVER. Z běžně používaných pak KERBEROS_V5 buď přímo nebo přes dostupné interface jako je GSSAPI nebo GS2. Zde bych se přimlouval za odchod od všech NEGO algoritmů, které dovolují fallback na NTLM. Další možností je například SAML, ale jeho konfigurace je extrémně náročná. Odměnou může být v případě vhodně zvolené konfigurace relativně vysoká úroveň zabezpečení. V případě Microsoft prostředí není SAML dostupný přes SSPI, ale je možné ho využít pomocí ADFS (Active Directory Federation Service) nebo AAD (Azure Active Directory).

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.