Rozbor SASL, první díl

Jedná se o síťovou autentizační vrstvu, kterou si stále velké množství lidí plete s crypt interface (lokální autentizační metody). V současnosti poskytuje pár desítek metod, ale je zde jeden závažný problém. Díky množství metod a vývoji kryptografie je náročné porovnat míru bezpečnosti jednotlivých metod. Dalším nepříjemným faktem je obtížnost vůbec dohledat porovnání bezpečnosti těchto metod. Tento článek má za účel takové porovnání nabídnout.

Co je to SASL (Simple Authentication and Security Layer)

Nejčastější otázka, k čemu mi ten SASL vlastně je. Je to jednoduché. Jedná se o jeden ze základních mechanismů poskytujících nástroje k ověřování uživatelů. Původně se používal hlavně pro účely poštovních serverů, tedy zajišťoval autentizaci POP3, IMAP4 a SMTP protokolu. A i nadále se tu používá. Později byl tento protokol implementován pro ověřování do protokolů jako je LDAP (adresářové služby), XMPP (komunikační nástroje), ale je možné ho využít i na dalších místech. Jednou z mnoha méně známých možností je například jeho podpora v někteých implementacích VNC (Virtual Network Computing), což je program pro přístup ke vzdálené ploše.
Co k němu říct dalšího? Dle Wikipedie se jedná o ‘...obecnou metodu pro ověřování v protokolech klient/server. Jejím hlavním účelem je ověřování klientů na serverech. SASL má několik ověřovacích mechanismů pro výměnu ověřovacích informací (obvykle označené jako přihlašovací údaje) a ověřovací systém pro uložení informací o uživatelích. Ověřovací mechanismus SASL řídí výzvy a odpovědi mezi klientem a serverem a to, jak by měly být kódovány při přenosu. Ověřovací systém označuje to, jak server ukládá a ověřuje data.‘ Použité metody jsou standardizované dle IETF (RFC 2222, RFC 4422 a podpůrné RFC 2245, RFC 2595, RFC 2831, RFC 4505, RFC 4616, RFC 5801, RFC 6631, RFC 7677) mají vlastní registry algoritmů IANA a otevřenou implementaci. Implementovány jsou například v rámci Cyrus SASL, GNU SASL, Java SASL a dalších knihovnách.

Historie SASL

Důvodem pro vznik byla krajně neuspokojivá situace při ověřování uživatelů poštovních systémů. Přestože v té době existovaly už více rozvinuté mechanismy, zpravidla se pro přístup k poště využívaly algoritmy jako je PAP, CHAP, MSCHAP, případně další mechanismy jako je APOP. Tyto mechanismy jsou součástí úvodního článku.
První verze SASL, ale ještě ne pod tímto označením, vznikla v roce 1993 na Carnegie Mellon University jako projekt Cyrus (Kýrós). Tento projekt byl pojmenován po perském králi Kýrovi Velikém, který byl historicky známý svým systémem královských cest a poštovních kurýrů, což výrazně podpořilo ekonomiku země (Kýrem se patrně později inspirovali i Římané). Systém poštovních kurýrů lze do jisté míry považovat za předchůdce komunikačních systémů. Cílem tohoto projektu bylo vytvořit univerzální autentizační rámec a oddělit autentizační mechanismy od komunikačních protokolů, jako autoři se nejčastěji udávají Rob Siemborski a John Gardiner Myers. Autorem původní specifikace byl právě J. G. Myers, ta byla později schválena IETF jako RFC 2222. Uvedená doporučení byla v souladu s návrhem, drobné rozdíly dané formalizací algoritmů byly v Cyrus SASLv1 dopracovány. Po necelých deseti letech došlo k první významné změně, nový dokument vytvořili Alexey Melnikov a Kurta D. Zeileng (RFC 4422) a vznikl SASLv2.

Rozdíly mezi verzemi

Mezi první a druhou verzí SASL jsou základní rozdíly, které je možné shrnout několika větami do následujícího odstavce. SASLv1 měl monolitickou strukturu, kterou bylo obtížné rozšiřovat a několik vestavěných mechanismů (Anonymous, LOGIN, PLAIN a dále Digest-MD5, CRAM-MD5). Druhá verze měla architekturu modulární, je zde podpora pro metody GSSAPI, EXTERNAL a SCRAM. Zatímco první verze podporovala hlavně protokoly pro poštovní služby, jako je IMAP, POP3, SMTP a později i LDAP, druhá verze se snaží být univerzálním rozhraním. Jsou zde i další rozdíly, například první verze nepodporovala zajištění integrity, podporovala pouze kryptografické mechanismy poplatné době vzniku a podobně.

