Ukládat hesla v počítači nebo v zařízení, které musí být s počítačem spojeno v okamžiku, kdy chcete dané heslo použít, není bez ohledu na to, jestli jsou hesla v daném úložišti šifrována či nikoliv, úplně ideální, stejně jako zapsat si všechna svá hesla na papírek, který můžete ztratit. Když si ale dokážete zapamatovat jedno komplexní heslo, tak si již žádná další hesla nemusíte pamatovat.

Hesla, která budete k přihlášení do jednotlivých systémů používat, budou totiž složena ze dvou částí. Z komplexního hesla, které budete mít uloženo jen ve své hlavě a z komplexních hesel pro jednotlivé systémy, která si někam zapíšete. Útočník, který by se k médiu se zapsanými hesly dostal, se však tak snadno nepřihlásí, protože by musel nejen znát, jaké uživatelské jméno a k jaké službě používáte, ale také jaká je ta druhá část hesla, kterou máte uloženou jen ve své hlavě.

Nehledě na to, že hesla mohou být na médiu zapsána v podobě seznamu, který se bude skládat z několika delších řetězců, a jen vy budete vědět, jak je heslo dlouhé, na jaké pozici začíná, zda jednotlivé znaky hesla následují v řetězci po sobě atd. Vy si můžete v podstatě vymyslet jakýkoliv algoritmus, a v hlavě provádět ještě nějakou transformaci. Je to sice security by obscurity přístup, ale plní dobře svůj účel. Možná je ale toto opatření zbytečné, protože pravděpodobnost, že by útočník bez jakýchkoliv indicií přišel na to, k čemu a komu daný seznam hesel slouží, je, přiznejme si to, mizivá. To je ostatně i důvod, proč je nesmyslné uživatelům zakazovat si hesla někam poznamenat.

První podmínka by mohla být splněna jen v okamžiku, kdy by útočníkem byla osoba, která vás zná. Pokud by útočník heslo odchytil při přenosu nebo by kompromitoval systém, do kterého se hlásíte, získal by jen heslo k danému systému. Do jiných systémů útočník nemá šanci se přihlásit, protože z odchyceného hesla není schopen odvodit hesla ostatní. Útočník by mohl být úspěšný jen v jednom jediném případě a to, že by odchytil jedno z hesel a zároveň by získal přístup k médiu, na kterém máte části hesel k jednotlivým systémům zapsána.

Pak by se již jednalo o cílený útok na vaší osobu, a v takovém případě by vás nejspíš nezachránila ani dvoufaktorová autentizace. Tím nechci říci, že dvoufaktorová autentizace pomocí nějakého tokenu nemá smysl. Má, ale upřímně řečeno, její hlavní výhoda spočívá především v tom, že token nelze jednoduše zkopírovat a když vám ho někdo ukradne, tak na to zpravidla brzy přijdete. Potíž je, že jsou systémy, které prostě jiný způsob autentizace než autentizaci heslem nenabízí.

Nyní si uveďme konkrétní příklad. Nejdříve si vymyslíme komplexní heslo, v duchu již výše odkazovaného příspěvku, ve kterém píšeme o tom, jak si vytvořit bezpečné heslo. Naším master heslem bude třeba „#P!Bm0“ Nyní již jen musíme vygenerovat ke každému systému, ke kterému se budeme hlásit, jedinečné komplexní heslo. Přičemž v hesle může být i zakódováno pro přihlášení k jaké službě dané heslo slouží. Zkuste si zahrát na útočníka a přijít na to, k jakým službám slouží tato tři hesla: w$4gEr, hg7Tm*, k2fW+3.

Když jsme si kladli otázku, jak dlouhé by měly být jednotlivé části hesla, vycházeli jsme z toho, že kdyby byla jedna část hesla kompromitována, musel by útočník druhou část hesla uhádnout. V případě, že by každá část hesla byla dlouhá přesně 6 znaků, znamenalo by to, že by útočník musel vyzkoušet minimálně 95^6 různých hesel a to by mu při rychlosti zkoušení 1000 hesel za sekundu trvalo několik let. Uhádnout heslo tímto způsobem je prakticky nemožné, viz příspěvek lámání hesel. Zde jen dodám, že i kdybyste disponovali botnetem čítajícím více jak tisíc strojů, tak vám to nepomůže, protože většina systémů je během sekundy stejně schopna obsloužit jen něco mezi 100 až 1000 uživatelů.

Pokud by se útočník dostal přímo k hashi takto konstruovaného hesla, musel by provést útok hrubou silou na heslo o délce 12 znaků a to by znamenalo vyzkoušet 95^12 různých hesel a to by trvalo až několik desítek let. Hlavní výhoda tohoto přístupu ke správě hesel spočívá v tom, že nepotřebujete žádný HW ani SW, a kompletní heslo není nikde uloženo ani se nezobrazuje v čitelné podobě na obrazovce.

Pozor: V okamžiku, kdy ztratíte médium, na kterém máte uložená jednotlivá hesla, tak se už nepřihlásíte, proto si raději udělejte jeho kopii a tu si uložte na bezpečném místě.

Pokud se rozhodnete, že pro správu hesel použijete nějaký SW nástroj, můžete svá hesla svěřit např. nějakému nástroji pro správu hesel, tzv. password manager, který hesla šifruje a pro přístup k nim vyžaduje zadání tzv. master hesla. Takovým řešením je např. KeePass nebo LastPass. Nevýhodou těchto řešení pro správu hesel je, že vaše hesla jsou uložena v paměti daného zařízení a následně i zobrazována na obrazovce. Kromě toho může být toto zařízení kompromitováno.

Jako bezpečnější řešení se proto jeví použití SW nástroje např. SuperGenPass, který hesla nikam neukládá, nýbrž hesla generuje v okamžiku, kdy zadáte název systému, do kterého se chcete autentizovat a své master heslo. Toto řešení využívá hashovací funkce, které jako parametr předáte master heslo, které se spojí s názvem systému (může jím být URL daného webu, název serveru nebo aplikace, to záleží zcela na vás), a pro tento řetězec se pak spočte hash, který se následně převede na komplexní heslo o určité délce. O tomto řešení se můžete dočíst více na rootu nebo blackhole. Nevýhodou tohoto řešení je, že se heslo zobrazuje v čitelné podobě na obrazovce.

Závěr: Všechny výše uvedené způsoby správy hesel jsou poměrně bezpečné a uživateli stačí si zapamatovat jen jedno, tzv. master heslo. Jak bude dlouhé, záleží především na něm, nicméně jako master heslo doporučujeme používat komplexní heslo o minimální délce 6 znaků. Ať už použijete jakékoliv řešení, nedoporučuji hesla uchovávat nebo generovat na zařízení, ze kterého se autentizujete.

