Čo sa stane s OTP tajomstvami, keď unikne databáza používateľov? Mohol by útočník použiť ich na získanie vašich ďalších citlivých informácií? Ako sú vôbec uložené na serveri?

Ukladanie hesiel #

Jedným z bežne používaných spôsobov prihlasovania do nejakej služby je stále heslo, ktoré zdieľate so serverom a udržiavate v tajnosti. Našťastie, je čoraz bežnejšie vedieť, že tento prístup má určité zraniteľnosti. Útočník sa môže zmocniť vášho hesla, pretože ho môže okrem iného uhádnuť alebo zaznamenať pri písaní.

Tiež je snáď všeobecne známe, že heslá by nemali byť ukladané v plain texte. Keď je vystavená databáza s ľahko čitateľnými heslami, útočník môže vyskúšať získané heslá na rôznych službách a okamžite získa prístup, ak sú heslá znovu použité. Aj keď nie sú znovu použité, prečítanie hesla môže odhaliť vzor použitý na jeho vytvorenie a následne pomôcť uhádnuť iné heslá toho istého používateľa na rôznych službách.

Na ochranu hesiel pred odhalením sú matematicky zahmlené spôsobom, ktorý sa nedá odmlhiť späť, pričom sa zaistí, že aj rovnaké heslá rôznych používateľov sú zahmlené do inej podoby. Tieto procesy sa nazývajú hashing a salting a celý proces je garantovane opakovateľný. Akékoľvek heslo zahmlenéí týmto spôsobom pre toho istého používateľa vždy vráti rovnakú podobu.

Čo sa stane, keď zadáte heslo do prihlasovacieho poľa? Odošle sa na server, kde sa zahashuje a osolí, potom sa porovná s hashom uloženým v databáze. Prístup vám je udelený, keď sa oba hashe presne zhodujú. Problém je, že keďže heslá sa stále doručujú na server spôsobom, ktorý možno prečítať ako plain text, útočník ovládajúci takýto server môže skúsiť prihlásiť sa na iné služby s vašim znovu použitým heslom v momente, keď sa prihlásite.

Na zmiernenie tohto problému by sme nikdy nemali znovu používať heslá a mali by sme používať náhodne generované, pozostávajúce z ťažko zapamätateľných znakov a sekvencií, ktoré sa tiež ťažko správne zadávajú. Poskytovatelia služieb nechcú nútiť svojich používateľov používať takýto veľmi bezpečný, ale úplne nepohodlný prístup, pretože by to zahnalo zákazníkov preč. Navyše server nemá absolútne žiadny spôsob, ako zaručiť, že používateľ použil jedinečné heslo, ktoré nepoužil na žiadnom inom serveri.

OTP alebo jednorazové heslo #

Riešenia na ochranu používateľa s heslom pred útočníkom existujú, ale v súčasnosti neexistuje nič ako dokonalá bezpečnosť. Všeobecným prístupom je pridávanie vrstiev zabezpečenia až do bodu, keď je to stále dostatočne pohodlné. Jednorazové heslá sa bežne používajú ako jedna z takých vrstiev. Zhruba povedané, nepredstavujete sa len jedným heslom, ktoré poznáte, ale aj ďalším, ktoré je pre vás vygenerované.

Aby bolo generované heslo opakovane použiteľné, musí byť zakaždým iné, inak je to len ďalšie heslo. Navyše, akékoľvek heslo, aby bolo charakterizované ako jednorazové heslo, musí byť vždy odmietnuté hneď po prvom použití. Jedným dôsledkom tejto vlastnosti je, že ak sa útočník zmocní takého hesla, ale použije ho po vás, je to prakticky zbytočné a tentokrát nemá šťastie.

Aby bolo generované heslo zakaždým iné, musí byť odvodené z meniacej sa počiatočnej informácie, tiež nazývanej seed hodnota. Aby server mohol toto heslo overiť, musí mať prístup k rovnakej seed hodnote, z ktorej bolo heslo vygenerované. Ignorujúc všetky ostatné možnosti, Unix timestamp spĺňa tento popis. Použitie Unix timestampu je výhodné, pretože uľahčuje generovanie krátkodobého jednorazového hesla, ktoré sa samo zničí nielen pri prvom použití, ale aj po krátkom čase od prvého vydania, bez ohľadu na to, či bolo použité alebo nie. Tento krátky čas je zvyčajne menej ako minúta a útočníkovi veľmi sťažuje úspešné použitie takého prchavého hesla, aj keď ho zachytí. Táto technika sa nazýva Timed One Time Password alebo TOTP.

Bohužiaľ, Unix timestamp je verejná informácia, ku ktorej má útočník prístup tiež, a nemôže byť použitý ako heslo ako taký. Musí byť matematicky skombinovaný s nejakým tajomstvom, ktoré útočník nepozná. Toto tajomstvo je vygenerované na serveri a prenesené na vaše zariadenie počas počiatočného nastavenia, napríklad naskenovaním QR kódu telefónom. Toto tajomstvo sa nazýva OTP secret.

Ukladanie OTP tajomstiev #

Teraz, keď vieme, že OTP secret je kombinovaný s timestampom na generovanie krátkodobého TOTP tokenu, ako sa tiež nazýva, môžeme sa ponoriť trochu hlbšie. Vieme tiež, že heslá sú ukladané spôsobom, ktorý nič neprezrádza, keď sú vystavené. Ale čo OTP tajomstvá? Mohli by byť zahmlené rovnakým spôsobom ako heslá? Naozaj ma zaujímalo nájsť odpoveď na túto otázku.