Přehled termínologie

V rámci rozboru se používají následující termíny a způsoby hodnocení, které specifikují výhody a nevýhody jednotlivých algoritmů.
- Channel Binding je technologie zajišťující vazbu mezi autentizačním mechanismem a komunikačním protokolem. Cílem je chránit spojení před únosem, nebo alespoň zajistit základní ověření na počátku spojení.
- Realms znamená oblast, v IT světě označuje například DNS doménu nebo nebo doménu služeb, ve které je poskytována určitá služba.
- Kryptoprimitiva poskytují přehled používaných algoritmů. Zmíněny jsou z dnešního pohledu zastaralé mechanismy, které jsou na současné úrovni akceptovatelné a které budou výhledově bezpečné.
- Počet stran specifikuje kolik stran se účastní ověření uživatele. U běžných mechanismů dochází k ověření na cílovém serveru (tedy klient a server), ale existují mechanismy, kde ověření zajišťuje třetí strana (klient, autentizační server a server služby). V takovém případě pak dochází buď k poskytnutí ověřené identifikace uživatele cílovému serveru (zpravidla token), případně token může obsahovat i autorizační informace (kam všude má uživatel přístup).
- PQC/QRC informují, zda je mechanismus odolný kvantovým počítačům (Post Quantum Cryptography nebo Quantum Resistant Cryptography)
- ZKP. Pod tímto pojmem jsou myšleny Zero Knowledge Protokoly. Ve zkratce se jedná o protokol, který v průběhu informace dovolí ověření hesla bez poskytnutí informací, které by mohly vést k jeho odhalení.
- Podpora crypt je víceméně doplňková informace a více na toto téma je v samostatném odstavci.
- Tokenizace úzce souvisí s počtem komunikujících stran, ale není podmínkou.
- Jedinečnost popisuje přenášené autentizační informace. Ta by měla být jedinečná (neopakovatelná), náhodná a nepředvídatelná. Zajistit splnění všech třech parametrů je obtížné.
- Ochrana informací o účtu (Credentials) je důležitou součástí autentizace. Ve valné většině dochází k ochraně hesla, ale objevují se algoritmy schopné chránit i jméno uživatele, případně oblast (realms)
- Ochrana proti Replay je dnes víceméně základní součástí autentizace. Při každém přihlášení musí dojít k použití ověření takovým způsobem, aby nebylo možné uvedenou informaci znovu použít. V jiném případě může útočník informaci zachytit a přihlásit se.
- Ochrana proti Relay je podstatně náročnější disciplínou. Pro zajištění ochrany před předáním informace (příkladem může být server útočníka vydávající se za server poskytovatele) musí být zajištěna kontrola kam se uživatel připojuje, tedy musí dojít k oboustrannému ověření. Tato technologie je bohužel velice málo používána.
- Ochrana proti únosu (Hijack) spočívá v navázání autentizačních informací na komunikační kanál. Cílem je chránit před možností unést spojení na stroj útočníka. Opět, tyto metody nejsou často používány ke škodě vlastníků. Velice úzce souvisí s Channel Binding, bohužel se nejedná o synonyma.
- Ochrana proti padělání (Forge) do jisté míry zahrnuje předchozí termíny. Jedná se o ochranu před útočníkem, který má za cíl padělat přihlášení uživatele.
- Podpora MFA je dnes součástí mantry, která má zajistit vyšší bezpečnost. To je pravdivé v případě použití různých komunikačních kanálů (OOB - Out of band), ale diskutabilní v případě použití jediného.
- Ochrana integrity spočívá v implementaci některé z MAC technologií (Message Authenticity Code), tedy kryptografický kontrolní součet. Mimo termínu MAC se používá termín MIC (Message Integrity Check), ICV (Integrity Code Verification)
- Použitá ochrana kanálu – autentizační kanál používá interní šifrování, volitelné transportní šifrování, používá povinně transportní šifrování, nebo používá šifrování mezi koncovými body (E2EE, zpravidla nad transportním šifrováním jako ochranu před SSL inspekcí)