A jak svá hesla spravujete vy? Už jste hlasovali v naší anketě?

Related posts:

1. Autentizace: mnoho hesel uživatelova smrt
2. Autentizace: mnoho hesel uživatelova smrt 2
3. Autentizace: politika účtů a hesel

Bude se jednat především o faktor z kategorie „něco mám“, který je spojen s vlastnictvím nějakého předmětu. Ten bude preferovat většina konzervativních firem. Jestliže ale byl doposud symbolem této kategorie HW token od společnosti RSA, bude jeho podíl na trhu postupně klesat, neboť bude pozvolna vytlačován smartphonem, který umožňuje příjem OTP ve formě SMS nebo je schopen OTP přímo generovat a fungovat jako tzv. SW token. Stále více firem bude umožňovat svým zaměstnancům použití soukromých mobilních zařízení a později i využití těchto zařízení jako druhého autentizačního faktoru pro přístup do svých systémů.

Důvodů, proč tomu tak bude, je několik. Jednak se potvrdilo, že velké firmy představují pro útočníky atraktivní cíl, a přes všechna ujištění je možné jejich systémy kompromitovat a to má pak dopad na všechny společnosti, které jejich autentizační řešení používají. Právě tato obava z úniku autentizačních údajů je ostatně i důvodem, proč nejrůznější společnosti nabízející jednotné přihlášení, doposud nezaznamenaly nějaký výrazný úspěch. Neposledním důvodem, který hovoří v neprospěch HW tokenů, je i výrazně vyšší TCO.

Dále je třeba si uvědomit, že člověk má ke svému telefonu přeci jen trochu jiný vztah, než k HW tokenu, takže v případě ztráty nebo zcizení telefonu tuto skutečnost zaznamená mnohem dříve, než když ztratí token. A když se nad tím zamyslíte, je to celkem logické, neboť telefon používá k telefonování, k psaní a čtení zpráv a ke spoustě dalších věcí, zatímco token používá zpravidla pouze k přihlášení do jednoho jediného systému. A pokud se do daného systému nehlásí příliš často, může ztrátu nebo zcizení tokenu zaznamenat až za mnoho hodin nebo i dní. V případě telefonu si jeho ztrátu nebo krádež uvědomí většinou mnohem dříve, často během několika málo minut.

Pro uživatele pak představuje autentizace pomocí telefonu jen samé výhody, především používá zařízení, na které je zvyklý, a hlavně sebou nemusí nosit žádný další předmět. Jak bude v následujících letech smartphone stále častěji využíván jako druhý faktor, poroste v souvislosti s tím i počet útoků, které bude cíleno na tuto platformu. A proto je vhodné již teď myslet na to, jak uživatele smartphone před těmito útoky ochránit. Vzhledem k tomu, že smartphone obsahuje plnohodnotný operační systém, měl by uživatel dodržovat stejná pravidla jako v případě práce na klasickém PC. Nejpoužívanější smartphony jsou poměrně solidně zabezpečeny, takže o tom zda se jeho uživatel stane obětí útoku, bude svým chováním rozhodovat především on sám.

Další autentizační metody z kategorie „něco jsem“, které ověřují uživatele na základě jeho biometrických charakteristik, se budou postupně též prosazovat, ale výrazně pomaleji, než by si jejich výrobci přáli, především z důvodu stále panující nedůvěry v jejich spolehlivost. Častěji než dříve se budeme moci setkat s technologií rozpoznávání hlasu (při volání do banky), tváře (při přihlašování do počítače, telefonu atd.) a způsobu psaní na klávesnici, neboť tyto technologie na rozdíl třeba od snímače otisku prstů nevyžadují instalaci žádného speciálního HW.

Tyto autentizační metody budou zároveň představovat i marketingový nástroj a zavádět je budou především ty firmy, které budou chtít touto cestou oslovit nové klienty, především mladou generaci, která netrpí předsudky a má stejně jako oni odvahu něco nového vyzkoušet.

Related posts:

1. Cloud computing: prognóza vývoje v nejbližších letech
2. Autentizace: Software token
3. Penetrační testování jako součást životního cyklu vývoje SW

Ovšem že ano, způsob jakým uživatel píše na klávesnici, je jednoznačně biometrická charakteristika a ta jako taková může být snadno využita v rámci vícefaktorové autentizace. Hlavní výhoda tohoto řešení pak spočívá především v tom, že není nutné instalovat žádný HW, neboť klávesnicí je vybaveno v podstatě každé zařízení a SW, který je k zaznamenání těchto charakteristik potřeba, může být snadno integrován v podobě javascriptu do každé webové aplikace.

Další výhodou tohoto řešení je, že po uživateli nejsou požadovány žádné úkony navíc, řešení je zcela transparentní, uživatel o tom, že probíhá nějaká analýza toho, jak píše, nemusí v podstatě vůbec vědět. Oproti ostatním autentizacím metodám, kdy se uživatel autentizuje jen jednou a v průběhu práce již k vyhodnocování toho, kdo v systému pracuje, nedochází, může být v tomto případě identita uživatele ověřována prakticky po celou dobu jeho práce.

Na první pohled se zdá, že možnosti využití tohoto řešení jsou značné. Mohlo by být použito nejen pro autentizaci, ale i pro zajištění autenticity zprávy, dokumentu nebo jakéhokoliv na klávesnici pořízeného textu, neboť hned by bylo zřejmé, kdo daný text napsal. Charakteristika způsobu psaní by se dala zkombinovat s otiskem počítače, a tak by se dalo nejen zjistit, že u počítače sedí oprávněný uživatel nebo někdo zcela jiný, ale i zda je do aplikace přistupováno ze stejného počítače. Dále by se mohlo jednat i o účinnou ochranu před keyloggerem, který zachytává pouze to, co bylo napsáno, nikoliv jako to bylo napsáno.

Jenže když se zamyslíme nad tím, jak celé toto řešení funguje, zjistíme, že všechno je trochu jinak. Kód, který se o pořízení těchto biometrických charakteristik stará, je celkem jednoduchý. Zaznamenává dobu, po kterou byla daná klávesa stisknuta (prodleva mezi událostmi keydown a keyup) a dobu, která uběhla mezi stiskem dvou po sobě jdoucích kláves (prodleva mezi stiskem keyup a dalším keydown), a dále, které dvě po sobě jdoucí klávesy to byly. Jak vidíte, parametrů, které můžeme vyhodnocovat, opravdu moc není.

