Jim Fenton je nezávislým konzultantem v oblasti informační bezpečnosti. Zajímá ho především digitální identita uživatelů a soukromí na internetu. Je také jedním z poradců NIST (National Institute of Standards and Technology) a je spolutvůrcem nového standardu pro přihlašování, který byl publikován před dvěma lety. Právě o tomto tématu přijel přednášet do Prahy v rámci Informatických večerů FIT ČVUT. Přednáška byla zaznamenána díky AVC ČVUT, k dispozici je i kompletní prezentace.
Zmínený standard NIST SP 800–63–3 je určen hlavně pro americké vládní organizace, ale řídí se jím spousta lidí po celém světě. Zaměřuje se na vývojáře či designéry, kteří potřebují, aby se k jejich aplikaci přihlašovali uživatelé. Chceme, aby měli uživatelé s přihlašováním dobrou zkušenost. Nejen aby byli šťastní, ale aby kvůli špatné zkušenosti nezačali být kreativní a nehledali zkratky. Když to začnou uživatelé dělat, není to dobré pro ně ani pro bezpečnost.
Kdo je náš uživatel?
Musíme také mít realistická očekávání. Hesla samotná nemohou zajistit dostatečnou bezpečnost. Pokud děláte něco citlivého, je potřeba nasadit druhý faktor – telefon, nějaké USB zařízení a podobně. Hesla jsou ovšem stále pro některé aplikace dostatečná a ještě nějakou dobu se bez nich určitě neobejdeme. Měli bychom ale maximum zátěže přenést na ověřovatele hesla, ne na uživatele. O bezpečnost se do velké míry může postarat server a nemusí mít na uživatele spoustu požadavků, které stejně nezvyšují bezpečnost a jen obtěžují. Stále dokola vidím spoustu služeb, které mají na uživatele zbytečné obtěžující požadavky. Tomuhle se musíme vyhnout.
Celý proces přihlašování by se měl zaměřit na legitimního uživatele, který má mít možnost se přihlásit. Často se zapomíná na to, že není cílem jen odradit útočníka. Proces musí být co nejjednodušší pro oprávněného uživatele a zároveň co nejsložitější pro toho falešného.
Uživatelé jsou obvykle velmi různorodí: lidé mluvící různými jazyky, uživatelé s postižením, studenti, senioři a další. Musíme stále myslet na to, kdo jsou naši uživatelé. Je možné, že ti, na které myslíme nejméně, od nás potřebují nejvíce pomoci.
Co je to heslo?
Za heslo je možné považovat celou řadu různých sekvencí, kterým standard NIST říká souhrnně „zapamatovatelné tajemství“. Zjednodušeně se jim říká hesla, ale může jít o frázi, PIN, nějaký druh informace a podobně. Říkejme tomu heslo, ale zahrnuje to všechny tyhle možnosti. Název nás nesmí omezovat v rozhledu, abychom si nemysleli, že musí jít například o jedno slovo (pass-word).
Při přemýšlení nad bezpečnými hesly je potřeba se na problém podívat z perspektivy útočníka. Co může udělat ten, kdo se chce do našeho systému dostat neoprávněně? Může jít o hádání během online útoku, offline útok po úspěšném útoku na ověřovatele, či sofistikované zneužití postranních kanálů. Útočník se může zaměřit na konkrétního člověka, obvykle někoho důležitého. Nebo je mu jedno, do kterého účtu se dostane. Může tak jít o přesně zaměřený či plošný útok, jehož cíle budou jiné.
Online útok
Online útok se zaměřuje na hádání hesla v živém systému. Může jít o útok hrubou silou, kdy útočník zkouší použít známá hesla a prostě je uhádnout. Může také využít toho, že mnoho uživatelů používá stejná hesla na mnoha místech. To je jedna z nejnebezpečnějších praktik. Občas se mě známí ptají, co mají dělat pro zvýšení bezpečnosti. První věc, kterou jim říkám, je: nepoužívejte stejná hesla na více místech.
Uživatelé se někdy snaží používat různé triky jako obměnu názvu služby přidáním vlastních znaků. Tohle nefunguje, útočníci už všechny tyhle triky viděli a znají je. Mnohem lepší je použít správce hesel, který za vás vhodný řetězec vymyslí a zapamatuje si ho. Zvolte si dobrého správce hesel.
Proti online útoku se může služba bránit několika způsoby: může omezit počet pokusů v čase, bránit v používání nejběžnějších hesel nebo může pracovat na tom, aby uživatelé nepoužívali hesla z různých služeb. Tady pomůže především osvěta.
Offline útok
Offline útok je hodně odlišný. Co udělá útočník, pokud se mu podaří překonat ochrany a dostat se do vašeho systému? Bude se snažit co nejrychleji získat citlivá data včetně hesel. Ta by měla být uložena tak, aby nebylo možné hesla jednoduše získat. Nabízí se nejrůznější hašovací funkce, ale není to tak jednoduché, jak se může na první pohled zdát. Heslo může být uloženo na první pohled bezpečně, ale útočníci mají k dispozici velké množství výkonného hardware. Navíc už mají data u sebe, takže mohou vyzkoušet neomezený počet pokusů. Mají tak mnohem vyšší šanci, že vaše heslo uhádnou.
Proti offline útokům je možné se bránit dostatečně dobrým hašovacím algoritmem náročným na paměť či čas nebo ochranou hašů samotných. Obrana proti offline útokům je vždy mnohem složitější, dejte si pozor na to, jak ukládáte hesla.
Délka hesla
Prodloužení hesla je nejspolehlivější způsob, jak zvýšit jeho odolnost. Pokud zvolíte heslohesloheslo místo prostého heslo, asi to moc nepomůže. Ale obecně, čím více znaků k heslu přidáte, tím bude bezpečnější. Nabízí se tedy možnost donutit uživatele vymyslet alespoň 24znakové heslo. Tohle není nutné a povede to jen k tomu, že uživatelé začnou být kreativní a budou se snažit omezení jednoduše obejít. Ať už tím, že zvolí opakující se slova nebo si heslo napíší na papírek a přilepí na monitor. Twitter je plný fotek lidí s hesly přilepenými k monitoru, to není dobré.
Mnohem lepší je přimět uživatele, aby si vybrali něco pro ně zapamatovatelného a zároveň dostatečně dlouhého. Jaká délka je dostatečná? Osmiznakové heslo je dostatečné proti online útoku, pokud je rozumně nastaven počet pokusů. Ale potřebujete více než dvakrát delší heslo, aby bylo stejně odolné proti offline útokům. Pokud tedy chcete mít svou databázi hesel dostatečně odolnou, měli byste používat hesla o alespoň 16 znacích. To ale uživatelé nemají rádi, protože si takto dlouhá hesla nemohou zapamatovat.
Místo takto drastických požadavků na straně uživatele je možné přenést zátěž na provozovatele, který může ukládat hesla bezpečněji a snížit tak útočníkovu úspěšnost i při použití kratších hesel. Chceme vést uživatele k tomu, aby si zvolili kratší zapamatovatelná hesla, ale nechceme je nutit k vymýšlení příliš dlouhých hesel.
Pak je tu ale také otázka maximální délky hesla. Je spousta webů, které vám dovolí vytvořit si heslo o délce maximálně osmi či dvanácti znaků. K ničemu takovému ale není důvod! Proč nepovolit hesla o délce 64 znaků nebo i více. Dovolte uživatelům takovou bezpečnost, jakou sami chtějí. Uživatelé si pak mohou zvolit velmi dlouhou frázi, která ale dává smysl jen jim.
Řada webů také omezuje použití mezer uvnitř hesla. Mezery jsou přirozená věc, povolte je uživatelům! Stejně tak by mělo být možné využít libovolné dostupné znaky – všechny tisknutelné ASCII znaky, unicode nebo třeba symboly emoji. Některé stránky vás vybízejí k použití speciálních znaků a vyjmenují vám pár povolených. Proč nemůžeme použít i jiné? Neexistuje rozumný důvod, proč uživatele omezovat ve výběru. Ověřovatel stejně musí heslo zahašovat, takže třeba SQL injection by neměl být problém.
Bezpečnostní otázky jsou zlo
Na mnoha místech jste stále dotazováni na bezpečnostní otázky či nápovědy k heslům. Nedělejte to! Všechny tyhle položky jsou další hesla a mají ty nejhorší vlastnosti. Pokud se například uživatele zeptáte, jak se jmenoval jeho první domácí mazlíček, pravděpodobně je možné jméno zjistit na Facebooku. Když se na něj navíc ptá deset různých webů, máte najednou deset míst se stejným heslem. To je strašlivé, vůbec nevím, proč to dělají.
Pokud jste jako uživatelé nuceni vyplnit bezpečnostní otázku v rámci vytváření nového účtu, použijte správce hesel a vygenerujte jako odpověď náhodný řetězec znaků. Uložte si takto vygenerovanou odpověď do poznámek ve svém správci.
Pravidla pro heslo
Velmi často se také můžeme setkat s tím, že nám služba nadiktuje, jaká pravidla musí naše heslo splňovat: velké písmeno, malé písmeno, číslo, zvláštní znak a podobně. Na všechna tato pravidla musíte dát pozor a přijít s takovým heslem, které je služba ochotna přijmout. Nedávno jsem si zřizoval nový bankovní účet a strávil jsem nepříjemné chvilky vymýšlením vhodného hesla. Zasekl jsem se na tom, že banka povolovala jen konkrétní zvláštní znaky, ale vypsala mi špatné!
Neměli byste své uživatele obtěžovat podobnými svazujícími pravidly. Vytváření hesla v takovém prostředí je noční můra, která navíc nepřináší tolik výhod, jak si obvykle tvůrci myslí. Jsou tu navíc jazykové rozdíly a stejná pravidla pak nemusí být v jiných jazycích použitelná. Mnohem lepší je použít seznam zakázaných hesel.
Jak velký ale má být seznam neakceptovatelných hesel? Pokud bude příliš krátký, uživatelé budou používat běžná krátká hesla. Pokud ale zase bude příliš rozsáhlý, naštveme uživatele – nebudou si moci snadno vytvořit heslo a začnou být kreativní. Je to jako pevná pravidla pro hesla, ale ještě méně transparentní. Uživatelé pak budou nepovolená hesla doplňovat o jednoduché znaky, jen aby vyhověli filtru.
Co když si uživatel zvolí špatné heslo? Je to příležitost ho něco naučit. Nestačí mu jen zobrazit varování, v takovém případě začne přidávat předvídatelné znaky. Doporučuje se dát uživateli konkrétní radu a zobrazit například oblíbený měřák ukazující sílu hesla. Uživatel pak má možnost pro další pokus vytvořit něco výrazně silnějšího.
Existuje celá řada problémů v uživatelském rozhraní, které se týkají hesel. Uživatel například téměř nikdy heslo přímo nevidí, takže je chráněn před jeho přečtením přes rameno. Myslete ale na to, že jsou tu uživatelé s různým postižením nebo lidé snažící se zadat heslo v pohybujícím se dopravním prostředku. Dejte jim možnost zobrazit si heslo v čitelné podobě. Zobrazení hesla může zlepšit přesnost při jeho zadávání a zlepšit tak uživatelský dojem. Heslo by se ale mělo po uplynutí jistého času zase samo skrýt.
Vypršení hesla
Na řadě míst je stále nutné si po určité době změnit heslo: po třech měsících, půl roce nebo roce. Není to dobrý nápad. Pokud uživatelé vědí, že si budou muset heslo brzy změnit, neinvestují dost času k vytvoření dobrého hesla. Běžné je také triviální doplňování hesla o další znaky, aby se nové heslo lišilo od toho předchozího. Dělám to tak sám, když se do podobné situace dostanu.
Mělo bychom raději povzbudit uživatele v tom, aby si vytvořili silné heslo, které jim vydrží dlouhou dobu. Může ovšem dojít ke kompromitaci hesla, takže je dobré mít v systému zabudovanou možnost vynutit obnovu hesla v případě podezření na problém. Nedělejte to ale pravidelně a zbytečně.
Bezpečné uložení hesla
Služby by se měly snažit heslo ukládat zodpovědně a co možná nejbezpečněji. Základní metodou je hašování, které brání úspěšnému útočníkovi k odhalení hesel v čitelné podobě. Naivní metoda spočívá v pouhém použití hašovací funkce, například SHA256. Útočník ale pak může vyzkoušet zahašovat spoustu potenciálních hesel a zkontrolovat, zda se výsledek shoduje. Zároveň vidí na první pohled, kteří dva uživatelé používají stejné heslo – haše jejich hesel se v databázi hesel shodují.
Proto se hesla před hašováním „solí“ – přidává se k nim náhodný řetězec. Sůl se pak uloží společně s hašem, aby bylo možné proces při pokusu o přihlášení snadno zopakovat. To řeší problém unikátnosti haše stejných hesel u různých uživatelů a nedovoluje to jednoduše použít předem vytvořené vyhledávací tabulky. Útočník ale může mít přístup k velkému množství výkonného hardware a může jednoduše hádat hrubou silou. Můžeme ho tedy jen zpomalit, ale ne dostatečně.
Existují ovšem mnohem sofistikovanější algoritmy, které z hádání hesel dělají mnohem náročnější disciplínu. Například algoritmus pbkdf2, který využívá technologií vyvinutých pro těžbu kryptoměn. Velmi dobře se ale akceleruje na grafických kartách a nepotřebuje ani moc paměti. Vhodnější je proto najít náročnější algoritmy.
Vhodný algoritmus musí být pomalejší a zároveň musí spotřebovat relativně velké množství paměti. K prolomení hesel je pak potřeba velké množství zdrojů. Populárním řešením je bcrypt, který je v této oblasti v současnosti asi nejlepším řešením.
Zajímavým řešením jsou haše chráněné klíčem (keyed hashing), kdy se z hesla vytvoří haš obvyklým způsobem a pak se předá specializovanému zařízení. To je oddělené od vnějšího světa, takže je těžké ho napadnout. Může to být i velmi bezpečný HSM. Toto oddělené zařízení původní haš znovu zahašuje, ale před tím do procesu přidá tajný klíč. Poté se výsledek vrátí zpět k uložení. Pokud neunikne tento tajný klíč, není možné z haše získat původní heslo. Prototyp řešení má Jim Fenton na svém GitHubu pod názvem rehash. Je to relativně levné, ale velmi efektivní řešení.
Případová studie: Adobe
V říjnu roku 2013 došlo k velkému úniku dat ve společnosti Adobe. Útočníkům se podařilo získat 130 milionů záznamů, které obsahovaly e-mailové adresy, nesolená zašifrovaná hesla a nešifrované nápovědy k nim. Udělali mnoho věcí úplně špatně. Celkem se v úniku nacházelo 56 milionů unikátních hesel – mnoho z nich bylo duplicitních. Naštěstí byla hesla zašifrovaná klíčem, který zřejmě nikdy neunikl Ale kdo si tím může být jistý? Kvůli dostupným e-mailovým adresám by bylo v opačném případě možné spojit hesla s konkrétními lidmi a zkusit se přihlásit na jiných službách.
Je ovšem možné začít s hesly hrát zajímavou hru, protože je možné korelovat nápovědy ke stejným heslům. Jedno z často opakujících se hesel mělo například nápovědy: Glenlivet, whiskey, single malt a Johny Walker. Heslo je scotch. Vím to, protože jeden z těch lidí je můj přítel a prozradil mi, že to je skutečně ono heslo.
Únik z Adobe dobře demonstruje základní problémy. Pokud se hesla nesolí, prozrazení jednoho z nich může mít dopad na stovky uživatelů. Nápovědy k heslům jsou zlo! Důležité zjištění také je, že je jednodušší chránit oddělený krátký klíč než chránit celou obrovskou databázi uživatelských účtů.
Dvoufaktorová autorizace
Hesla jsou ovšem jen jeden ze způsobů zabezpečení. V kritických systémech je rozumné použít takzvanou dvoufaktorovou autentizaci. Kromě toho, že něco známe (heslo), pak musíme také něco vlastnit. To je onen zmíněný druhý faktor, který ovšem může tvořit mnoho různých řešení.
Tím nejjednodušším jsou různé kartičky do peněženky, na kterých jsou uložena hesla pro jedno použití. Nepotřebujete k tomu nic speciálního, máte u sebe prostě kus papíru. Nevýhodou je, že na kartičku se vejde jen omezený počet hesel a pak ji musíte vyměnit. Je to ale velmi levné řešení a dobře se hodí pro občasnou autentizaci k některým službám.
Velmi rozšířeným řešením je odeslání doplňkové informace mimo hlavní komunikační kanál. Typickým řešením je odeslání zprávy na mobilní telefon, ze které musí uživatel opsat jednorázové heslo. Velkým problémem jsou ale krádeže telefonních čísel, kdy někdo přijde za operátorem a prohlásí, že ztratil telefon. Protože se identita ověřuje velmi zběžně, podaří se občas někomu takto přivlastnit si číslo. Použití klasických textových zpráv proto není doporučováno. Mnohem bezpečnější je použít bezpečnostní aplikaci, která prokáže, že máte v ruce konkrétní přístroj.
Další variantou jsou aplikace či zařízení generující jednorázová hesla. Dokazujete pak, že držíte v ruce konkrétní zařízení, které obsahuje správně nastavenou aplikaci. Nevýhodou je, že ověřovatel musí používat předem vygenerovaný klíč (RNG seed), ze kterého generuje jednorázová hesla. Už se v minulosti stalo, že tato citlivá informace unikla a útočník si byl schopen neomezeně jednorázová hesla generovat. Je to dobrý přístup, ale pokud se k něm rozhodnete, musíte dobře chránit tento klíč.
Standard FIDO umožňuje ke koncovému zařízení připojit autentizační zařízení. Tím může být smart karta, USB dongle, NFC karta a podobně. Používá se tu protokol typu výzva-odpověď, kdy zařízení na základě kryptografie veřejného klíče vygeneruje odpověď na zaslanou výzvu. Výhoda je, že každý uživatel má vlastní pár klíčů a ověřovatel zná jen veřejný klíč, který mu pro přihlášení k uživatelským účtům nestačí.
Není konečným řešením využití biometrických údajů? Můžeme použít duhovku, skenovat obličej nebo sejmout otisk prstu. Nebudeme si muset pamatovat hesla, ale sáhneme na senzor a je to. Nebyl by to krásný svět? Biometrie ale není tak skvělá, jak si všichni myslí. Jsme například omezeni přesností detekce biometrických údajů. Typický poměr falešné pozitivity se tu pohybuje mezi 1:1000 až 1:10000. To je jako třímístný PIN. Naopak je tu nebezpečí falešné negativity, stačí mít špinavé nebo mokré ruce a už nejsme identifikováni. Největším problémem ale je, že své biometrické údaje necháváme všude okolo sebe a neumíme je revokovat.
Přesto mají biometrické údaje své místo, pokud je použijeme správně. Doporučovaná metoda je svázat je s konkrétním zařízením a ověřovat lokálně. Můžu mít například svůj otisk prstu nahraný v mobilu, kde se také ověřuje. Pokud mám problémy s rozpoznáním, vždycky můžu použít záložní heslo.
Univerzální doporučení
Existuje sada obecně platných doporučení, která se vztahují na různé metody autentizace, od hesel přes dvoufaktorové ověření až po zmíněné sejmutí biometrických údajů.
První z nich je škrcení (throttling), kdy omezíme počet pokusů při autentizaci. Je to primární obranný mechanismus. Problém ale je, že když to uděláte příliš přísné, může útočník překročit limit a odříznout uživatele od jeho účtu. Je potřeba dobře zvážit, jaké může mít útočník plány. Je ale možné použít složitější metody, například nasadit CAPTCHA, vzít v úvahu reputaci IP adresy a podobně. Nezapomeňte, že limitujete online útoky, ale zároveň omezujete uživatele.
Důležitá je také ochrana proti phishingu. Když uživatel vloží své přihlašovací údaje do falešné přihlašovací stránky, útočník se může přihlásit místo něj. Jednorázová hesla se mění, ale útočník se může přihlásit okamžitě a heslo je pro něj platné. Cílem tedy je tomuto útoku zabránit a není to možné nechat na uživatelích – útočníci se stále zlepšují ve vytváření phishingových webů. Řešením je autentizaci spojit s konkrétním TLS sezením, pokud si útočník otevře své vlastní, už pro něj nebude přihlášení platit. Využít se k tomu dají už zmíněná zařízení využívající standard FIDO a připojená přímo ke konkrétnímu zařízení.
Ověřovatel by měl také zvážit, zda jsou jím zvolené metody odolné proti kompromitaci. Zda únik některých dat povede k možnosti autentizovat se jako uživatel. Roli tu hraje zejména typ autentizátoru: veřejné klíče jsou bezpečné, symetrické klíče naopak ne a u hesel záleží na způsobu jejich uložení. Přihlášení musí být také odolné proti útoku přehráním, tedy situaci, kdy útočník zopakuje dříve zaznamenanou komunikaci a tím se přihlásí.