Vztah SASL a crypt interface

Na první pohled je mezi SASL a crypt jednoduchý vztah, výstupy některých funkcí mohou vypadat podobně. Proč je ale nelze zaměnit? Mohou mít podobný výstup, tedy identifikátor, počet rund, sůl, výstupní hash … tím ale veškerá podoba končí. Mezi těmito dvěma metodami není žádný vztah, pro některé algoritmy je ale možné na straně serveru použít ověření proti lokální databázi hesel v ve formě zajišťované metodou crypt (více k tomuto tématu v článku "Ukládání hesel pomocí Crypt interface"). Jedná se o metody PLAIN, LOGIN, CRAM-MD5 a za určitých podmínek např. GS2/GSS-API/SPNEGO/Kerberos, případně EXTERNAL nebo OTP. Ostatní algoritmy uvedený postup nepodporují a i u těchto metod je nutné chápat jak přesně pracují a zda je možné tyto mechanismy použít. Případně, zda nebude jejich nasazení implementačně a architektonicky závislé. Z uvedeného důvodu je tak často podstatně bezpečnější nechat mechanismus SASL používat vlastní databázi, která není se systémovou nijak spojena.

Přehled SASL metod, které jsou součástí rozboru

Při inicializaci spojení je zvolena konkrétní metoda, na základě této volby probíhá další ověřování uživatele. Volba probíhá zasláním následujících informací:
AUTHENTICATE SASL [Metoda]

Vysvětlení vztahů mezi GS2, GSSAPI, SPNEGO a Kerberos

Uvedené metody mají vcelku komplikované vazby, dané jejich návrhem a obecnou funkcí.
Kerberos. Patrně nejjednodušší metodou je Kerberos, který možné brát jako samostatný autentizační mechanismus.
GSSAPI (Generic Security Services Application Programming Interface) není vlastně nic jiného, než rozhraní pro autentizaci, kde je nejčastějším protokolem právě Kerberos. Důvod byl vcelku prozaický, dodnes neexistuje standardizované rozhraní pro Kerberos a uvedené rozhraní zajišťuje GSSAPI. Časem uvedené API začalo podporovat i metodu SPNEGO. Využití v SASL je zajímavé tím, že SASL je API, které zde využívá další API.
SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) je mechanismus z prostředí operačních systémů Microsoft, který využíval NTLM (přeaněji NTLMv1 a NTLMv2) a Kerberos pro autentizaci proti Active Directory. V prostředí Microsoft je SPNEGO součástí SSPI (API pro SPNEGO a další mechanismy), SPNEGO může využívat GSSAPI jako jeden z mechanismů. Zároveň GSSAPI může SPNEGO používat jako jeden ze svých mechanismů. Je to trochu zamotané, ale tak to bylo navrženo.
GS2 (Generic Security Service Mechanism for SASL) využívá GSSAPI jako rozhraní pro autentizaci, Kerberos je zde jedním z možných autentizačních mechanismů.

Nekompletní přehled metod (předchůdci SASL)

Mimo níže uvedené metody se používaly ještě další způsoby ověřování. Zpravidla záleželo na způsobu komunikace, tedy zda byly využívány sériové linky (UUCP, SLIP, PPP …) nebo čisté síťové spojení přes TCP/IP. Uvedené metody jsou zastaralé a jejich využitelnost je obtížná, jsou uvedeny pouze z dokumentačních důvodů.

PAP (Password Authentication Protocol)
Jedná se prakticky o metodu BASIC (viz. dále), kdy klient odesílá na server žádost o ověření nešifrovaným způsobem.

CHAP (Challenge Autentication Protocol)
Jedná se o mírné vylepšení metody, kdy klient odesílá požadavek o přihlášení uživatele, server mu na odpověď poskytne výzvu a klient odpovídá hashí na ID zprávy, heslem a výzvou.
Server → Client: C_S
Client → Server: MD5(ID||Password||C_S)

APOP (Auhtentization before POP)
Jedná se o protokol specifický pouze pro POP3, tedy protokol určený pro stahování pošty.
Server → Client: C_S
Client → Server: MD5(Password||C_S)

Rozbor metod

Vlastní SASL metody, které jsou součástí přehledu obsahují vždy část věnující se popisu algoritmu, kryptografickému zápisu a zhodnocení. V současnosti má většina uvedených algoritmů spíše historický význam, proto je nutné zvážit význam jejich nasazení v produkčním prostředí.