Tyto parametry, zachycené skriptem na straně klienta pak jsou předány na server, na kterém pak proběhne vlastní vyhodnocení proti již dříve uloženému vzoru, tzv. keystroke pattern recognition a spočte se skóre. Stejně jako u všech ostatních biometrických metod musí i zde být nastavena nějaká tolerance, protože uživatel nikdy nezadá ani ten samý text úplně stejně. A stejně jako i u ostatních biometrických metod, i zde bude existovat určité riziko chybně přijatých a chybně odmítnutých uživatelů.

Nyní, když již víme, jak tato biometrická metoda funguje, se můžeme zamyslet nad tím, jakým způsobem by bylo možné na ní vést útok. Nejjednodušším způsobem je použít stejný skript a umístit ho na vlastní webovou stránku, na které donutíme oběť něco napsat, ale stejně tak se může jednat i o keylogger, který bude kromě hesel uchovávat i tyto charakteristiky. Narážíme zde na podobný problém jako v případě hlasové autentizace, kdy v okamžiku kdy bude mít útočník možnost si pořídit tyto charakteristiky, může následně na server poslat takovou odpověď, tj. text včetně charakteristik, který bude programem vyhodnocen, jako že ho napsal daný uživatel.

Samozřejmě, že provedení útoku není až tak jednoduché, neboť útočník by vzhledem k tomu, že ani oprávněná osoba není schopna dosáhnout opakovaně stejného skóre, musel nejprve analyzovat, jakým způsobem k vyhodnocování na straně serveru probíhá, a charakteristiku, kterou na server posílá, upravit tak, aby spočtené skóre nedosáhlo hodnoty 100%, protože jinak by to bylo hned podezřelé.

Podívejte se schválně na konkrétní řešení od německé společnosti TM3 Software GmbH, která vyvinula SW KeyTrac, který si můžete vyzkoušet přímo v prostředí vašeho prohlížeče. Demo vyžaduje zadání poměrně dlouhého textu, ale nenechte se odradit, stojí to za to. Kromě toho má firma v nabídce i řešení, která se spokojí i se zadáním pouhých 8 znaků. Já jsem dosáhl skóre 99,98% a co vy?

No related posts.

V minulém příspěvku jsme se zabývali otázkou, zda je jednorázové heslo (One Time Password, zkr. OTP) používané v rámci autentizace bezpečné. OTP však nemusí být vždy použito jen pro autentizaci. Např. v internetovém bankovnictví se OTP dost často používá pro autorizaci transakce, kdy uživatel musí každou transakci potvrdit jednorázovým heslem, nazývaným TAN (Transaction Authentication Number) případně mTAN (mobile Transaction Authentication Number) pokud je toto OTP zasíláno na mobilní zařízení klienta ve formě SMS.

Problém je, že pokud počítač nebo mobilní telefon uživatele není prost malwaru, tak i tento TAN resp. mTAN může být útočníkem snadno odchycen a zneužit, viz např. útoky na uživatele internetového bankovnictví za použití specializovaného bankovního trojana nazývaného Zitmo (Zeus in the mobile), který je schopen přeposlat útočníkovi mTAN zasílané na mobilní zařízení uživatele ve formě SMS. Tento případ jasně ukázal, že ani doručení OTP jiným kanálem (Out-Of-Band, zkr. OOB), jak je doporučováno v dodatku k příručce Authentication in an Internet Banking Environment vydané FFIEC, nemusí vždy stačit.

Pokud se bude uživatel hlásit z počítače, který je prost malwaru a ISP (Internet Service Provider) i daný server bude využívat DNSSEC, nemusí se uživatel internetového bankovnictví MITM nebo MITB útoku obávat. Jenže uživatel si v podstatě nemůže být nikdy jist, že jeho počítač nebo smartphone je prost malwaru. Dokonce i v případě, že je v SMS uvedeno číslo cílového účtu a částka, tak to na celé záležitosti nic nemění, protože OTP lze získat i jiným způsobem. (Mimochodem, některé banky v SMS tyto informace stále neuvádí, takže klient v podstatě neví, co vlastně potvrzuje.)

Řešením by mohlo být generovat OTP metodou challenge-response. Uživatel by do zařízení sloužícího ke generování OTP přepsal kritické hodnoty z formuláře a z těch a ze sdíleného tajemství by bylo vygenerováno OTP, které by uživatel následně přepsal do webového formuláře. Pokud namítáte, že uživatele by přepisování oněch kritických hodnot obtěžovalo, a že by je nemusel přepsat správně, a vůbec že se jedná o velice nepřívětivé řešení, tak máte pravdu.

Co kdyby ale uživatel nemusel žádné hodnoty z formuláře do zařízení přepisovat. Co kdyby byl generátor OTP vybaven jednoduchým snímačem QR kódu, který by byl umístěn na dané stránce a na displeji by následně zobrazoval ony kritické hodnoty a po stisknutí tlačítka by vygeneroval odpovídající OTP, které jediné by uživatel musel přepsat. Co, že by to bylo moc drahé? Ale jděte, záleží jen na tom, u koho si to necháte vyrobit.

Říkáte, že uživatel sebou nechce žádné další zařízení nosit a ještě dávat pozor, aby ho neztratil. Dobře, ale co kdyby se jednalo o aplikaci, kterou by si jednoduše nahrál do svého smartphonu, ten sebou nosí přeci stejně ne? Myslím, že vaši klienti by mohli být spokojeni a vy zase ušetříte, neboť nebudete muset distribuovat žádné HW tokeny, ani posílat drahé SMS. Nebylo by tohle dobré řešení z pohledu bezpečnosti, použitelnosti i nákladů?

Related posts:

1. Autentizace v internetovém bankovnictví
2. Autentizace v internetovém bankovnictví – dodatek
3. Man in the mobile aneb útok na uživatele internetového bankovnictví

V minulém příspěvku jsme se zamýšleli nad tím, jak by mohla být provedena autentizace uživatele po telefonu. Řekli jsme si, že uživatel by mohl svoji identitu potvrdit znalostí hesla, svým hlasem a případně i číslem, ze kterého volá. Ignorovali jsme však jednu podstatnou skutečnost, že nejen poskytovatel služby, v naší úvaze banka, chce mít jistotu, že informaci nebo službu poskytuje oprávněnému uživateli, ale že i uživatel chce mít jistotu, že hovoří opravdu s bankou.

Některé organizace tento problém řeší tak, že provedou callback, tímto způsobem je možné se poměrně jednoduše bránit útokům označovaných jako caller ID spoofing, které spočívají v tom, že útočník zavolá přes voice-over-IP poskytovatele, který mu umožňuje nastavit si libovolné caller ID (rozuměj telefonní číslo), anebo využije jedné z mnoha placených a přes internet dostupných služeb, které toto umožňují.

