Názory k článku Postřehy z bezpečnosti: Thorium jako open-source a bezplatný Authenticator od Protonu

> Možnost exportovat TOTP je funkce, která v jiných populárních autentizačních aplikacích, jako jsou Microsoft Authenticator a Authy, velmi chybí.

Pred dvoma rokmi som migroval na novy mobil, pouzivam Micorosft Authentificator. Funkcia exportovat a importovat veci vratane TOTP tam bola.

chápu, že to je pro uživatele zjednodušení, ale schopnost authenikátorů udělat export výrazně snižuje jejich bezpečnost, pak totiž nikdy nevíš, jestli útočník někdy neudělal export a kódy si nepoužívá. Problematické poté je, že nelze snadno ověřit odkud a jestli je používá.

Z pohledu bezpečnosti by měly tyhle 2FA ověřovače být vždy vázané na konkrétní zařízení a mělo by jít ověřit z kterého zařízení byl kód poskytnutý.

Krásná teorie ale člověk občas také potřebuje žít. Ono nejbezpečnější je z jistého úhlu pohledu žít zavřený na samotce za mříží.

ale tak cesty jsou a lze to dělat i bez toho exportu, že. Za mě TOTP a celá schopnost udělat neauditovatelný export a neschopnost ověřit, že 2FA kód zadává konkrétní osoba/zařízení je velké špatné a dostává se nám to na úroveň sms.

Stačí, aby se na zařízení, kde je daný authenicator spustil cizí kód, který bude schopný provést export a máš zaděláno na problém, tenhle únik nemusí pak zanechat žádné stopy.

Tak u TOTP/HOTP je na vstupu shared secret, ktery tak nejak "export" minimalne behem inicializace by design predpoklada - protoze ho musi mit obe strany. Takze ven proste musi... z cehoz samozrejme vyplyva i to omezeni, ze technicky nikdy nejde zarucit, ze kod je svazany s jednou osobou/zarizenim. Je to tak proste navrzene...

chápu, že to je pro uživatele zjednodušení, ale schopnost authenikátorů udělat export výrazně snižuje jejich bezpečnost, pak totiž nikdy nevíš, jestli útočník někdy neudělal export a kódy si nepoužívá.
Aegis má třeba protokol, kde by byl případný export vidět. A export není kvůli zjednodušení, ale kvůli tomu, že když se mi rozbije telefon, importuji zálohu do jiného a můžu se přihlásit do služeb, kde mám nastavený 2FA. Většina normálních společností jako GitHub, Alphabet umožňuje i alternativní metodu 2FA, ale k některým se přihlásíte jen pomocí autentifikační aplikace (a v horším případě jen SMS) a když najednou tu jedinou možnou 2FA metodu nemáte po ruce, máte smůlu...

5. 8. 2025, 10:54 editováno autorem komentáře

Netušil jsem, že konfigurovatelný a exportovatelný TOTP je nějaké terno. Vzhledem k tomu, že hesla a další autentizace mám už dvě dekády na KeePass (aktuálně KeePassXC pro Linux a KeePassDX pro Android), bral jsem to jako standard všech normálních nástrojů této kategorie. Na principiálně neexportovatelné 2FA slouží věci jako FIDO/U2F (což mám taky na YubiKey a IDEM Key).

I kdyby šlo udělat něco jako TOTP s asymetrickým šifrováním (bez shared secret) a generováním neexportovatelného privátního klíče na TPM čipu, museli byste na každou webovou službu zaregistrovat všechna zařízení zvlášť (např. mobil, všechny notebooky apod.), což by byla otrava. A používat jen jedno zařízení (mobil) s ručním opisováním je zase nepraktické a bez záložních možností obnovení i riskantní.

namátkou třeba CyberArk Identity nebo Microsoft Authenticator nepodporují export, nepoužívají shared secret a jsou vázané na zařízení. To, že to je UX peklo neřeším.

U KeePass je jeho vlastnost, že ho lze exportovat, dokonce některé verze i jen změnou konfigurace bez master hesla uměly udělat export, což je super, když ti běžně může na tvém počítači spouště cizí kód kdejaká stránka nebo balíček...

Řešením může být webauthn nebo passkey, pak zařízení registruješ jen vůči tomu, kdo ti poskytuje autoritu a webové aplikace o tom neví. Stejně tak je možné používat oauth2 či openid aj. a delegovat přihlášení na některou velkou službu a neřešit jí u každé aplikace.