9798-U-DSA-SHA1, 9798-U-ECDSA-SHA1, 9798-U-RSA-SHA1-ENC

9798-U-algoritmus je algoritmus pro jednosměrné (Unilateral) ověření pomocí certifikátů, kdy se ověřuje klient proti serveru, ale nedochází k ověření serveru. Autentizační algoritmus dovoluje využití algoritmů DSA, ECDSA a RSA.

Server → Client: Challenge S_A
Client → Server: TokenC(C_A||Client Certificate||DSA-(S_A||C_A))

S_A, C_A – Náhodná výzva serveru a klienta, musí se jednat o jedinečnou hodnotu.

Channel Binding: Ne
Realms: Ano
Kryptoprimitiva: Zastaralá (SHA1, DSA), výběhová (RSA)
Účastníků autentizace: 2
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Ne
Tokenizace: Ne
Jedinečnost: Ano
Ochrana credentials: Ne
Ochrana proti Replay: Ano
Ochrana proti Relay: Ne
Ochrana proti Hijack: Ne
Ochrana proti Forge: Ano
Podpora MFA: Ne
Ochrana integrity: Ne
Typ šifrování: Interní

9798-M-DSA-SHA1, 9798-M-ECDSA-SHA1, 9798-M-RSA-SHA1-ENC

9798-M-algoritmus je algoritmus pro obousměrné (Mutual) ověření pomocí certifikátů, kdy se ověřuje jak klient proti serveru tak server vůči klientu. Autentizační algoritmus dovoluje využití algoritmů DSA, ECDSA a RSA.

Server → Client: Challenge S_A
Client → Server: TokenC(C_A||Client Certificate||DSA-(S_A||C_A)||Optional I_C)
Server → Client: TokenS(S_B||Server Certificate||DSA-(S_A||C_A||S_B)||Optional I_S)

S_A, S_B, C_A - Náhodná výzva serveru a klienta, musí se jednat o jedinečnou hodnotu.
I_S, I_C - Identifikátor serveru a identifikátor klienta

Channel Binding: Ne
Realms: Ano
Kryptoprimitiva: Zastaralá (SHA1, DSA), výběhová (RSA)
Účastníků autentizace: 2
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Ne
Tokenizace: Ne
Jedinečnost: Ano
Ochrana credentials: Ne
Ochrana proti Replay: Ano
Ochrana proti Relay: Ano
Ochrana proti Hijack: Ano
Ochrana proti Forge: Ano
Podpora MFA: Ne
Ochrana integrity: Ne
Typ šifrování: Interní

Anonymous

Anonymní spojení bez hesla, podmínkou je volba jména anonymous.

Channel Binding: Ne
Realms: Ne
Kryptoprimitiva: Ne
Účastníků autentizace: ?
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Ne
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: Ne
Ochrana integrity: Ne
Typ šifrování: Ne

PLAIN

Jedná se o textovou informaci o uživatelském jménu a heslu. Uvedené informace jsou zasílány v otevřeném textu (PLAIN), bez jakékoliv ochrany. Použití transportního šifrování je sice nezbytnou, ale nikoliv dostatečnou metodou ochrany, protože v případě SSL inspekce dochází k získání těchto autentizačních informací.

Client → Server: (username||0x00h||password||0x00h)

Channel Binding: Ne
Realms: Ne
Kryptoprimitiva: Ne
Účastníků autentizace: 2
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Ano
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: Ne
Ochrana integrity: Ne
Typ šifrování: Ne, nezbytné

LOGIN

Jedná se opět o textovou informaci o uživatelském jménu a heslu. V tomto případě se jedná o dvě výměny mezi serverem a klientem, klient odesílá kódovaná data. Uvedené informace pouze zakódované pomocí BASE64 (kódování 4B do 6B tak, aby byly výsledkem vždy tisknutelné znaky z rozsahu 7-bit ASCII), ale jinak bez jakékoliv ochrany. Použití transportního šifrování je sice nezbytnou, ale opět nedostatečnou metodou ochrany, protože v případě SSL inspekce je také možné získat autentizační informace.
Podobnou metodou přihlašování je metoda BASIC u webových serverů, kde je ale řetězec "username:password" zakódován pomocí BASE64 a zaslán jako odpověď na autentizační požadavek serveru.