Jak má ale uživatel poznat, že hovoří opravdu s někým z dané společnosti? Že se mu operátor představí jménem dané společnosti? To je přeci dost málo, ne? U webu by si mohl uživatel zkontrolovat alespoň certifikát, ale co si může zkontrolovat zde? Prakticky nic. Uživatelé jsou v tomto případě vystaveny mnoha různým útokům přes phishing, smishing až po vishing.

Oproti klasickému phishingu, je zde větší šance, že si uživatel rozmyslí, zda bude na dané číslo volat, obzvlášť v případě, když uvidí, že se jedná o číslo z jiné země. Ovšem mnohem horší situace může nastat v okamžiku, kdy klientovi zavolá útočník. Pozná klient, že se jedná o vishing? Nejspíš ne, neboť většinou se autentizuje jen jedna strana a ještě k tomu nedostatečně.

Problém je, že uživatel opravdu moc možností nemá. Jediné, co může udělat, že si do systému, pokud to daný systém podporuje, nahraje svůj vzkaz a ten mu je po úspěšné autentizaci přehrán. Jistě jste poznali, že se jedná o pokus o oboustrannou autentizaci (mutual authentication), která je obdobou SiteKey, která je náchylná k MITM útoku. Pojďme si stručně popsat, jak by takový útok probíhal.

Útočník zavolá na číslo poskytovatele dané služby (banky), a v reálném čase zadá údaje, které mu právě poskytla oběť, do automatizovaného systému (Interactive Voice Response, zkr. IVR), který mu přehraje zprávu, kterou on s minimálním zpožděním přehraje i oběti, která je následně systémem vyzvána k hlasové autentizaci, poté již dojde ke spojení s operátorem, ale s tím již hovoří útočník, zatímco oběť hovoří s operátorem útočníka. Z tohoto důvodu se nám jeví jako vhodné, aby kontrola volajícího probíhala po celou dobu daného hovoru. Pokud by tomu tak nebylo, mohl by útočník snadno realizovat např. převod peněz na jiný účet.

Tento útok je, pokud jde o zdroje, podstatně méně náročný na provedení než v minulém příspěvku naznačený útok spočívající v generování smysluplných odpovědí na dotazy operátora z databáze slov a slovních spojeních uložených v databázi útočníka a sestavených na základě pořízené nahrávky uživatele.

Dalším úskalím hlasové autentizace může být hlasová indispozice uživatele, v takovém případě by se uživateli nepodařilo do systému přihlásit a službu by prakticky nemohl využívat. Je otázka, jak by v takovém případě vůbec hovořil s operátorem, ale budiž. Uvedené problémy a rizika nás nicméně přivádí na myšlenku, zda možnost kontroly hlasu v průběhu celého hovoru nevyužít spíše jako systém sloužící k odhalení podvodu (Fraud Detection System, zkr. FDS) a v případě podezření nepoložit uživateli nějakou kontrolní otázku.

Závěr: Navzdory výše uvedeným skutečnostem se domníváme, že pokud bude hovor do banky iniciovat sám klient, a bude se autentizovat pomocí ID a PIN, tak se nemusí příliš obávat, že by se stal obětí nějakého útoku. A jaký je váš názor?

Předpokládejte, že zavoláte do banky na číslo, na kterém je poskytována služba telefonického bankovnictví a systém vás vyzve k zadání vašeho identifikačního čísla.

Změnila by se nějak vaše volba, pokud by obsluha účtu byla možná jen z předem dohodnutého telefonního čísla? Telefon by v daném případě sloužil jako druhý faktor z kategorie „něco má“ a identifikátor by nebylo nutné zadávat.

Změnila by se nějak vaše volba, pokud by obsluha účtu byla možná jen z předem dohodnutého telefonního čísla a banka by navíc provedla callback? To znamená, že by vám zavolala zpět.

Related posts:

1. Autentizace: Jednorázová hesla – PINsafe
2. Autentizace

To znamená, že pokud dojde k zachycení OTP útočníkem, nemůže jím být k opětovnému přihlášení použito. Opravdu? Ve většině případů tomu tak je, pokud ovšem útočník zachycené OTP nepoužije dříve než oběť.

Útočníkovi stačí uživatele jen přesměrovat na svůj web, a uživatel mu na něm sám zadá jednorázové heslo, neboť si nevšimne, že je vlastně někde jinde. Říkáte, že vám se to stát nemůže, protože pečlivě kontrolujete certifikát, a zda web, ke kterému se hlásíte, používá DNSSEC stejně jako váš ISP. Dobře děláte, ale útočník může získat vaše přihlašovací údaje i jinak.

Útočníkovi stačí ohlídat si formulářové pole, do kterého se OTP zadává a poslat si jeho hodnotu přes internet na svůj stroj a z něj autentizaci dokončit. V okamžiku, kdy uživatel klikne na tlačítko sloužící k odeslání OTP na server, tak se mu zobrazí standardní hlášení, že zadané jméno nebo heslo bylo chybné. Uživatel si pomyslí, že se asi překlepl a tak si vygeneruje nové OTP a pokusí se přihlásit znovu a tentokrát se mu to již povede.

Teď už asi tušíte, proč je u OTP omezená jeho platnost třeba jen na 60 sekund. Ano, proto aby útočník nestihl odchycené heslo použít. Jenže je naivní se domnívat, že útočník sedí u svého počítače a ručně zadává uživatelské jméno a OTP, které mu právě poslal jeho malware. Kdepak, vše probíhá zcela automatizovaně. Malware přihlašovací údaje, tj. uživatelské jméno a heslo odchytí a odešle útočníkovi na server, kde jeho bot provede přihlášení na pravý server a teprve poté útočník provede ručně v daném systému příslušnou operaci.

Pokud není nijak omezen počet současně připojených uživatelů (což většinou není) a aplikace ani nezobrazuje hlášení o tom, kdy došlo k poslednímu přihlášení (což zpravidla zobrazuje málokterá aplikace), oběť si pravděpodobně pomyslí, že došlo k nějaké chybě a zadá prostě nové OTP. Vidíme, že celá důvěra v bezpečnou autentizaci pomocí OTP je vlastně založena jen na předpokladu, že útočník nebude nikdy schopen odchycené heslo použít dříve než oprávněný uživatel. A jak jsme si uvedli výše, časové omezení útočníkovi ve zneužití odchyceného OTP rozhodně nezabrání.

