Úvaha nad použitím TOTP

4.3.2022 20:57 | Přečteno: 4286× | Linux | poslední úprava: 4.3.2022 20:57

Dnes to bude o TOTP (Time-based one-time password), k čemuž jsem se dostal trochu oklikou, jak dále popíšu. Je to trošku delší, snad se na mě nebudete zlobit.

Většina větších služeb, kterí se dají ovládat po internetu, nabízí multifaktorovou autentizaci (MFA). Některým se v pracovním životě dá špatně vyhnout, jako třeba Microsoft Office 365 (závidím těm, kteří dokumentaci nemusí psát ve Wordu). V praxi se to projevuje tak, že kromě hesla člověk musí dodat ještě další kód, většinou zaslaný přes SMS nebo vygenerované jednorázové heslo. Já osobně nerad píšu svoje telefoní číslo, když to není potřeba, takže raději ta jednorázová hesla.

Teď se dostávám k impulsu, který mě přiměl se v tom vrtat. Jednorázová hesla mi generuje aplikace v telefonu (stejně to má asi drtivá většina lidí, která používá jednorázová hesla). Ale můj telefon začíná dosluhovat, takže jsem si probral aplikace v telefonu, abych měl představu, které z nich je potřeba zálohovat a jak se data obnoví, když telefon definitivně umře. Zjistil jsem, že právě aplikace na jednorázová hesla by nějak z principu neměly jít zálohovat mimo zařízení. Našel jsem nějaké články, které tvrdí, že umí migrovat nastavení z telefonu na telefon, ale spíš mi přijde, že radí, jak si nechat vygenorovat novou tajnou hodnotu pro nový teefon, přičemž ten starý musí být k dispozici (https://www.howtogeek.com/682273/how-to-move-microsoft-authenticator-to-a-new-phone/, https://www.howtogeek.com/425994/how-to-move-google-authenticator-to-a-new-phone-or-multiple-phones/). I když u následujícího článku to opravdu vypadá, že Google Authenticator exportuje tajná data https://www.token2.eu/shop/page/how-to-transfer-totp-profiles-from-google-authenticator-to-a-token2-hardware-token.

Pokusil jsem se tedy zjisitit, jak to s tím TOTP vlastně je a jak to udělat, abych nebyl závislý na telefonu.

Co je TOTP (pro ty, kdo to ještě nevědí)

Myšlenka TOTP vychází ze staršího HOTP, který využívá potenciál hashovací funkce (https://en.wikipedia.org/wiki/Hash_function, https://cs.wikipedia.org/wiki/Ha%C5%A1ovac%C3%AD_funkce). Rozeberme si to od konce.

Hashovací funkce

Hashovací funkce je funkce, která ze vstupních dat libovolné délky (posloupnost bytů) vytvoří jinou posloupnost bytů, která má pevnou délku. Této hodnotě tady budeme říkat prostě hash. Teorie k tomu je poměrně složitá, tak raději odkážu na wikipedii. Pro nás je důležité hlavně to, že z hashe není možné vyčíst původní hodnotu (jinak než hrubou silou). Detaily najdete třeba na wikipedii (https://en.wikipedia.org/wiki/Hash_function, https://cs.wikipedia.org/wiki/Ha%C5%A1ovac%C3%AD_funkce). Nechci rozebírat problém kolizí, takže jenom odkazy https://en.wikipedia.org/wiki/Hash_collision, https://cs.wikipedia.org/wiki/Kolize_(funkce)

V praxi se používá několik hashovacích funkcí, občas se nějaká přidá a občas nějaká vypadne, protože se přijde na to, že má nějaké slabiny. Příkladem vyřazené funkce je MD5, naopak SHA-1 stále odolává (https://cs.wikipedia.org/wiki/Secure_Hash_Algorithm, https://en.wikipedia.org/wiki/SHA-1).

Hashovací funkce vyřešila problém bezpečného skladování uživatelských hesel - hesla se prostě neskladují, uchovává se jen hash (ale neřeší problém dopravy hesla po nezabezpečené cestě). Pro autentikaci není potřeba porovnávat hesla, stačí porovnat hashe. Když uživatel zadá heslo, spočítá se hash a porovná se s uloženou hodnotou (Pozn: v praxi ještě přibylo solení https://en.wikipedia.org/wiki/Salt_(cryptography), https://cs.wikipedia.org/wiki/S%C5%AFl_(kryptografie) ). Tak i při úniku souboru (databáze) s hesly ještě nejsou hesla prozrazena. Útočník musí ještě prorazit hashe, což zabere nějaký čas. Samozřejmě se na to nedá úplně spolehnout, s rostoucím výkonem počítačů se některé hashovací funkce ukážou jako slabé a je třeba je nahradit. Taky je otázka, jestli si admin vůbec všimne, že má draze placeného stážistu.

HOTP

Algoritmus HOTP (HMAC-based one-time password, https://en.wikipedia.org/wiki/HMAC, https://cs.wikipedia.org/wiki/HMAC) řeší problém přenosu hesla po nezabezpečené cestě. Nejčastěji se autentikuje klient vůči serveru, takže se přidržím terminologie klient-server, i když obecně se můžou mezi sebou autentikovat libovolné dvě strany. Účelem je, aby útočník, který odposlechne heslo, nezískal nějakou použitelnou informaci.

Obě strany (klient a server) sdílejí tajnou hodnotu (secret key). Kromě toho si musejí obě strany vést čítač, který se každým pokusem o autentizaci zvyšuje. Dá se to představit tak, že počítá pokusy o autentikaci, ale technicky není důvod, aby se začínalo od 0 nebo 1. Stačí, že obě strany ví, na kterém čísle se začíná. Každým pokusem se musí čítač zvýšit, ideálně o 1 (nikdy se nesmí snížit), ale do jisté míry se dá přeskakovat (většinou v důsledku chyby spojení).

Má-li se jedna strana (klient) autentikovat, nejdříve zvedne čítač o 1 a zapíše za sebe tajnou hodnotu a hodnotu čítače (counter). Celou tuto hodnotu zahashuje. Nakonec z hashe spočítá něco, co se dá převést na znaky, které je uživatel schopen přepsat na klávesnici, zpravidla číslo v desítkové soustavě o délce 6-8 znaků, říkejme mu prostě heslo. Toto heslo pošle druhé straně (server). Ta zkusí stejnou a operaci (taky si vede čítač) pro hodnotu čítač+1 a když dojde ke stejnému výsledku, je heslo považováno za správné (valid). Když to nevyjde, zkusí provést stejnou operaci s několka hodnotami následujícími po hodnotě čítače. Maximální počet zvýšení čítače je předem domluven, Když najde shodu, opět je heslo považováno za správné. (Jen) V případě, že server opravdu našel shodu, zvedne hodnotu čítače na hodnotu, při které našel shodu. Pokud útočník odposlechne heslo a nestihne ho uplatnit dřív, než legitimní uživatel, už ho nemá jak uplatnit, protože druhá strana si mezi tím zvedne čítač aspoň o 1. Samozřejmě, že HOTP není imunní proti rozličným útokům jako třeba man-in-the-middle attack, nebo phishingu, takže je potřeba dodržovat základní pravidla síťové bezpečnosti. (našel jsem k tomu poměrně málo článků, takže snad jenom jeden korejsky: http://www.koreascience.or.kr/article/JAKO201110334670187.page)

Odkazy: https://en.wikipedia.org/wiki/HMAC-based_one-time_password, https://datatracker.ietf.org/doc/html/rfc2104, https://datatracker.ietf.org/doc/html/rfc4226.

Tímto způsobem se do jisté míry vyřešil problém autentikace klienta na serveru, ale zase se znovu vrátil problém s bezpečným uložením tajných hodnot na serveru i klientovi. To si člověk zase nevybere.

Pěkný článek tady: https://peterbabic.dev/blog/are-otp-secrets-stored-plaintext/. Mám-li věřit tomuto článku (https://www.researchgate.net/publication/277953442_ENHANCING_TOTP_PROTOCOL_BY_EMBEDDING_CURRENT_GPS_LOCATION), tak dokonce bývají tajné hodnoty uloženy volně v aplikačních datech: "TOTP is adopted in Google Authenticator and Windows Authenticator software. However, this protocol has certain limitations; it uses a static shared key and stores it in a clear form into SQLite database (DB) on the mobile device;"

TOTP

Když máme tak pěkně vymyšlený algoritmus HOTP, půjdeme dál. Proč si pamatovat nějaký čítač, když nám jeden běží kolem? Je to čas. Jediné, co se požaduje je, aby obě strany měly synchronizovaný čas, což je dnes už docela standard. Z aktuálního času se vyrobí celé číslo. To se použije místo čítače v algoritmu HOTP. Tím dostáváme algoritmus TOTP.

Odkazy: https://datatracker.ietf.org/doc/html/rfc6238, https://en.wikipedia.org/wiki/Time-based_one-time_password.

Jako vhodný kandidát na čítač vyrobený z času se nabízí unix time ořezaný na celé číslo. To by ovšem znamenalo, že veškeré výpočty na jedné straně, odeslání a přijetí druhou stranou by se musely odehrát v 1 sekundě. Proto se čítač zvolí jako celá část unix time děleného vhodným číslem, nejčastěji 30 nebo 60. Potom má čítač stejnou hodnotu po dobu 30 nebo 60 sekund, což už je v praxi použitelná hodnota za kterou je uživatel schopen hodnotu přepsat.

Narozdíl od HOTP je v TOTP jiný přístup ke zkoušení vyšší hodnoty čítače. Nejčastěji se vůbec nezkouší jiná hodnota čítače, než ta aktuální podle času serveru (v případě, že klient má přesný čas, nebo se to od něj očekává), nebo se naopak zkouší několik vyšších, ale i nižších hodnot (pokud se čeká, že klient může mít rozhozený čas).

To je asi tak celé. Obsáhlejší vysvětlení a přesné algoritmy naleznete v odkazovaných článcích na wikipediích a příslušných RFC.

TOTP z hlediska uživatele

Teď se podívejme, co z hlediska uživatele znamená zprovoznit si TOTP a následně vygenerovat heslo.

Snad pro každý programovací jazyk existuje knihovna, která implementuje používané hashovací algoritmy nebo přímo TOTP, takže pro programátora je vcelku jednoduché v programu spočítat hash nějakých dat. Takže z tohoto pohledu není s počítáním TOTP problém. Ale přeci jenom uživatel chce hotovou aplikaci.

Aplikace do počítače

(telefon s androidem/iOS je taky počítač) - asi nejrozšířenější způsob. Uživatel si bez dodatečných nákladů (počítač/telefon už má) nainstaluje aplikaci. Server předá aplikaci tajnou hodnotu (secret key), klient si ji načte a serveru pošle vygenerované heslo, čímž potvrdí, že tajnou hodnotu načetl správně (tomuto procesu se anglicky říká enrollement, česky asi registrace). Většinou se k tomu používá QR kód a je to tak trochu slabé místo celého procesu.

V okamžiku, kdy je potřeba vygenerovat heslo, aplikace vezme tajnou hodnotu, systémový čas a spočítá heslo. Do jedné aplikace se dají uložit data pro několik účtů (většinou neomezený počet).

Když se podíváte do Google Store, najdete tam spousty aplikací, které implementují TOTP (klientskou část). Aplikace bych rozdělil do několika skupin podle toho, jak se incialuzuje tajná hodnota:

• server zobrazí QR kód, aplikace si ho načte. Z QR kódu se dozví URL, kde nejspíš dostane vlastní tajnou hodnotu (až tak podrobně jsem to nezkoumal). Takové aplikace jsou pak použitelné jen pro účty u toho, kdo je vydal.
• jako první druh, ale URL se posílá přes SMS. Většinou jde o bankovní aplikace. Výhoda je, že nepoučený uživatel nemá moc co zkazit (o poučeném uživateli darmo mluvit).
• server zobrazí QR kód, aplikace si ho načte. V datech je přímo tajná hodnota. Jelikož je TOTP standardizované (v RFC 6238), dá se čekat, že tyto aplikace budou navzájem záměnné, tj. stačí jedna aplikace na všechny účty. Přijdete tím o nějaké funkce (push notifikace), bez kterých se ovšem dá obejít. Zárověň máte šanci, že místo aplikace můžete použít nějaké HW zařízení (viz dále). Nevýhoda je, že uživatel může být v pokušení uložit si tajnou hodnotu jen tak na disk, co kdyby se náhodou někdy hodila.

Většinou se tyto aplikace instalují na telefon a většinou se ani nenabízejí pro "velký počítač" (Windows, Linux, MAC OS X a další). Vychází se z předpokladu, že člověk primárně použivá počítač a pro telefon sáhne jenom pro jednorázové heslo. V době, kdy standardy HOTP/TOTP vznikaly (od 2005), to tak i bylo a nějaká jednoduchá aplikace by mohla běžet i na staré Nokii, kdyby do ní šly instalovat aplikace. Od té doby šel vývoj divoce dopředu a spousta lidí má jako primární nástroj telefon, takže má autentizační aplikaci na stejném zařízení, což bezpečnosti nepřidá.

Na druhou stranu existují i aplikace, které se nainstalují na PC. Příkladem je MobilePASS+. Takové řešení je oblíbené v korporátech, protože s minimálními náklady si můžeme odškrtnout, že máme 2-faktorovou autentizaci. Z hlediska bezpečnosti to je asi stejné jako předchozí případ, když je obojí na telefonu. Většinou se to tak dělá proto, že nějaká outsorcovaná služba vyžaduje dvou nebo vícefaktorovou autentozaci (2FA, MFA).

Dedikované hardwarové zařízení

Anglicky se jim říká Hardware Token (https://mfa.uwo.ca/tokens_and_keys.html), česky proto nemám lepší překlad, tak budu psát prostě token.

Pomyslný protiklad aplikace. Zařízení má většinou tvar malé krabičky, od velikost platební karty až po malou kalkulačku. Zařízení je plně soběstačné, jenom se nesmí vybít baterka. Token musí iniciovat (naprogramovat, nakonfigurovat) strana serveru, potom se musí fyzicky dopravit uživateli. Protože v krabičce běží hodiny, musí být napájena baterkou, která má životnost až několik let. Když uživatel potřebuje heslo, stiskne tlačítko a heslo se objeví na vestavěném displeji.

V marketingových materiálech jsem nenašel informaci, jestli v tokenu jsou data jen pro jeden účet, nebo v něm je uloženo víc účtů. Ale počítám, že tam bude jen jeden. Takže asi to není vhodný kandidát na přenesení všech účtů, které máte uložené v aplikaci v telefonu.

Když jsem zkoušel googlit nějaká taková zařízení, přišlo mi, že je docela velký výběr. (https://guide.duo.com/tokens, https://www.token2.com/shop/, https://www.protectimus.com/slim-mini/index.php, https://deepnetsecurity.com/authenticators/one-time-password/) Většina z nich je opakovaně programovatelná buď přes USB nebo přes NFC. Většinou se z bezpečnostních důvodů při nastavení času smaže tajná hodnota.

HW token je používán v aplikacích, kde je potřeba ještě vyšší bezpečnost než poskytne aplikace v telefonu. Telefon je totiž zranitelný na dálku, kdežto HW token nekomunikuje s okolím. HW tokeny nejspíš používají jenom banky a podobné instituce, jinde by asi uživatelé nebyli ochotní platit měsíční poplatek za zapůjčení tokenu.

Oproti aplikaci v telefonu/počítači je zde několik rozdílů. Z bezpečnostních důvodů není žádoucí aby token komunikoval s okolím. Proto hodiny nejsou synchronizované se správným časem (nemají jak). Nejde to ani manuálně, protože možnost přestavit čas je považována za bezpečnostní riziko. Mohlo by dojít k tomu, že útočník, který získá přístup k tokenu, přestaví čas na budoucnost, nechá si vygenerovat hesla a pak čas zase vrátí zpátky, aby majitel nic nepoznal (time traveller attack).

Běžně se udává, že se hodiny v tokenu můžou rozejít o 1,5 až 2 minuty za rok. Pro srovnání - u digitálních hodinek se většinu udává nepřesnost 15 - 20 sekund za měsíc, což dává až 4 minuty za rok. V praxi jsou ale hodinky mnohem přesnější, jedno měření jsem našel třeba tady: https://thetruthaboutwatches.com/2021/06/watch-accuracy-rolex-vs-casio/, většina hodinek tam má přesnost lepší než 0,2 s za den, což odpovídá 6 sekund za měsíc nebo 72 s za rok. Trošku nechápu, proč nemůžou do tokenu dát přesnější čipy, když v hodinkách být můžou.

Nepřesnost hodin (time drift, time-skew) je docela noční můra pro provozovatele serverů. Protože nemůžou odstřihnout zákazníky s nepřesnými hodinami, musí i jim umožnit se autentikovat. Nejjednodušší způsob je zkusit kromě čítače odpovídajícího správnému času i několik vyšších, a nižších hodnot (narozdíl od HOTP). Proto je životnost bezpečnostních tokenů uměle omezena, například na jeden rok, poté se musí vrátit vydavateli, který jej přeprogramuje nebo skartuje, do toho nevidím.

Hardwarové tokeny nejsou tak oblíbené jako aplikace v telefonu, hlavně kvůli ceně. Podívejte se do ceníku své banky, na kolik to přijde, pokud je banka vůbec nabízí. Jedním z prvních průkopníků byla E-banka. Schválně, kdo si dnes pamatuje na E-banku? (https://cs.wikipedia.org/wiki/EBanka).

Zákazníci jsou samozřejmě leniví a pohodlní a rádi vymění bezpečnost za pohodlí. Výrobci jim nakonec samozřejmě vyjdou vstříc, takže existují tokeny, kde se dá čas v tokenu přenastavit, navíc přes NFC. (https://token2.medium.com/time-drift-a-major-downside-of-totp-hardware-tokens-c164c2ec9252, https://www.token2.swiss/shop/category/programmable-tokens). Pěkný článek: https://blog.syss.com/posts/security-of-totp-tokens/, https://www.syss.de/fileadmin/dokumente/Publikationen/2021/2021_06_21_Deeg-Klostermeier_On_the_Security_of_TOTP_Hardware_Tokens.pdf. Hledal jsem podobné výzkumy i pro aplikace v telefonu. Kupodivu jsem nic nenašel. Nikomu asi nevadí, že se dá v telefonu posunout čas. Pravda je, že v tom tokenu se to dá udělat přes NFC bez dalšího potvrzování.

Hybridní zařízení

Jako hybridní zařízení označuji zařízení, která se připojují do počítače nebo telefonu. Také se jim říká Security Keys (https://mfa.uwo.ca/tokens_and_keys.html). Většinou to jsou malé věci, které se připojují přes USB. Příkladem jsou zařízení firmy Yubico, o kterých jsem už taky kdysi psal. (https://www.yubico.com/products/yubikey-5-overview). Ale samozřejmě existují další výrobci.

Tato zařízení spojují některé vlastnosti obou přístupů - aplikace a tokenu (ne vždy dobré vlastnosti - třeba time traveller attack mi přijde u takových zařízení jednodušší). Může na něm být víc účtů. Přesný čas se bere z telefonu/počítače, zatímco tajná data jsou na externím zařízení (klíči), které nikdy neopustí (aspoň v to doufám). Sice je pořád potřeba telefon nebo počítač, ale stačí jen nainstalovat aplikaci a zapojit klíč, na kterém jsou potřebná data.

Samozřejmě je zde pořád riziko, že útočník nějak hackne klíč zapojený do USB. Útočník to má trochu komplikované tím, že v základním nastavení je třeba pro každou akci fyzicky se dotknout klíče.

Praktické postřehy

Ke svým experimentům jsem použil klíče Yubico. Yubico nabízí ke svým klíčům aplikaci pro Android, Windows, Linux a MAC OS. Přestože klíče mají NFC, v případě TOTP je třeba připojit je přes kabel (NFC je rezervované pro jiné účely). Načtení tajné hodnoty se dá udělat buď přes čtení QR kódu (zobrazeného na monitoru/displeji nebo přes kameru) nebo i přes klasické vstupní políčko (to se hodí například, pokud QR kód snímáte jinu aplikací). Jakmile je hodnota načtená, uloží se do klíče a už se nedá vytáhnout.

V okamžiku použití se zvolí příslušný účet a pak je potřeba dotknout se klíče (pokud si to nenastavíte jinak) a zobrazí se heslo.

Takto jsem pokusně vyřešil TOTP pro Paypal a Microsoft a obojí funguje.

V praxi je potřeba ta stejná data nacpat do několika klíčů, pro případ, že by jeden selhal. Dělá se to tak, že necháte na monitoru viset QR kód, načtete ho postupně do všech klíčů a teprve s posledním z nich dokončíte registraci (enrollment). Taky by samozřemě šlo si hodnotu z QR kódu uložit do souboru a pak do klíčů kopírovat přes copy-paste. Ale nechci nikoho navádět k tomu, aby si tajnou hodnotu ukládal na disk, byť šifrovaný,

Povedlo se mi snížit závislost na datech uložených v telefonu. Abych mohl vygenerovat TOTP, stačí na libovolný počítač nainstalovat aplikaci, zapojit klíč a je hotovo. Na druhou stranu s bankovními aplikacemi to není tak jednoduché, ale když je nejhůř, dá se dojít do banky a požádat o novou registraci aplikace.

Slovníček

• MFA multi-factor authentication, vícefázové ověření https://cs.wikipedia.org/wiki/V%C3%ADcef%C3%A1zov%C3%A9_ov%C4%9B%C5%99en%C3%AD
• 2FA two-factor authentication, dvoufázové ověření, podmnnožina MFA
• HOTP HMAC-based one-time password, https://en.wikipedia.org/wiki/HMAC-based_one-time_password
• HMAC hash-based message authentication code https://en.wikipedia.org/wiki/HMAC
• TOTP Time-based one-time password, https://en.wikipedia.org/wiki/Time-based_one-time_password
• SHA Secure Hash Algorithms, https://en.wikipedia.org/wiki/Secure_Hash_Algorithms, https://cs.wikipedia.org/wiki/Secure_Hash_Algorithm

       

Obrázky

Komentáře

[jancici]

ja používam AUTHY na telefóne aj na desktope, dá sa to zosynchronizovať, teda že si tam vieš pridať viacero zariadení.

ak ľahne fón tak mám funkčnú kópiu na dekstope kde starý fón odstránim a priddám nový

[Tomáš]

Nevím, jestli to je dobrý způsob. Nejspíš to je chráněné heslem, takže jsme zhruba na té úrovni, že používáš nějaký password manager, ke kterém si pamatuješ jedno heslo (já bych se bál, že po dovolené si už nevzpomenu). Myslím, že TOTP mělo vyšší ambice, ale to by předpokládalo použití HW zařízení, které tu tajnou hodnotu nikdy nevydá, ani když ho budeš přemlouvat JTAGem či nějakou destruktivní metodou.

Když se víceméně hromadně přešlo na generování TOTP v aplikaci, tak už to je asi jedno, protože ta aplikace musí někde mít tu tajnu hodnotu v otevřené formě (po dobu výpočtu). Ještě je možnost, že by v telefonu byl nějaký bezpečnostní čip, který by se choval jako ten USB klíč, takže by se uživateli ušetřilo připojování klíče. Ale to by se zase narazilo na jiné problémy, např. jak nahrát tajnou hodnotu na jiné (záložní) zařízení, jak spolehlivě zlikvidovat data, když se zbavuješ starého telefonu atd. Při ceně toho USB klíče kolem 30-40 dolarů za kus si dopřeješ 2-3 kusy, ale kupovat 3 telefony asi nechceš.

[ehmmm]

Jo tak s timhle jsem taky bojoval.

K zakaznikovi jsme se pripojovali pres OpenVPN a k osobnimu certifikatu bylo jeste nejake jmeno/heslo. IT zakaznika usoudilo, ze to neni bezpecne (je pravda, ze ja to jmeno/heslo mel v souboru a v *.ovpn se odkazoval na tento soubor), tak zavedli tohle sesticislo zavisle na heslu (najekym dlouhym textu, ktery obvykle je v QR kodu, ale je konstantni) a casu a kazdych 30 sekund se meni.

Tak to ne. Poslepoval jsem skript v Pythonu, ktery spusti OpenVPN, podle hesla spocita sesticislo, preda ho OpenVPN a jedeme.

[Heretik]

HOTP je logicky špatně už jako koncept. S velmi velkým počtem neúspěšných útoků útočník znemožní legitimní autentikaci, když se čítač servru dostane mimo rozsah klienta, například řádově.

Při trvalém nebo rychlejším útoku klient nedohoní útočníka do platného rozsahu nikdy.

V tomto případě se jedná o jednoduchou indirekci aditivní operace na vnitřním stavu která je přístupná útočníkovi přímo.

Uvedený protokol proto považuji za hračkový až dementní.

[Tomáš]

Pokud jsem to pochopil spravne, tak citac se zveda az pri uspesnem pokusu.

Na obranu pred DOS utokem se samozrejme daji nasadit standardni vychytavky, jako umele natahovani overeni hesla (proste se pocka 1 sekunda, nez se vrati vysledek), zablokuje se na pul hodiny zdrojova adresa apod. (Obzvlaste "oblibene" je zablokovani uctu na pul hodiny.)

[Kate]

Jeden postřeh pro tvůrce aplikací: Prosím nechte uživatele nastavit víc než jeden generátor. Spousta lidí má třeba dva yubikey klíče.

A drobná korekce: Yubikey TOTP s NFC funguje. Alespoň u Yubikey 5.

[Max]

Jaké ověřování proti službám vlastně používáte? Pořád přemýšlím, jaké 2FA použít pro ověřování na různých druzích serverů a služeb.
Bavím se jak o Linuxu (ssh), tak o Windows (rdp, kerberos apod.).
Zatím jsem došel k Yubikey, ale pořád nevím nevím, zda tím jde pokrýt vše :-/.
Na Linuxu už 2FA jedu, ale chtěl bych to změnit na něco jiného, současný druh 2FA mi moc nevyhovuje.
Zdar Max