Autentizace

Autentikace a autentifikace

V češtině se pro autentizaci používají i další synonyma, i když méně častěji: autentikace či autentifikace. Všechny tři termíny zřejmě pocházejí z latinského termínu authenticus a záleží na tom, přes jaký jazyk se k nám dostaly:

• autetikace pochází z anglického authentication
• autentifikace pochází z francouzského authentification

Pěkně o tom píše Dalibor Behún na Intervalu. Použití těchto variant tedy není chybou – aby se však odborná terminologie postupně sjednotila, doporučuje se používat raději slovo autentizace.

Autentizace vs. autorizace

Autentizace se často plete s autorizací, která se však netýká identity uživatele – pouze ověřuje, zda má uživatel oprávnění něco udělat (třeba zobrazit si obsah, smazat jiného uživatele apod.). Autorizace tedy obvykle na autentizaci navazuje:

1. Nejdříve si potvrdíme, že daná osoba je opravdu Jan Štráfelda, za kterého se zadáním loginu vydává.
2. Následně ověříme, že Jan Štráfelda má skutečně oprávnění danou akci vykonat (třeba editovat článek).

HTTP autentizace

HTTP protokol umožňuje vynucení autentizace pomocí speciálních hlaviček. Prohlížeč si pak vyžádá přihlašovací údaje a předá je na server. V moderních aplikacích se však HTTP autentizace už dávno nepoužívá, protože není možné ovlivnit vzhled přihlašovacího formuláře a nedokážeme si také vynutit odhlášení uživatele.

Dvoufaktorová autentizace

Dvoufaktorová, nebo někdy také multifaktorová autentizace (MFA), přináší vyšší úroveň zabezpečení než u běžné autentizace. Znáte to nejspíš z internetového bankovnictví, kde při přihlášování musíte kromě hesla zadat i kód, který vám přijde v SMS zprávě. K potvrzení vaší identity je tedy potřeba další faktor – potenciálnímu útočníkovi již nestačí jen znalost hesla, ale musí mít přístup i k vašemu telefonu.

Obecně platí, že je méně bezpečné, pokud spoléháme na to, že útočník něco neví (tj. nezná heslo), než že něco nemá (zde váš telefon). V angličtině se tomu říká Security through obscurity. Ideální je samozřejmě kombinace obou faktorů. Jako třeba u bankomatu – abyste si mohli vybrat hotovost, musíte mít platební kartu a znát k ní i PIN (= heslo).

Zabezpečení pomocí dvoufaktorové autentizace se doporučuje nejen v online bankovnictví, ale u všech účtů, jejichž napadení pro vás může mít nepříjemné následky. Sem patří zejména přístup do e-mailu (protože na e-mail si můžete nechat zaslat nové heslo), na Facebook či do jiných sociálních sítí, do služeb typu Google Analytics atd. Naštěstí dvoufaktorovou autentizaci umožňuje stále více služeb.

Obvyklé způsoby dvoufázové autentizace

Druhým faktorem může být kromě hesla:

1. Hardwarový klíč

   Ukázky hardwarových klíčů pro dvoufaktorovou autentizaci Typicky jde o malou USB klíčenku, kterou musí uživatel při autentizaci připojit do počítače (např. YubiKey). Případně o malé zařízení zobrazující heslo, které uživatel opíše do počítače.

   Nevýhodou je, že uživatel musí mít daný fyzický předmět stále u sebe. A připojuje-li se zařízení k počítači, musí se umět připojit i k chytrým telefonům, tabletům apod. Také vám sebere jeden USB slot, kterých se třeba na malých noteboocích obecně nedostává. K nevýhodám patří také pořizovací cena zařízení. I proto bezpečnostní tokeny dominují zejména ve firemní sféře.

2. Kód z SMS zprávy

   Pro uživatele poměrně jednoduchý způsob ověřování, protože telefon máme u sebe stále a přečíst si SMS zprávu také umíme. K nevýhodám patří:

   • telefon může mít právě špatný signál či vybitou baterii
   • náklady pro provozovatele aplikace na zasílání zpráv
   • někteří lidé stále mobilní telefon nemají

3. Softwarový klíč

   Stáhnete si do telefonu specializovanou aplikaci, která každých 30 sekund vygeneruje nový bezpečnostní kód. Ten opíšete do příslušného formluáře na webu a jste ověření. Provozovatel neplatí žádné SMS zprávy a vy nepotřebujete mobilní signál.

   K nejznámějším aplikacím generujícím softwarové klíče patří Google Autenticator či LastPass Autenticator.

Nevýhody dvoufaktorové autentizace

Jakákoliv autentizace uživatele zdržuje. Místo, aby se rychle přihlásil kliknutím na tlačítko, musí vyplňovat login a heslo a pak čekat na ověření (moderní hasovací funkce, aby byly bezpečné, potřebují čas). U dvoufaktorové autentizace je to ještě náročnější, připojujete USB flešku, opisujete kód z telefonu nebo ze speciální aplikace, kterou si nejdříve musíte v telefonu nalistovat.