Byť je tento útok opravdu možný a není problém napsat malware, který OTP zadávané uživatelem odchytává a posílá útočníkovi, tak riziko, že by se větší počet uživatelů stal obětí takového útoku, je spíše nízké. Především proto, že malware, který se takto chová, bývá zpravidla velice rychle odhalen, a kromě toho vyžaduje i změnu způsobu, jakým jsou odchycené autentizační údaje zneužívány organizovaným zločinem, i když i zde se situace pomalu mění.

Závěr: Jednorázová hesla by měla být nepredikovatelná, aby útočník nemohl ze zachyceného OTP odvodit následující a měla by mít omezenou časovou platnost a měla by být vázána na session ID.

Related posts:

1. Autentizace: Jednorázová hesla – PINsafe
2. Autentizace: Jednorázová hesla – S/KEY
3. Autentizace: proč uživatelé volí slabá hesla

Technologie hlasové biometrie (voice biometrics) umožňující autentizaci uživatele pomocí hlasu (voice authentication) v posledních letech pokročila na tolik, že jejímu masivnějšímu nasazení již nebrání ani tak cena, jako spíše stále přetrvávající nedůvěra odborné i laické veřejnosti v její spolehlivost. Není tedy divu, že se s touto technologií můžeme v běžném životě setkat zatím spíše výjimečně, a přitom by se dala poměrně efektivně využít např. v rámci skutečné vícefaktorové autentizace (multi-factor authentication, zkr. MFA) např. pro přístup klienta k bankovnímu účtu nebo k jiným citlivým informacím.

Poznámka: Pozor, speaker recognition není totéž co speech recognition, neboť oba systémy slouží ke zcela jiným účelům. Zatímco v prvním případě je cílem takového systému poznat, komu daný hlas patří, tak ve druhém případě je cílem rozpoznat, co daná osoba říká.

V principu není ověření pomocí hlasu nic složitého. Nejprve pořídíme hlasový záznam (např. z právě probíhající běžného hovoru mezi operátorem a klientem, takže klient o tom v podstatě vůbec nemusí vědět), který analyzujeme a vytvoříme z něj hlasový otisk (voiceprint) jenž uložíme do systému (tento proces nazývaný honosně enrollment). Při příští komunikaci s daným uživatelem pak jeho aktuální hlasový projev porovnáme pomocí speciálního, pro tento účel vyvinutého algoritmu s voiceprintem, který máme uložen v systému a pokud si vybrané hlasové charakteristiky odpovídají, je uživatel vpuštěn do systému, v opačném případě mu je přístup odepřen.

Poznámka: Pozor, pokud hovoříme o identifikaci řečníka (speaker identification), tak systém musí projít všechny voiceprinty a dohledat komu daný hlas patří. V případě autentizace řečníka (speaker authentication) se již uživatel nějak identifikoval a systém ověřuje jeho hlas proti jedinému voiceprintu, takže samotné ověření by nemělo trvat déle než několik sekund.

Tato forma ověření uživatele může spočívat buď v analýze toho, jak byla vyslovena požadovaná fráze nebo jak byl vysloven libovolný text. Zatímco v prvním případě musí uživatel vyslovit např. sdílené tajemství nebo zopakovat frázi, kterou mu přehrál systém (jedná se o tzv. text-dependent system), tak ve druhém případě může hovořit zcela přirozeně (free speech) a jeho hlas je vyhodnocován v průběhu hovoru (jedná se o tzv. text-independent system).

Poznámka: Některé systémy ukládají do své DB jen voiceprint o velikosti maximálně několika KB, ze kterého nelze zrekonstruovat původní nahrávku, a případně voiceprint aktualizují s každou úspěšnou autentizací.

Jistě vás napadlo, že pokud by systém vyžadoval pouze vyslovení správného hesla, mohl by být oklamán opětovným přehráním zachycené zprávy (replay attack). Takový útok spočívá v tom, že útočník si nejprve hlas oprávněného uživatele nahraje a poté ho přehraje v okamžiku, kdy ho systém vyzve k vyslovení daného hesla. To by měl ale systém snadno odhalit, protože člověk nedokáže danou frázi zopakovat vždy úplně přesně, kdežto stroj ano, takže systém bude hned vědět, že se jedná o replay attack.

Jako bezpečnější řešení se tedy jeví požadovat po uživateli zopakování náhodně vygenerované fráze. Fráze může být například náhodně generovaná řada čísel (což je asi nejčastější řešení) nebo náhodně vybraný text z nějaké databáze, případně fráze vygenerovaná ze slovníku, která je pak uživateli přehrána pomocí syntézy řeči. Tu si útočník dopředu připravit nemůže a generovat ji v průběhu hovoru pomocí SW z DB obsahující slova z odněkud získané nahrávky by měl systém též rozpoznat, neboť je schopen rozlišit i změnou výslovnosti slova u konkrétního uživatele díky okolním slovům.

Kromě toho věta, kterou musí uživatel zopakovat, může obsahovat i slova a spojení, která se v běžném jazyce příliš často nepoužívají, a tudíž útočník nebude mít možnost si jejich nahrávku někde pořídit. Nehledě na to, že mohou být použity oba přístupy, kdy je uživatel nejprve ověřen tím, že musí zopakovat danou frázi a následně je pak jeho hlas vyhodnocován i v průběhu celého hovoru.

Představte si, že byste např. zavolali do své banky, systém by vás podle vašeho hlasu poznal a vy byste jen operátora požádali o provedení určité transakce nebo o sdělení jiných citlivých informací. To by byla efektivita a komfort. Ovšem rozhovor uživatele a operátora by musel být v takovém případě dostatečně unikátní, aby nebylo možné replay attack realizovat pouhým přehráním již předem připravených vět. Nezapomínejte, že operátoři call center kvůli efektivitě vedou dialog podle předem daných scénářů, takže se dá předpokládat, že každý hovor bude probíhat víceméně stejně. Ale možná že ani to by nemuselo být nutné, protože jak jsme již uvedli výše, systém by měl takový útok snadno poznat.

Jedno je jisté, pro obě strany je důležité, aby systém fungoval maximálně spolehlivě, tzn., aby vás poznal podle hlasu i v případě, že budete nachlazen a zároveň, aby odhalil útočníka, který má podobný hlas (vaše dvojče, člen rodiny) nebo se snaží váš hlas napodobit (imitátor). V případě, že si systém není jistý, měl by použít jiný způsob autentizace. Z těchto důvodů je vhodné kombinovat tento autentizační faktor ještě s dalším faktorem z jiné kategorie.