Server → Client: Username:
Client → Server: Base64(username)
Server → Client: Password:
Client → Server: Base64(password)

Channel Binding: Ne
Realms: Ne
Kryptoprimitiva: Ne
Účastníků autentizace: 2
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Ano
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: Ne
Ochrana integrity: Ne
Typ šifrování: Ne, nezbytné

CRAM-MD5

Jednoduchá ochrana přihlašovacích informací na základě náhodné výzvy a hash algoritmu MD5. Klient a server sdílí heslo nebo hash hesla, v tomto případě je uvažováno heslo.

Server → Client: C_S
Client → Server: HMAC-MD5(Password, C_S)

Channel Binding: Ne
Realms: Ne
Kryptoprimitiva: Zastaralá (MD5)
Účastníků autentizace: 2
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Může být využito
Tokenizace: Ne
Jedinečnost: Ano
Ochrana credentials: Heslo
Ochrana proti Replay: Ano
Ochrana proti Relay: Ne
Ochrana proti Hijack: Ne
Ochrana proti Forge: Ne
Podpora MFA: Ne
Ochrana integrity: Ne
Typ šifrování: Interní

DIGEST-MD5

Jednoduchá ochrana přihlašovacích informací na základě náhodné výzvy a hash algoritmu MD5. Klient a server sdílí heslo nebo hash hesla, v tomto případě je uvažováno heslo.

Server → Client: C_S
Client → Server: MD5(MD5(username||realm||password)||C_S||C_C)||C_S||Auth)||C_C

Kde pro přihlašování se užívá : Auth=method||URI
Pro integritu je užití podobné: Auth=MD5(message)

Channel Binding: Ne
Realms: Ano
Kryptoprimitiva: Zastaralá (MD5)
Účastníků autentizace: 2
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Ne
Tokenizace: Ne
Jedinečnost: Ano
Ochrana credentials: Heslo
Ochrana proti Replay: Ano
Ochrana proti Relay: Ne
Ochrana proti Hijack: Ne
Ochrana proti Forge: Ne
Podpora MFA: Ne
Ochrana integrity: Ne
Typ šifrování: Interní

PASSDSS

Password-based Secure Device Authentication je mechanismus pro ověření uživatele vytvořený za pomoci DES algoritmu. Existuje jak ve verzi PASSDSS-DES-1 tak ve verzi PASSDSS-3DES-1 a sloužil pro ověření pomocí SSH klíčů založených na algoritmu DSA. Na začátku došlo k výměně informací, které byly podepsány DSA klíči pro zajištění důvěryhodnosti. Přenášená informace byla využita pro odvození kílčového materiálu, který byl šifrován uživatelským heslem. Při tvorbě autentizační informace došlo u zprávy k tvorbě neúplného kontrolního součtu otevřeného textu, šifrován je celý výsledek včetně MAC. Struktura algoritmu je z dnešního pohledu komplikovaná.

Client: SharedSecret=DHPublicKey_Client=g^{PrivKey_Client}
Server: SharedSecret=DHPublicKey_Server=g^{PrivKey_Client}
Client → Server: Request
Server → Client: DSA Public Key_Server||DSASignature(Key_Server,C_Server)
Client → Server: DSA Public Key_Client||DSASignature(Key_Client,C_Client)
Client:
- K=Public Key_Server^{PrivKey_Client}
- cs-encryption-iv = SHA1( K || "A" || H )
- sc-encryption-iv = SHA1( K || "B" || H )
- cs-encryption-key-1 = SHA1( K || "C" || H )
- cs-encryption-key-2 = SHA1( K || cs-encryption-key-1 )
- cs-encryption-key = cs-encryption-key-1 || cs-encryption-key-2
- sc-encryption-key-1 = SHA1( K || "D" || H )
- sc-encryption-key-2 = SHA1( K || sc-encryption-key-1 )
- sc-encryption-key = sc-encryption-key-1 || sc-encryption-key-2
- cs-integrity-key = SHA1( K || "E" || H )
- sc-integrity-key = SHA1( K || "F" || H )
- data=AuthID||DSA Public Key_Client||DSA Public Key_Server||mask||buffer)
- MAC=HMAC-SHA-1(cs-integrity-key, data)
Client → Server: Enc-3DES-CBC(cs-encryption-key, mask||buffer||passphrase, IV=cs-encryption-iv)||MAC