TOTP je pořád stejně bezpečné/nebez­pečné, kritický problém by mohl být, kdyby to tak začali používat úplně všichni, tak je rizko prostě moc vysoké. Podobné to bylo se sms, byly super bezpečné, když to nikdo neměl, jakmile to všichni měli, byl problém na světě, protože vynaložené prostředky se rozprostřely mezi spousty cílů...

Nevím, jaké protokoly podporují a používají CyberArk Identity a Microsoft Authenticator, ale TOTP je na shared secret postavené, takže tam prostě je. To, že ho nelze přes UI vytáhnout, je už jen security by obscurity.

KeePass je prostě normální solidně šifrovaný soubor s otevřeným protokolem (plus já bych ho nikdy nepoužíval s closed source softwarem), takže pokud někdo někdy něco exportoval bez master hesla a není to jen pověra, musel to být brutální jednorázový bug v softwaru, který ho předtím zapsal. Každopádně obecnou kompromitovatelnost počítače a věcí, co někdy leží dešifrovaně v paměti (tady bych úplně nezmiňoval kódy webových stránek, těch vrstev ochrany je tam ještě hodně, a kódy balíčků si docela hlídám), si prostě člověk musí uvědomit a vyhodnotit dle účelu, proto jsem právě zmiňoval FIDO. Každopádně cokoliv s podporou TOTP na tom bude z principu úplně stejně blbě.

Delegované přihlášení sice řeší problém UX, ale zase je to delegace mojí absolutní důvěry na prostředníka, což mě neláká, a problém je pro mě i často z principu vycházející sjednocovatelnost účtů (dvě různé webové služby jsou schopné sjednotit mé identity na jejich serverech prostřednictvím ID u prostředníka). Proto mám samostatné mailové adresy na každý login, abych jim to tolik neusnadňoval, a zatím každá delegovaná autentizace, o které jsem si něco četl, by mě o to připravila. Rád se nechám poučit, pokud existuje nějaká jiná.

bohužel vesměs vlastní, takže nic přenosného. Ano, TOTP jak je definovaný v rfc 6238, má prostě čas a sdílené tajemství, což je jeho slabá stránka.

V keepass je to open database trigger, v originálním projektu to mají ještě doteď dokumentované https://keepass.info/help/kb/trigger_examples.html#backuponopen. Konfiguraci může upravit jakýkoliv proces, který běží pod uživatelem, super. Koukám, že to issue v keepassu ještě nemají doteď nějak rozumně vyřešené https://sourceforge.net/p/keepass/discussion/329220/thread/a146e5cf6b/. Keepassxc by to ale neměl mít, co vím.

V rámci oauth2 providerů ti ale běžně každý vrací jiné unikátní ID pro každou třetí stranu, sjednocení se častěji dělá podle jména, emailu či jiných údajů, které se předají nebo které zadáš.

Mít extra email ti nemusí moc pomoc, zejména, když používáš jeden počítač, jeden prohlížeč a nemažeš pořád cookies, těch způsobů jak tě sjednotit je tak strašně moc, že to je těžké se tomu ubránit.

Tak to, že se standardně k keepassu něco s přístupem k uživateli dostane není chyba, ale vlastnost, v dobrém i ve zlém, se kterou je potřeba počítat.
Pokud je to kritické (banka, přístup do firmy, ...), tak se to řešit dá (počínaje správně nastaveným SElinuxem přes SMS až po dedikovaný HW token jako např. SecurID, prostě druhým/dalším faktorem, který je zaručeně mimo dosah útočníka - jak říkáte se to nesmí potkat), u diskuse na rootu je to celkem fuk ;-).

A tak v dobe vzniku TOTP/HOTP (kveten 2011/prosinec 2005) jsme si o nejakem mohli nechat jen zdat... :-) UAF, FIDO2, WebAuthN i Passkeys prisly o "par" let pozdeji. Casova osa je tady taky dulezita.... holt veci se vyviji a plnohodnotna podpora v prohlizecich je take vcelku cerstva... aneb takovy Firefox mel s CTAP2 problemy jeste pred dvema roky.

Ano, v dnesni dobe uz o TOTP nema u novych sluzeb smysl moc premyslet.

přesně tak, je to poplatné době, kdy to vzniklo a v kontextu doby to byla bezpečná evoluce, dnes to je ale zastaralý a jsou vhodnější alternativy.

Stejně tak dnes máme jiné potřeby.

Fakt na TOTP používáš KeePassDX? Tam nemají čtení QR kódů, takže musíš opisovat... A čtení přes foťák a následné sdílení mi o občas házelo chyby.

Keepass2android v tomhle funguje lépe