Poznámka: Špičkové systémy pracují s příznaky, které komplexně popisují hlasové ústrojí řečníka. To je dáno fyziologicky a imitátor ho nemůže v žádném případě změnit, a proto jsou tyto systémy vůči profesionálním imitátorům celkem imunní, neboť imitátor zvládne pouze změnit základní tón a rychlost řeči, či některé další parametry, což k oklamání nestačí.

Nemusíme se spoléhat jen na hlasovou verifikaci. Můžeme např. po uživateli požadovat zadání jeho ID a PINu nebo akceptovat volání jen z určitého čísla. V obou případech se pak jedná o dvoufaktorovou autentizaci. V prvním případě z kategorie „něco ví“ a ve druhém případě z kategorie „něco má“. Případně je možné provádět kontrolu všech tří faktorů, počítat skóre a podle jeho výše pak rozhodovat, zda uživatel procesem autentizace úspěšně prošel nebo ne.

Poznámka: V České republice se problematikou verifikace mluvčího hluboce zabývá výzkumná skupina Speech@FIT z Fakulty informačních technologií Vysokého učení technického, která v tomto oboru patří ke světové špičce.

Závěr: Domníváme se, že pro většinu uživatelů by mohla být autentizace pomocí hlasu přijatelná, neboť na ně neklade prakticky žádné nároky. Lze však tuto metodu autentizace považovat za spolehlivou a bezpečnou?

Related posts:

1. Autentizace: úskalí hlasové autentizace
2. Autentizace: biometrické metody
3. Autentizace: prognóza vývoje v dalších letech

Z informací uvedených na stránkách Ústavu pro jazyk český vyplývá, že čeština má kolem 200.000 slov, a nejmenší Slovník spisovné češtiny pro školu a veřejnost obsahuje zhruba 48.000 hesel představujících jádro spisovné slovní zásoby, přičemž průměrná délka slova je 5 znaků.

Na základě těchto informací můžeme prohlásit, že pokud by passphrase byla tvořena pouhými 3 slovy, tak by včetně dvou mezer měla délku 17 znaků, a to by znamenalo vyzkoušet zhruba 27^17 různých možností, což by trvalo až několik let. Ovšem útok nemusí probíhat jen hrubou silou a rozhodně nemusí být zkoušeny všechny možnosti, nýbrž může být použit algoritmus, který zohledňuje specifika daného jazyka, a nemusí být ani příliš sofistikovaný.

Takový algoritmus může např. zkoušet sestavit passphrase ze všech možných slov, která se nacházejí v daném slovníku. Jedná se o klasické variace, na rozdíl od lámání hesla, kde se používají variace s opakováním. Myslím, že pro stanovení všech možností můžeme předpokládat, že většina uživatelů nepoužije ve své passphrase vícekrát stejné slovo a pokud ano, tak se to na době potřebné k prolomení dané passphrase příliš neprojeví. Počet všech variací spočteme takto: n!/(n-k)!, přičemž „n“ je počet všech slov a „k“ je počet slov v passphrase.

Kdyby passphrase byla krátká věta, řekněme o pouhých 3 slovech, musel by útočník vyzkoušet 48.000!/(48.000-3)! variací. Taková passphrase by byla prolomena i na obyčejném počítači do několika málo dnů. Přidáme-li ještě jedno slovo, získáme passphrase o 4 slovech, což představuje 48.000!/(48.000-4)! variací a prolomení této passphrase by trvalo několik stovek let. Ovšem v případě odpovídající výpočetní kapacity je to otázka několika málo měsíců. Taková passphrase není bezpečná, a proto přidáme další slovo. Získáme tak passphrase o 5 slovech. Útočník by musel vyzkoušet 48.000!/(48.000-5)! variací, a prolomit takovou passphrase by i výkonnému botnetu čítajícímu 1 milión strojů trvalo kolem 20 let. Pro běžný počítač by to byl úkol na několik miliónů let.

Lze tedy passphrase o 5 slovech a průměrné délce 25 znaků považovat za bezpečnou? Zcela určitě ano, protože hrubou silou ani výše uvedeným způsobem není možné takovou passphrase prolomit v rozumném čase. Ovšem je tady jeden malý problém. Výše uvedený počet slov sice tvoří jádro spisovné slovní zásoby, ale to ještě neznamená, že všechna ta slova běžný člověk zná a především, že je i používá. Běžně se uvádí, že dospělý člověk používá kolem 5000 slov. To je dost podstatná informace, nemyslíte? Naprosto, neboť zcela zásadně ovlivňuje dobu potřebnou k prolomení takové passphrase.

Vyjdeme-li z našeho předpokladu, že passphrase je krátká věta o pouhých 3 slovech, stačilo by útočníkovi vyzkoušet jen 5.000!/(5.000-3)! variací. Taková passphrase by byla prolomena na obyčejném počítači v podstatě okamžitě. Přidáme-li ještě jedno slovo, získáme passphrase o 4 slovech, což představuje 5.000!/(5.000-4)! variací a prolomení této passphrase by trvalo několik dní. Taková passphrase není bezpečná, a ani přidáním dalšího slova si příliš nepomůžeme. V případě passphrase o 5 slovech by útočník musel vyzkoušet 5.000!/(5.000-5)! variací, a prolomení takové passphrase by síti o několika 100 strojů trvalo necelý rok. Pro běžný počítač by to byl úkol na několik set let.

Počet všech variací, které útočník musí vyzkoušet, však není n!/(n-k)!. Nezapomínejte, že mezi slovy se dělají běžně mezery a útočník neví, zda je passphrase obsahuje nebo ne, takže variace všech možných slov musí útočník vyzkoušet dvakrát, a to s mezerami a bez mezer, takže když napíšeme 2*n!/(n-k)! neuděláme chybu, ale také si tím příliš nepomůžeme, neboť doba potřebná k prolomení se prodlouží jen dvojnásobně.

Mohli bychom ještě analyzovat četnost výskytu jednotlivých slov, tak jak je uvádí frekvenční slovník a optimalizovat náš algoritmus tak, aby začal nejprve zkoušet ona ustálená a nejčastější slovní spojení a pak teprve ta méně častá a tím podstatně zvýšit teoretickou rychlosti lámání. Jenže uživatelem vytvořená passphrase nemusí obsahovat jen slova spisovná, nýbrž může obsahovat i slangové a odborné výrazy, slova z jiných jazyků, zkomoleniny, úmyslné gramatické chyby, velká písmena, čísla a speciální znaky. Navíc oproti angličtině, kde je pořadí slov ve větě pevně dáno a podoba slova se nemění, tak v češtině toto neplatí.