Je tedy pochopitelné, že se uživatelé zavádění vyšších úrovní zabezpečení brání. Zejména pokud internetové bezpečnosti nerozumějí, nebo mají pocit, že jim o žádná důležitá data nejde. Jediné, co v tom můžeme jako vývojáři a manažeři projektů udělat, je snažit se uživatele postupně vzdělávat. Jako já tímto článkem

Komfort uživatelů také může zvýšit koncept RAdAC (z anglického Risk Adaptable Access Control). Myšlenka je jednoduchá: pro přihlášení do účtu si často vystačíme s jedním faktorem. A další ověřovací faktory přidáme ve chvíli, kdy se riziko zvyšuje (třeba se uživatel pokouší přihlásit ze zahraničí, chystá se něco důležitého smazat apod.).

Autentizace pomocí jiných služeb

Komfort autentizace můžeme zlepšit také tím, že místo abychom uživatele aplikace nutili k ověření identity zadáváním jména a hesla, ověříme pouze, že už je přihlášený do nějaké služby třetí strany, které důvěřujeme (protože její prolomení by pak způsobilo potíže i nám) a kterou většina našich uživatelů používá.

Nejčastěji půjde o Google účet či přihlášení do Facebooku. Záleží ale na cílové skupině naší internetové aplikace. U vývojářů může jít například o GitHub, BitBucket, apod.

Autentizace pomocí biometrických údajů

Nová kategorie autentizace, která se postupně stále více rozšiřuje, jak se zvyšuje důraz na bezpečnost. Kromě toho, že něco vím (heslo) a něco mám (hardwarový token, telefon…) se mohu prokázat i tím, že něco jsem (člověk se specifickými vlastnostmi).

Spadá sem tedy například:

• autentizace pomocí otisků prstů (u dražších notebooků už je běžná)
• autentizace pomocí skenů duhovky či sítnice
• autentizace pomocí tónu a rytmu hlasu

Tady někde zřejmě leží budoucnost autentizace.

Implementace autentizace

Pokud vyvíjíte na zelené louce webovou aplikaci, která má autentizaci umožnit, jde o poměrně náročný a složitý proces. I u základního ověření identity musí vývojáři vyřešit následující problémy:

• jak se uživatel do naší aplikace dostane (registrace, založí ho jiný uživatel...)
• jak získáme jeho heslo (při registraci ho nejspíš zadá, ale zakládá-li ho jiný uživatel nebo importujeme-li ho z nějaké databáze?)
• ukládání hesla uživatele bezpečným způsobem (aby se k němu nedostal například správce serveru nebo útočník, který databázi s hesly odcizí)
• možnost uživatele změnit si heslo (pokud ho třeba zapomněl)
• možnost uživatele změnit si login (jde-li například o pracovní e-mailovou adresu)
• předávání informace mezi stránkami aplikace o tom, že již identitu uživatele známe (aby se nemusel logovat na každé stránce)
• mechanismus, který zabrání opakovaným pokusům uživatele o ověření, tj. například povolíme jen 6 pokusů za hodinu (aby nešlo prolomit autentizaci hrubou silou, třeba postupným zkoušením různých slov ze slovníku)
• odhlášení uživatele (po nějaké době nečinnosti či přímo kliknutím na odhlašovací tlačítko)
• vynucení změny hesla uživatele či odhlášení všech uživatelů (třeba při zjištění nějakého bezpečnostního problému)
• možnost zrušení účtu (třeba kvůli GDPR)

Celé je to ještě mnohem složitější. Už jen možnost změnit si heslo vyžaduje nejméně tři kroky:

1. Uživatel zadá do formuláře svůj e-mail. My mu však nemůžeme vygenerovat nové heslo a poslat mu ho do mailu, protože e-mail není šifrovaný. Vytvoříme mu tedy adresu specifickou přímo pro něj a tu mu pošleme do mailu.
2. Na dané adrese mu zobrazíme formulář, do kterého může zadat nové heslo.
3. Platnost této adresy je třeba omezit na určitou dobu (aby uživateli nemohl heslo změnit například člověk, který se k dané adrese dostane po delší době).

Vidíte, kolik je toho třeba promyslet? A co teprve, pokud budeme chtít umožnit také autentizaci dvoufaktorovou nebo třeba zároveň využít autentizaci pomocí přihlášení k Facebooku.

Uživatelská přívětivost autentizace

A to se na problém stále díváme jen z pohledu vývojáře. Vše také bude nutné domyslet z hlediska uživatele aplikace – aby to celé pochopil a přesně věděl, co má udělat. A také, aby to neohrozilo cíle aplikace. Například, nutíme-li uživatele e-shopu, aby si vytvořil heslo k účtu, nesnižujeme tím pravděpodobnost, že nákup dokončí?

Až zase budete do zadání psát jednoduchý bod „přihlášení uživatele“, vzpomeňte si na tento článek. A vyhraďte si dostatek času na to, vše důkladně promyslet a s vývojáři řádně prodiskutovat.