Channel Binding: Ne
Realms: Ne
Kryptoprimitiva: Zastaralá (DES, 3DES, SHA-1, DSA, DH)
Účastníků autentizace: 2
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Ne
Tokenizace: Ne
Jedinečnost: Ano
Ochrana credentials: Heslo
Ochrana proti Replay: Ano
Ochrana proti Relay: Ne
Ochrana proti Hijack: Ne
Ochrana proti Forge: Ne
Podpora MFA: Ne
Ochrana integrity: Ne
Typ šifrování: Interní

Compuserve RPA (non-standard)

Compuserve Remote Passphrase Authentication je proprietární mechanismus z poloviny 80. let. Původně byl používán pro ověření uživatelů do sítě CompuServe, díky tomuto mechanismu a širokému rozšíření byl později zahrnut do SASL knihovny. V současnosti je již na ústupu, jeho bezpečnostní vlastnosti jsou ze současného pohledu nedostatečné.

Client → Server: Request||Username
Server → Client: List of identities
Client → Server: ID||Username||Service
Server → Client: C_Server||Timestamp
Client → Server: C_Client
Client → Server: Response_Client=MD5(Password 128b||Padding 48B||Username||Service||ID||C_Client||C_Server||Timestamp||Password 128b)
Server → Client: Response_Server=MD5(Service Password 128b||Padding 48B||Username||Service||ID||C_Client||C_Server||Timestamp||Response_Server||Service Password 128b)

Channel Binding: Ne
Realms: Ano
Kryptoprimitiva: Zastaralá (MD5)
Účastníků autentizace: 2
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Ne
Tokenizace: Ne
Jedinečnost: Ano
Ochrana credentials: Heslo
Ochrana proti Replay: Ano
Ochrana proti Relay: Ne
Ochrana proti Hijack: Ne
Ochrana proti Forge: Ne
Podpora MFA: Ne
Ochrana integrity: Ne
Typ šifrování: Interní

SRP

Secure Remote Password patří starší, ale velice kvalitní autentizační mechanismy v rámci návrhu původního SASL. Využívá modulární aritmetiku pro šifrování jednorázového výstupu hesla. Tento mechanismus může být stále na některých platformám dostupný jako SRP nebo PAKE a přes jeho stáří vyniká kvalitou. Z dnešního pohledu mu je možné vytknout některé detaily, v současnosti bych doporučil jeho nahrazení algoritmem OPAQUE, SESPAKE (RFC 8133), SPAKE2+ (RFC 9383). Bohužel uvedené algoritmy nejsou v rámci SASL dostupné.

Client:
- Random R
- A=g^R mod p
Client → Server: Username||A
Server:
- Random R
- Salt S ze souboru s uloženými hesly
- Validátor V je výsledek jednosměrného uložení hesla
- B=(V+g^Q) mod p
Server → Client: B||S
Client:
- Password
- H=SHA-1(S||SHA-1(Username|":"|Password))
- T=(B-g^H)^{(R+Username*H)} mod p
- W=SHA-1_Interleave(T)
- M=SHA-1(SHA-1(p) xor SHA-1(g)||SHA-1(Username)||S||A||B||W)
Client → Server: M||K
Server: Z=H(A||M||K)

Channel Binding: Ne
Realms: Ne
Kryptoprimitiva: Zastaralá (SHA-1)
Účastníků autentizace: 2
PQC/QRC: Ne
ZKP: Ano
Podpora crypt interface: Možná
Tokenizace: Ne
Jedinečnost: Ano
Ochrana credentials: Heslo
Ochrana proti Replay: Ano
Ochrana proti Relay: Ne
Ochrana proti Hijack: Ano
Ochrana proti Forge: Ano
Podpora MFA: Ne
Ochrana integrity: Ano
Typ šifrování: Interní

Přehled

Tento díl se věnoval hlavně historii a základním mechanismům, které jsou spojeny s historií autentizačních mechanismů. Do této historie byly zahrnuty mechanismy využívající asymetrické kryptografie z prvních míst seznamu. V dalších dílech budou rozebrány ostatní mechanismy využívající architekturu klient-server. Ostatní mechanismy, které využívají více stran budou rozebrány v dalších dílech. Pokračování je v článku SASL díl druhý.

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.