Na tomto místě je nutné znovu zdůraznit, že útočník zpravidla nikdy neví, jak dlouhou passphrase si uživatel zadal, a tak musí zkoušet všechny variace. Passphrase je stejně jako heslo v systému uložena v podobě hashe, a tak se jaksi nedá v průběhu lámání zjistit, zda se lámání ubírá tím správným směrem. Algoritmus nemá jak poznat, že se mu podařilo první slovo použité v passphrase uhádnout a na základě této informace odvodit zbytek. Útočník proto musí zkoušet celé věty. Ty si samozřejmě může vygenerovat předem nebo je generovat v průběhu hádání.

V okamžiku kdy vaše passphrase nebude obsahovat slova v takové podobě, v jaké jsou uvedena ve slovníku, tak v podstatě nemůže být prolomena jinak než hrubou silou a potom je nutné ji považovat za téměř stejně bezpečnou jako komplexní heslo o dané délce. Toho lze dosáhnout i jinak, než že budete používat velká a malá písmena, čísla a speciální znaky. Stačí třeba v každém slově zdvojit poslední písmeno a nebo…, ale to už necháme na vás.

Závěr: Pokud bychom měli odpovědět na otázku z nadpisu článku, tak se domníváme, že passphrase by se měla skládat minimálně z 5 slov, ale nemělo by se jednat o běžně používanou frázi, známý slogan, oblíbenou písničku, apod. Pokud se budete tímto doporučením řídit, tak i sofistikovaný slovníkový útok proti vaši passphrase velice pravděpodobně selže a vámi zvolenou passphrase se nepodaří nikomu v reálném čase prolomit.

Related posts:

1. Autentizace: Je lepší passphrase nebo komplexní heslo?
2. Autentizace: Jak vytvořit bezpečné heslo?
3. Autentizace: přilož prst

Pokud přijde řeč na autentizaci uživatele do systému pomocí hesla, tak je uživatel dost často nabádán k tomu, aby používal silná hesla, nikam si je nepoznamenával, pravidelně je měnil a rozhodně nepoužíval stejné heslo na více systémech. Smysluplnosti těchto pravidel jsme se věnovali v minulém příspěvku.

Heslo může plnit dobře svojí úlohu pouze tehdy, když není zadáváno na počítači, na kterém se nachází škodlivý kód (přestaňte už konečně stahovat ten warez) a je přenášeno bezpečným kanálem (když web umožňuje komunikovat přes HTTPS, využijte toho). V opačném případě je jedno, jak dlouhé a komplexní vaše heslo je a jak často si ho měníte, protože může být snadno odchyceno a neprodleně použito.

V tomto příspěvku budeme předpokládat, že byla zcizena DB, ve které jsou uloženy hashe hesel a útočník se bude snažit tato hesla prolomit hrubou silou. Na to, že správce systému použil sůl, se spolehnout nemůžeme, a proto budeme naše heslo konstruovat tak, aby odolalo útoku hrubou silou i v případě, že by byly v DB uloženy pouze nesolené hashe. Po pravdě řečeno, ona ta sůl zase až tak moc velký význam nemá, jen útočník nebude moci použít již vygenerované rainbowtables.

Dále si musíme položit otázku, jak často se bude náš hypotetický uživatel hlásit a zda je ochoten zadávat dlouhá hesla obsahující pouze písmena, anebo spíše kratší komplexní hesla obsahující velká a malá písmena, čísla a speciální znaky. Skutečnost je taková, že prolomit hrubou silou komplexní heslo o délce 8 znaků je pro počítač vybavený výkonnou grafickou kartou otázka pouhých několika týdnů (řekl bych, že ten nevychovaný spratek od sousedů takový počítač má, tak abyste se nedivili) a v okamžiku, kdy bude útočník disponovat více počítači (jo, mám na mysli tu partu studentů, co jste posledně potkal v hospodě), tak takové heslo prolomí během několika dnů, no a v případě, že by se jednalo o botnet (ano, to byla ta lákavá nabídka na pronájem 100.000 počítačů, co vám přišla mailem minulý týden), tak se z toho stává otázka na maximálně několik hodin.

A přitom bezpečné heslo, které by odolalo i útoku botnetu čítajícího 10 tisíc až 1 milión strojů, z nichž by každý byl schopen lámat hesla rychlostí 200 miliónů hesel za sekundu, by muselo být dlouhé minimálně 12 znaků a obsahovat velká a malá písmena, čísla a speciální znaky a vydrželo by několik desítek let. Na druhou stranu jen o jeden znak kratší 11znakové heslo by bylo prolomeno do několika měsíců. Možná si říkáte, že 12 znakové heslo je příliš dlouhé, ale myslím, že z tohoto pohledu už je celkem jedno, jestli zadáváte 8znakové nebo 12znakové komplexní heslo.

Další možností je používat delší heslo. Vězte, že takové 16 znakové heslo obsahující pouze písmena by nebylo při použití botnetu prolomeno dříve než za několik let a pokud byste použili velká a malá písmena nebo dokonce i čísla, tak ještě později. Nabízí se tedy otázka, zda by pro většinu lidí nebylo mnohem jednodušší a rychlejší používat spíše delší heslo, než se trápit s nějakými speciálními znaky, které může být někdy i problém zadat a z nichž většina stejně nebude nikdy použita.

Na první pohled se může zdát, že k prolomení komplexního 12 znakového hesla by teoreticky muselo být vyzkoušeno 95^8 různých variací s opakováním, jenže ve skutečnosti to bude někde mezi 62^8 a 95^8 a daleko spíš se budeme blížit k té nižší hodnotě. (Vycházíme z toho, že máme 10 číslic + 26 malých písmen + 26 velkých písmen, což je 62 znaků + 33 speciálních znaků, a dostáváme se na 95 různých znaků.)

Myslím, že můžeme vyslovit závěr, že než sestavovat nějaká komplexní hesla obsahující velká a malá písmena, čísla a speciální znaky, je mnohem efektivnější používat passphrase o minimální délce 16 znaků a nějaká velká a malá písmena a čísla nemusíte vůbec řešit. A jestli si říkáte, že byste si je nezapamatovali, tak si je proboha napište na papír a ten si schovejte na bezpečné místo. A že vaše firemní politika po vás velká a malá písmena, čísla a speciální znaky vyžaduje? Hm, tak tam na začátek flákněte velké písmeno, mezi jednotlivá slova vražte mezeru, na konec tečku a je to.

Nabízí se také otázka, zda to musí být zrovna papírek, kde budete mít hesla zapsaná. Co kdybyste si hesla uložili do svého smartphonu? A co kdybyste si je do svého smartphonu uložili jako obrázek? A vůbec, kam si svá hesla vlastně ukládáte, a neříkejte, že si je všechna pamatujete.