Hľadaním na internete som dospel k záveru, že to bohužiaľ nefunguje, diskutované tiež tu, pretože server musí vypočítať TOTP token z tajomstva a porovnať ho s tokenom poskytnutým používateľom, nemôže len začať priamym porovnávaním. Aby to fungovalo, tajomstvo musí byť uložené spôsobom, ktorý umožňuje získať pôvodný secret.

Najjednoduchší spôsob splnenia tejto podmienky je uložiť OTP tajomstvá v plain texte. Predstavte si scenár, kde útočník opäť získa prístup k databáze, tentoraz nie len s nečitateľnými heslami, ale aj s veľmi čitateľnými OTP tajomstvami. Ako sa situácia mení? No, môže teraz generovať TOTP tokeny, ktoré by vyzerali ako keby boli od vás, kedykoľvek sa mu zachce, čím efektívne ukradne zariadenie, ktoré ste používali na generovanie tokenov (niečo, čo vlastníte). Stále sa však nemôže prihlásiť do služby vydávajúc sa za vás, pretože nemôže získať heslo (niečo, čo viete).

Kombinácia niečoho, čo viete, s niečím, čo vlastníte, je základom Multi Factor Authentication (MFA). Táto technika opisuje presne dva faktory a zvyčajne sa označuje ako Two Factor Authentication alebo 2FA.

Šifrovanie #

Zrejmý spôsob ochrany OTP tajomstiev je ich šifrovanie, diskutované tiež tu. Toto však funguje len vtedy, keď všeobecný secret použitý na dešifrovanie OTP tajomstiev všetkých používateľov nebol vystavený spolu s databázou. Nie ideálne, ale lepšie ako nič.

Ďalším hľadaním na internete mi bolo čoraz jasnejšie, že zďaleka nie som jediný, kto premýšľa o ochrane OTP tajomstiev na serveri, diskutované tu, tu a tu. Ukazuje sa, že existuje jedno riešenie.

Dešifrovanie OTP tajomstva heslom poskytnutým používateľom. Teraz útočník potrebuje heslo v plain texte, aby získal OTP tajomstvo v plain texte a mohol generovať vlastné TOTP tokeny. Môžete sa chvíľu zastaviť a skúsiť premýšľať, aká je nevýhoda tohto prístupu.

Správcovia hesiel #

Skôr než potvrdím vašu odpoveď, dovoľte mi trochu porozprávať o správcoch hesiel. Správca hesiel je aplikácia, ktorá chráni všetky vaše heslá jediným, nazývaným master heslo. Vaše chránené heslá môžu byť veľmi silné a úplne jedinečné a jediný spôsob, ako sa k nim dostať, je prelomiť vaše master heslo. Ak je použité silné, môže to byť dosť ťažké.

V poslednej dobe správcovia hesiel začali ponúkať aj generovanie TOTP tokenov. Mnohí tvrdia, že to vedie k Single Factor Authentication. Preniknutie do databázy, kde sú uložené vaše heslá aj OTP tajomstvá, je všetko, čo útočník potrebuje na vstup do ktorejkoľvek z vašich tam uložených služieb. Z pohľadu používateľa je to veľmi pohodlné, ale vedie to k falošnému pocitu bezpečnosti. Aby bolo jasno, heslá a OTP tajomstvá by mali byť uložené v databáze chránenej dvoma rôznymi prostriedkami, aby boli bezpečnejšie.

Úprimne povedané, obavy z ukladania OTP tajomstiev v správcovi hesiel spolu so samotnými heslami ma priviedli k objaveniu, že OTP tajomstvá môžu byť vystavené buď zo strany používateľa alebo servera. Táto skutočnosť sama o sebe je pre mňa dosť znepokojujúca.

No, ako som povedal pred chvíľou, strana na serveri môže byť úspešne dešifrovaná heslom poskytnutým používateľom. Ale je tu veľké ale. Ak používateľ požiada o zaslanie nového hesla, server musí buď deaktivovať 2FA alebo inštruovať používateľa, aby znovu inicializoval proces generovania OTP zakaždým, keď sa heslo zmení. Nie som si istý, či to je na nejakej službe skutočne implementované.

Záver #

Správa bezpečnosti je dosť otravná. Niekedy prajem si, aby som nikdy nezačal a len používal jednoduché slabé heslo všade, alebo dokonca žiadne heslo. Ale každý by si mal urobiť vlastný prieskum a usúdiť, akú úroveň súkromia chce zachovať.

Slabé a dokonca slabo znovu použité heslá môžu byť pre bežného používateľa dostatočne chránené aktiváciou 2FA. Ďalším prístupom sú silné heslá so správcom hesiel. Kombinácia oboch svetov prináša najväčšiu bezpečnosť. Lákavý spôsob ochrany OTP kódov rovnakým master heslom, ktoré chráni vaše ostatné heslá, sa považuje za zlú prax. Znižuje pohodlie, pričom zároveň neposkytuje výhody, ktoré poskytuje skutočný druhý faktor. Alebo áno? A príde passwordless dostatočne skoro, aby všetky tieto otázky boli zastarané?

Odkazy #