Na základě informací uvedených v příspěvku „Jak vytvořit bezpečnou passphrase“ můžeme prohlásit, že passphrase o 5 slovech a průměrné délce 25 znaků je o něco bezpečnější, než 9 znakové komplexní heslo. A byť se může mnohým jevit passphrase jako méně bezpečná, tak uživateli, který ji bude používat, hrozí za jinak stejných podmínek výrazně menší riziko, že jeho passphrase bude prolomena. Situace by se mohla změnit až v okamžiku, kdy by výrazně větší počet uživatelů začal používat místo komplexního hesla passphrase.

Lámání a hádání hesel však není jediný způsob, jak se může útočník k heslu uživatele dostat. Ne, nebudeme uvažovat keyloggery, malware, MITM a další typy útoků, protože v případě těchto útoků je jedno, jak dlouhé a komplexní heslo nebo passphrase vlastně je. Ty sdílené tajemství jednoduše odchytí. Zamysleme se nyní krátce jen nad jediným typem útoku, a tím je odpozorování passphrase.

Lze předpokládat, že uživatel bude jednotlivé znaky passphrase zadávat minimálně stejně rychle jako u komplexního hesla. Ovšem zapsání passphrase mu bude trvat o něco déle, protože passphrase je prostě delší. A právě délka zvyšuje i riziko, že se uživatel při zadávání passphrase překlepne, a bude ji muset zadávat znovu. Je otázka, zda zadávanou passphrase maskovat a zda nepovolit zobrazení posledního stisknutého znaku. Stejně jako u hesla je dobré si dávat pozor, zda vás při zadávání někdo nepozoruje a vůbec je vhodné dodržovat i další zásady, především nepoužívat stejnou passphrase na více systémech.

Problém je, že těch znaků, které uživatel musí napsat, aby passphrase mohla být považována za bezpečnou, je prostě moc. Jako mnohem jednodušší mi přijde pro přihlašování do systémů používat komplexní heslo vytvořené podle návodu v příspěvku „Jak si vytvořit bezpečné heslo“. Zapamatujete si ho stejně dobře jako passphrase, ale přihlásíte se rychleji. Na druhou stranu útočníkovi stačí odpozorovat část odchyceného hesla a zbytek pak prolomit hrubou silou. To v případě passphrase nemusí být až tak snadné.

Related posts:

1. Autentizace: Jak vytvořit bezpečnou passphrase?
2. Autentizace: Jak vytvořit bezpečné heslo?
3. Autentizace: Jak v systému bezpečně uložit heslo

Systém S/KEY funguje tak, že na tajný klíč K, který vznikne spojením uživatelem zvoleného hesla a výzvy serveru aplikuje N-krát hashovací funkci a vygeneruje přesně N jednorázových hesel (One Time Password, zkr. OTP). Přičemž poslední OTP, které uživatel nikdy zadávat nebude, se spolu s výzvou uloží do DB. Způsob, jakým jsou generována jednotlivá OTP, můžeme jednoduše zapsat takto: H(K), H(H(K))…H^N(K).

Uživatel obdrží seznam OTP v opačném pořadí, než jsou vygenerována, tzn., že na prvním místě jeho seznamu se bude nacházet OTP, které bylo vygenerováno jako poslední. Samotná autentizace pak probíhá tak, že uživatel na výzvu systému zadá OTP, které se v jeho seznamu nachází na prvním místě. Systém aplikuje na toto heslo hashovací funkci H a pokud spočtený hash odpovídá hashi, který má systém uložený ve své DB, je uživatel úspěšně autentizován a do DB se uloží uživatelem právě zadané heslo resp. jeho hash, proti kterému se pak při příští autentizaci porovnání uživatelem zadaného hesla provádí.

Pokud zvolíme jako heslo např. „P4$w0Rd“, challenge bude nabývat hodnoty „3 secret“ a necháme si vygenerovat 4 jednorázová hesla, potom získáme následující jednorázová hesla, přičemž OTP, které se nachází na pozici 0, v našem případě CURD FEUD ODIN OVAL ITEM JIG, uživatel nikdy zadávat nebude, to bude v systému uloženo a použito pouze proto, aby bylo proti čemu porovnat uživatelem zadané heslo.

0: CURD FEUD ODIN OVAL ITEM JIG (6DCF F71C 6519 FC40)
1: NE LOUD SEND WHET BRIM IDEA (2B36 6765 7D85 F33C)
2: BONE BAWL OAF COOK DANA LULU (5C0A 84B7 3546 ED68)
3: OVER SAL REB RISK WARD CRUD (CA67 44DB E82F 76D9)

V okamžiku, kdy se uživatel bude chtít přihlásit do systému, zadá heslo, které se nachází na pozici 1, v tomto případě NE LOUD SEND WHET BRIM IDEA. Systém spočte hash tohoto hesla a porovná ho s uloženým hashem a jelikož se hashe rovnají, je uživatel přihlášen. Uživatel si na svém seznamu heslo na pozici 1 škrtne a pro příští přihlášení použije heslo na pozici 2, což je BONE BAWL OAF COOK DANA LULU, jehož hash je pak porovnáván proti posledně použitému heslu.

Interně S/KEY používá 64bitová čísla. Výstupem hashovací funkce MD5, která bývá v S/KEY využívána je ale řetězec o délce 128 bitů, je zřejmé, že se musí provést ještě nějaká úprava. Ano, je to tak, řetězec se rozdělí na dvě poloviny o 64bitech a na ně se aplikuje funkce XOR. Výsledek je pak převeden do hexadecimální soustavy, takže je možné ho zapsat jako 16 hexadecimálních znaků. Ta by se však uživateli špatně přepisovala, proto se hash prodlouží na 66bitový a rozdělí na šest skupin po 11 bitech. Taková skupina pak může nabývat 2^11, což je 2048 různých hodnot. Každé takové hodnotě pak odpovídá krátké slovo o délce 1 až 4 znaky. A z těchto slov jsou pak složena samotná jednorázová hesla, která uživatel při autentizaci zadává. Uživatel je může zadat i malými písmeny a bez mezer.

On-line generátor OTP hesel naprogramovaný v JavaScriptu je možné si vyzkoušet na adrese http://www.ocf.berkeley.edu/~jjlin/jsotp/ odkud je možné si stáhnout i zdrojový kód.

Related posts:

1. Autentizace: Jednorázová hesla – PINsafe
2. Autentizace: Jsou jednorázová hesla bezpečná?
3. Mac OS X: Lion a nešťastná změna hesla