Időalapú egyszer használatos jelszó (TOTP): A hitelesítési algoritmus működése és célja

A digitális világban az online identitásunk védelme alapvető fontosságú. A felhasználónevek és jelszavak régóta képezik a hitelesítés gerincét, ám önmagukban már nem elegendőek a napjainkban egyre kifinomultabbá váló kiberfenyegetésekkel szemben. Ezen a ponton lép be a képbe a multifaktoros hitelesítés (MFA), amely további biztonsági rétegeket ad a bejelentkezési folyamathoz. Az MFA egyik legelterjedtebb és legmegbízhatóbb formája az Időalapú egyszer használatos jelszó (TOTP), amely egy rövid ideig érvényes, egyedi kódot generál a felhasználó számára.

A TOTP nem csupán egy technikai megoldás; egy olyan elv, amely a kiberbiztonság alapvető pilléreit erősíti meg: a valamit, amit tudsz (jelszó) és a valamit, amid van (telefon, hardveres token) kombinációját. Ez a megközelítés drámaian csökkenti a fiókfeltörések kockázatát, még akkor is, ha a jelszó valamilyen módon illetéktelen kezekbe kerül.

A TOTP algoritmusának megértése kulcsfontosságú ahhoz, hogy teljes mértékben értékelni tudjuk a nyújtotta biztonságot és megismerjük alkalmazási lehetőségeit. Ez a cikk részletesen bemutatja a TOTP működését, célját, előnyeit és hátrányait, valamint gyakorlati megvalósítási szempontjait a felhasználók és fejlesztők számára egyaránt.

Mi az Időalapú egyszer használatos jelszó (TOTP)?

Az Időalapú egyszer használatos jelszó, vagy angolul Time-based One-Time Password (TOTP), egy olyan algoritmus, amely egy rövid ideig érvényes, egyszer használatos numerikus kódot generál. Ez a kód jellemzően 30 vagy 60 másodpercig érvényes, és utána automatikusan új generálódik. A TOTP a HMAC-alapú egyszer használatos jelszó (HOTP) algoritmus továbbfejlesztett változata, amelyet az RFC 4226 szabvány ír le. A TOTP-t az RFC 6238 szabványosította, és széles körben alkalmazzák a kétfaktoros hitelesítés (2FA) részeként.

A TOTP alapvető célja az, hogy egy dinamikusan változó, kiszámíthatatlan második hitelesítési faktort biztosítson. Míg egy statikus jelszó hosszú ideig érvényes, és ismételten felhasználható, addig a TOTP kódja rendkívül rövid élettartamú, és minden bejelentkezési kísérlethez (vagy adott időintervallumon belül) egyedi. Ez megakadályozza az úgynevezett replay-támadásokat, ahol egy elfogott jelszót újra felhasználnak a rendszerbe való bejutáshoz.

A TOTP rendszerek két fő komponensből állnak:

• Kliens (generátor): Ez jellemzően egy okostelefonon futó hitelesítő alkalmazás (pl. Google Authenticator, Microsoft Authenticator, Authy), vagy egy dedikált hardveres token. Ez az eszköz generálja a TOTP kódot.
• Szerver (validátor): Ez az a rendszer, amelyhez a felhasználó be szeretne jelentkezni (pl. Google, Facebook, banki alkalmazás). A szerver felelős a generált kód ellenőrzéséért.

A TOTP használata jelentősen növeli a felhasználói fiókok biztonságát. Még ha egy támadó meg is szerzi a felhasználó jelszavát, nem fog tudni bejelentkezni a fiókba a TOTP kód nélkül, amelyet csak a felhasználó birtokában lévő eszköz tud generálni.

A TOTP algoritmus működésének alapelvei

A TOTP működésének megértéséhez három alapvető fogalmat kell tisztáznunk:

1. Megosztott titkos kulcs (Shared Secret Key): Ez egy egyedi, véletlenszerűen generált bináris kulcs, amelyet a felhasználó fiókjának beállítása során hoznak létre. Ezt a kulcsot a szerver biztonságosan tárolja, és a felhasználó hitelesítő alkalmazása is megkapja (jellemzően QR-kód formájában beolvasva). Ez a kulcs soha nem kerül átvitelre a hálózaton keresztül a hitelesítési folyamat során. Ez az alapja a TOTP biztonságának.
2. Időalap (Time-based Factor): A TOTP a jelenlegi időt veszi figyelembe a kód generálásakor. Az időt egy előre meghatározott időintervallumokra (jellemzően 30 másodperc) osztják, amelyeket „időlépéseknek” (time steps) neveznek. Mind a kliens, mind a szerver ugyanazt az időt és időlépést használja a számításhoz.
3. Kriptográfiai hash függvény (Cryptographic Hash Function): A TOTP a HMAC (Keyed-Hash Message Authentication Code) eljárást alkalmazza, amely egy titkos kulccsal és egy üzenettel (ez esetben az időalappal) együtt egy determinisztikus hash értéket állít elő. A leggyakrabban használt hash függvény az SHA-1, de egyre inkább terjed az SHA-256 és az SHA-512 is a nagyobb biztonság érdekében.

A TOTP kód generálása a következő lépésekben történik:

1. Időlépés számítása: Az aktuális UTC időt (koordinált világidő) elosztják az előre meghatározott időlépés hosszával (pl. 30 másodperc). Az eredmény egész része adja meg az aktuális időlépés sorszámát. Ezt nevezzük T értéknek. Például, ha az aktuális idő 16:00:45, és az időlépés 30 másodperc, akkor az időlépés sorszáma: floor(16:00:45 / 30 másodperc) = floor(16:00:30-16:00:59 közötti idő). A tényleges számítás a Unix időbélyegen alapszik.
2. HMAC számítása: A megosztott titkos kulcsot (K) és az aktuális időlépés sorszámát (T) bemenetként használva kiszámítják az HMAC hash értéket. A képlet valahogy így néz ki: HMAC(K, T). Az eredmény egy hosszú bináris érték.
3. Dinamikus csonkolás (Dynamic Truncation): A kapott HMAC hash értékből egy specifikus algoritmus segítségével kivágnak egy 4 bájtos (32 bites) részt. Ez a kiválasztás dinamikus, a hash érték utolsó bájtjának alsó 4 bitje határozza meg, honnan kezdődik a kivágás. Ez biztosítja, hogy a kód minden generáláskor véletlenszerűen eltérő pozícióról kerüljön kivágásra, növelve a biztonságot.
4. Numerikus kód generálása: A kivágott 32 bites értéket egy decimális számmá alakítják, majd csonkolják a kívánt számjegyre (jellemzően 6 vagy 8 számjegyre). Például, ha a 32 bites értékből kapott szám 123456789, és 6 számjegyű kódot szeretnénk, akkor a végeredmény 456789 lesz (modulo 1.000.000).

Az egész folyamat rendkívül gyors, és mind a kliens, mind a szerver képes azt másodpercek alatt elvégezni. A kulcs a pontos időszinkronizáció. Ha a kliens és a szerver órája jelentősen eltér egymástól, a generált kódok nem fognak egyezni, és a hitelesítés sikertelen lesz. Ezért a szerverek gyakran elfogadnak egy „időablakot”, azaz nem csak az aktuális időlépéshez tartozó kódot, hanem az előző és a következő időlépéshez tartozó kódot is elfogadhatják, hogy kompenzálják a kisebb időeltéréseket.

A TOTP alapvető ereje abban rejlik, hogy egyetlen, statikus titkos kulcs és az idő folyamatosan változó természete alapján képes egy dinamikusan változó, rövid élettartamú, mégis megbízhatóan ellenőrizhető hitelesítési faktort létrehozni, minimalizálva a visszaélés lehetőségét.

A TOTP beállítása és hitelesítési folyamata

A TOTP beállítása, vagy más néven „regisztrációja”, egy egyszeri folyamat, amely során a felhasználó összekapcsolja a hitelesítő alkalmazását a szolgáltató rendszerével. Ezt követően a bejelentkezési folyamat során a felhasználónak be kell írnia a generált kódot.

A TOTP beállítása (Enrollment)

A beállítási folyamat általában a következőképpen zajlik:

1. A felhasználó kezdeményezi a 2FA beállítását: A szolgáltató weboldalán vagy alkalmazásában a „Biztonság” vagy „Fiókbeállítások” menüpont alatt a felhasználó kiválasztja a kétfaktoros hitelesítés engedélyezését, és azon belül a hitelesítő alkalmazás (Authenticator App) opciót.
2. Szerver generálja a titkos kulcsot: A szolgáltató szervere ekkor generál egy egyedi, véletlenszerű, kriptográfiailag erős titkos kulcsot (általában 16-32 bájt hosszú, Base32 kódolásban). Ezt a kulcsot a szerver biztonságosan tárolja a felhasználó fiókjához rendelve.
3. QR-kód megjelenítése: A szerver ezt a titkos kulcsot egy speciális URI (Uniform Resource Identifier) formátumba ágyazza, amelyet aztán QR-kódként jelenít meg a felhasználó számára a képernyőn. Ez az URI szabványosított formátumú, az otpauth:// sémát használja, és tartalmazza a titkos kulcsot, a felhasználó fiókjának azonosítóját (pl. email cím), a szolgáltató nevét, a kód hosszát (6 vagy 8 számjegy), és az időlépés hosszát (általában 30 másodperc).
4. Felhasználó beolvassa a QR-kódot: A felhasználó megnyitja a preferált hitelesítő alkalmazását (pl. Google Authenticator), és kiválasztja a „QR-kód beolvasása” opciót. Az alkalmazás beolvassa a QR-kódot, kinyeri belőle a titkos kulcsot és a kapcsolódó beállításokat (szolgáltató neve, fiók azonosítója).
5. Kulcs tárolása a kliensen: A hitelesítő alkalmazás biztonságosan eltárolja a titkos kulcsot a felhasználó eszközén. Ettől a ponttól kezdve az alkalmazás képes lesz TOTP kódokat generálni a tárolt kulcs és az aktuális idő alapján.
6. Opcionális ellenőrzés: Néhány szolgáltató megkéri a felhasználót, hogy a beállítás után azonnal írja be az első generált TOTP kódot, hogy megbizonyosodjon arról, hogy a beállítás sikeres volt, és az időszinkronizáció is megfelelő.

Fontos: A titkos kulcsot soha ne ossza meg mással! Ez a kulcs a TOTP rendszer szíve, és a kompromittálása a fiók feltöréséhez vezethet.

A TOTP hitelesítési folyamata

Miután a TOTP beállítása megtörtént, a bejelentkezési folyamat a következőképpen módosul:

1. Felhasználó megadja a felhasználónevét és jelszavát: A felhasználó a szokásos módon beírja a felhasználónevét és a jelszavát a szolgáltató bejelentkezési oldalán.
2. Szerver ellenőrzi a jelszót: A szerver ellenőrzi a megadott jelszót. Ha a jelszó helyes, a szerver továbblép a második faktor kérésére.
3. Szerver kéri a TOTP kódot: A szerver egy új mezőt jelenít meg, ahol a felhasználónak be kell írnia az egyszer használatos kódot.
4. Felhasználó generálja a TOTP kódot: A felhasználó megnyitja a hitelesítő alkalmazását a telefonján. Az alkalmazás automatikusan generálja és megjeleníti az aktuális, érvényes TOTP kódot (amely 30 vagy 60 másodpercenként frissül).
5. Felhasználó beírja a TOTP kódot: A felhasználó beírja a hitelesítő alkalmazás által generált kódot a szolgáltató bejelentkezési oldalán lévő mezőbe.
6. Szerver ellenőrzi a TOTP kódot:
   • A szerver a saját belső órája és a felhasználóhoz tartozó, tárolt titkos kulcs segítségével kiszámítja a várható TOTP kódot.
   • A szerver jellemzően nem csak az aktuális időlépéshez tartozó kódot ellenőrzi, hanem az előző és a következő időlépésekhez tartozó kódokat is (ez az ún. „időablak” vagy „drift window”). Ez kompenzálja a kliens és a szerver órája közötti kisebb eltéréseket. Az RFC 6238 ajánlása szerint a szervernek legalább egy perccel előre és hátra (azaz 2*30 másodperc = 2 időlépés) kell ellenőriznie az időt.
   • Ha a felhasználó által megadott kód megegyezik a szerver által számított valamelyik érvényes kóddal az időablakon belül, a hitelesítés sikeresnek minősül.
7. Sikeres bejelentkezés: Ha mindkét faktor (jelszó és TOTP kód) helyes, a felhasználó sikeresen bejelentkezik a fiókjába.

A folyamat zökkenőmentes és gyors, a felhasználó számára pedig mindössze annyit jelent, hogy egy extra lépést kell megtennie a bejelentkezéshez, cserébe jelentősen megnövelt biztonságot kap.

A TOTP előnyei

A TOTP széles körű elterjedtsége nem véletlen. Számos előnnyel rendelkezik más hitelesítési módszerekkel szemben, amelyek hozzájárulnak a felhasználói fiókok biztonságának és a felhasználói élmény javításához.

1. Fokozott biztonság a jelszófeltörések ellen

Ez a legnyilvánvalóbb és legfontosabb előny. Még ha egy támadó meg is szerzi a felhasználó jelszavát egy adatszivárgásból vagy phishing támadásból, nem fog tudni bejelentkezni a fiókba a TOTP kód nélkül. A kód rövid élettartama (30-60 másodperc) miatt a támadó nem tudja újra felhasználni még akkor sem, ha valahogyan megszerzi azt. Ez a phishing-ellenállóság teszi a TOTP-t különösen értékessé a statikus jelszavakkal vagy SMS-alapú OTP-kkel szemben.

2. Offline működés

A TOTP kódok generálásához nincs szükség internetkapcsolatra a kliens oldalon. Mivel a számítás a titkos kulcs és az eszköz helyi ideje alapján történik, a felhasználó generálhat TOTP kódot még akkor is, ha nincs mobilhálózati vagy Wi-Fi kapcsolata. Ez különösen hasznos utazáskor vagy olyan helyeken, ahol a hálózati lefedettség gyenge.

3. Nyílt szabvány

A TOTP egy nyílt szabvány (RFC 6238), ami azt jelenti, hogy bárki szabadon implementálhatja. Ez elősegíti az interoperabilitást: egyetlen hitelesítő alkalmazás (pl. Google Authenticator, Authy) használható több különböző szolgáltató fiókjához is, feltéve, hogy azok támogatják a TOTP-t. Ez csökkenti a felhasználók terhét, mivel nem kell minden szolgáltatóhoz külön alkalmazást használniuk.

4. Költséghatékony és könnyen implementálható

A TOTP szoftveres implementációja viszonylag egyszerű mind a kliens, mind a szerver oldalon. Nincs szükség drága hardveres eszközökre (bár léteznek hardveres TOTP tokenek is), és nincsenek tranzakciós költségek, mint az SMS-alapú OTP-k esetében, ahol minden üzenetküldés díjjal járhat. Ez különösen vonzóvá teszi a kis- és középvállalkozások, valamint az egyéni felhasználók számára.

5. Védelem a replay-támadások ellen

Mivel minden TOTP kód csak egy rövid időintervallumon belül érvényes és egyszer használatos, egy támadó nem tudja elfogni és később újra felhasználni a kódot a rendszerbe való bejutáshoz. Az időalapú természete miatt az előzőleg generált kódok azonnal érvénytelenné válnak.

6. Felhasználói kényelem (az SMS OTP-hez képest)

Bár a TOTP egy extra lépést jelent, sok felhasználó kényelmesebbnek találja, mint az SMS OTP-t. Nincs szükség a hálózati lefedettségre, nem kell várni az SMS megérkezésére, és elkerülhetők az SMS-alapú támadások (pl. SIM-swap). Az alkalmazás azonnal megjeleníti a kódot, ami gyorsabb bejelentkezést tesz lehetővé.

7. Hardveres tokenek támogatása

A TOTP algoritmus nem korlátozódik szoftveres hitelesítő alkalmazásokra. Léteznek dedikált hardveres tokenek is, amelyek beépített kijelzővel rendelkeznek, és automatikusan generálják a TOTP kódokat. Ezek különösen hasznosak lehetnek magas biztonságú környezetekben, ahol a telefonos alkalmazások használata nem megengedett vagy nem kívánatos.

Összességében a TOTP egy robusztus, széles körben elfogadott és hatékony megoldás a multifaktoros hitelesítésre, amely jelentősen hozzájárul az online biztonság növeléséhez.

A TOTP hátrányai és korlátai

Bár a TOTP számos előnnyel jár, fontos felismerni a korlátait és potenciális hátrányait is. Ezek megértése segíthet a biztonsági stratégia optimalizálásában és a lehetséges kockázatok minimalizálásában.

1. Időszinkronizációs problémák (Time Drift)

A TOTP a pontos időszinkronizációra épül a kliens (hitelesítő alkalmazás) és a szerver között. Ha az eszköz órája jelentősen eltér a szerver idejétől (pl. több perccel), a generált kódok érvénytelenek lesznek, még akkor is, ha a titkos kulcs helyes. Bár a szerverek gyakran alkalmaznak egy „időablakot” (pl. elfogadnak 1-2 perccel korábbi vagy későbbi kódokat), a nagyobb eltérések továbbra is problémát okozhatnak. Ez különösen akkor fordulhat elő, ha a felhasználó manuálisan állítja be az eszköz óráját, vagy ha az eszköz akkumulátora lemerül, és emiatt az óra visszaáll.

2. Eszköz elvesztése vagy ellopása

Ha a felhasználó elveszíti vagy ellopják a telefonját, amelyen a hitelesítő alkalmazás fut, elveszíti a TOTP kódok generálásának képességét. Ez kizárhatja a felhasználót a fiókjából. Ezért elengedhetetlen a megfelelő helyreállítási protokollok megléte (pl. egyszer használatos helyreállítási kódok, alternatív hitelesítési módszerek, ügyfélszolgálati azonosítás).

3. Titkos kulcs kompromittálása

A TOTP biztonsága teljes mértékben a megosztott titkos kulcs titkosságán alapul. Ha ez a kulcs valamilyen módon illetéktelen kezekbe kerül (pl. a szerver adatbázisának feltörése, vagy a felhasználó eszközének rootolása/jailbreakelése révén), akkor a támadó képes lesz TOTP kódokat generálni. Emiatt a szerver oldalon a kulcsok tárolása rendkívül biztonságos módon kell, hogy történjen (titkosítva, hozzáférés-vezérléssel).

4. Felhasználói hibák és szociális mérnöki támadások

A TOTP nem véd a szociális mérnöki támadások ellen, ha a felhasználót ráveszik, hogy adja meg a TOTP kódját egy hamis bejelentkezési oldalon (phishing). Bár a kód rövid élettartamú, egy kifinomult támadó valós időben felhasználhatja azt. A felhasználóknak ébernek kell lenniük, és soha nem szabad kódot megadniuk, ha nem ők kezdeményezték a bejelentkezést, vagy ha gyanús a weboldal URL-je.

5. Adathalászati ellenállás (korlátozottan)

Bár a TOTP jelentősen javítja a phishing elleni védelmet az SMS OTP-hez képest, nem teljesen immunis rá. Léteznek olyan kifinomult phishing támadások (ún. man-in-the-middle phishing vagy adversary-in-the-middle attacks), amelyek képesek elfogni a TOTP kódot is valós időben. Ezek a támadások egy proxy szerveren keresztül irányítják át a felhasználói forgalmat, és azonnal továbbítják a megszerzett hitelesítési adatokat a valódi szolgáltatóhoz. Az ilyen támadások ellen a FIDO U2F/WebAuthn szabványok nyújtanak jobb védelmet.

6. Nincs beépített számláló (HOTP-vel ellentétben)

A TOTP nem rendelkezik beépített számlálóval, mint a HOTP. Ez azt jelenti, hogy ha egy kód generálódik, de nem használják fel, az egyszerűen érvénytelenné válik az idő múlásával. Míg ez a funkció egyszerűsíti az implementációt (nincs szükség a számláló szinkronizálására), azt is jelenti, hogy a szerver nem tudja nyomon követni, hogy egy generált kód hányszor lett felhasználva (bár a „replay” elleni védelem miatt ez nem is célja).

7. Mentés és migrálás kihívásai

A hitelesítő alkalmazásokban tárolt titkos kulcsok biztonsági mentése és új telefonra való migrálása problémás lehet. Sok alkalmazás nem kínál egyszerű, biztonságos mentési lehetőséget, mivel a kulcsok exportálása biztonsági kockázatot jelenthet. Ezért a felhasználóknak gyakran újra kell regisztrálniuk az összes TOTP-kompatibilis fiókjukat egy új eszközön, ami időigényes lehet. Vannak azonban olyan alkalmazások (pl. Authy), amelyek felhőalapú, titkosított mentést kínálnak.

Ezen hátrányok ellenére a TOTP továbbra is az egyik legbiztonságosabb és legelterjedtebb multifaktoros hitelesítési módszer, különösen a statikus jelszavakhoz és az SMS-alapú OTP-khez képest. A kockázatok minimalizálhatók a megfelelő felhasználói oktatással és a helyreállítási protokollok gondos megtervezésével.

TOTP vs. HOTP vs. SMS OTP vs. Push értesítés

A multifaktoros hitelesítés számos formában létezik, és fontos megérteni a TOTP helyét ebben az ökoszisztémában más népszerű módszerekhez képest. Nézzük meg a legfontosabb különbségeket.

TOTP (Time-based One-Time Password)

• Működés: Időalapú. A kód az aktuális idő és egy megosztott titkos kulcs alapján generálódik.
• Érvényesség: Rövid ideig (30-60 másodperc) érvényes, utána automatikusan új kód generálódik.
• Előnyök:
  • Magas biztonság a phishing és replay-támadások ellen (SMS OTP-nél jobb).
  • Offline működés (nincs szükség internetkapcsolatra a kód generálásához).
  • Nyílt szabvány, széleskörűen támogatott.
  • Költséghatékony (nincs SMS díj).
• Hátrányok:
  • Időszinkronizációra érzékeny.
  • Eszköz elvesztése esetén helyreállítási mechanizmus szükséges.
  • Kifinomult man-in-the-middle phishing támadások ellen nem 100%-osan véd.
• Használat: Banki alkalmazások, felhőszolgáltatások, e-mail fiókok, közösségi média.

HOTP (HMAC-based One-Time Password)

• Működés: Számláló-alapú. A kód egy számláló (counter) értéke és egy megosztott titkos kulcs alapján generálódik. Minden sikeres hitelesítés után a számláló növekszik.
• Érvényesség: Mindaddig érvényes, amíg fel nem használják, vagy amíg a számláló értéke el nem tér a szerveren lévő számláló értékétől.
• Előnyök:
  • Nem érzékeny az időszinkronizációra.
  • Offline működés.
• Hátrányok:
  • Ha a számláló szinkronizálatlan lesz (pl. túl sok kódot generál a felhasználó anélkül, hogy felhasználná), akkor a kódok érvénytelenné válnak.
  • A replay-támadások ellen kevésbé védett, ha a számláló értékét nem kezelik megfelelően.
• Használat: Kevésbé elterjedt, mint a TOTP; jellemzően hardveres tokenekben vagy speciális rendszerekben. A TOTP az HOTP továbbfejlesztése, amely kiküszöböli a számláló szinkronizálásának problémáját.

SMS OTP (Short Message Service One-Time Password)

• Működés: A szerver generál egy egyszer használatos kódot, és SMS-ben elküldi a felhasználó regisztrált telefonszámára.
• Érvényesség: Jellemzően néhány percig érvényes.
• Előnyök:
  • Széleskörűen elterjedt, szinte minden mobiltelefonra eljut.
  • Egyszerű a felhasználó számára (nem kell külön alkalmazás).
• Hátrányok:
  • Alacsonyabb biztonság: Sebezhető a SIM-swap támadásokra, ahol a támadó átveszi a telefonszám felett az irányítást.
  • Phishingre érzékeny: A felhasználó könnyen megadhatja a kódot egy hamis weboldalon.
  • Hálózati függőség: Szükséges a mobilhálózati lefedettség az SMS fogadásához.
  • Költséges: A szolgáltatóknak fizetniük kell minden elküldött SMS-ért.
  • Megbízhatóság: Az SMS-ek késhetnek vagy egyáltalán nem érkeznek meg.
• Használat: Banki tranzakciók, online vásárlás, fiók-helyreállítás. Biztonsági okokból egyre inkább visszaszorul.

Push értesítés (Push Notification Authentication)

• Működés: A szerver küld egy értesítést a felhasználó okostelefonján lévő dedikált alkalmazásnak. A felhasználó az alkalmazáson belül egyetlen koppintással (elfogad/elutasít gomb) hagyja jóvá a bejelentkezési kísérletet.
• Érvényesség: A bejelentkezési kísérlet idejére korlátozódik.
• Előnyök:
  • Rendkívül kényelmes: Egyetlen koppintás.
  • Phishing-ellenállóbb: A felhasználó látja, hogy pontosan milyen szolgáltatásba próbál bejelentkezni, és gyakran a helyszínt is. Kevésbé valószínű, hogy véletlenül jóváhagy egy hamis bejelentkezést.
  • Nincs szükség kód beírására.
• Hátrányok:
  • Szükséges az internetkapcsolat a push értesítés fogadásához.
  • Szükséges egy dedikált alkalmazás a szolgáltatótól.
  • „Megerősítési fáradtság” (push fatigue): Ha a felhasználó túl sok értesítést kap, hajlamos lehet gondolkodás nélkül jóváhagyni azokat.
  • Nem minden szolgáltató támogatja.
• Használat: Google, Microsoft, banki alkalmazások, VPN bejelentkezések.

Összefoglaló összehasonlítás:

A TOTP kiváló kompromisszumot kínál a biztonság és a kényelem között, különösen azokhoz a rendszerekhez, ahol a felhasználók gyakran offline állapotban is hozzáférhetnek az OTP generáláshoz. Bár a push értesítések kényelmesebbek lehetnek, a TOTP robusztus alternatívát nyújt, és széles körben elfogadott szabványként működik.

Implementációs szempontok fejlesztők és szervezetek számára

A TOTP bevezetése egy rendszerbe nem csupán az algoritmus megértéséből áll, hanem számos gyakorlati megfontolást is magában foglal a fejlesztők és a szervezetek számára. Ezek a szempontok a biztonságot, a skálázhatóságot és a felhasználói élményt egyaránt érintik.

1. Titkos kulcsok biztonságos tárolása

Ez az egyik legkritikusabb szempont. A szerver oldalon a felhasználókhoz rendelt titkos kulcsokat rendkívül biztonságosan kell tárolni. Ez magában foglalja:

• Titkosítás: A kulcsokat titkosítva kell tárolni az adatbázisban, ideális esetben egy erős, dedikált kulcskezelő rendszer (HSM – Hardware Security Module vagy KMS – Key Management System) segítségével.
• Hozzáférési kontroll: Csak a legszükségesebb rendszerek és felhasználók férhetnek hozzá a kulcsokhoz, szigorú hozzáférés-vezérlési szabályokkal.
• Kulcs rotáció: Bár a TOTP kulcsok alapvetően hosszú élettartamúak, bizonyos esetekben (pl. gyanús tevékenység észlelésekor) lehetőség kell, hogy legyen a kulcsok rotálására vagy újraregisztrálására.
• Soha ne naplózza a kulcsot! A kulcsot soha nem szabad nyílt szövegként naplózni semmilyen rendszerben.

2. Időszinkronizáció kezelése

Mint korábban említettük, az időszinkronizáció kulcsfontosságú. A szervernek:

• Pontos időforrás: Használnia kell egy megbízható időforrást (pl. NTP – Network Time Protocol szerverek) a saját órájának szinkronizálásához.
• Időablak (Time Window): Implementálnia kell egy időablakot a kód érvényességének ellenőrzésekor. Az RFC 6238 ajánlása szerint legalább 1-2 időlépésnyi eltérést (30-60 másodperc) érdemes tolerálni előre és hátra. Ez javítja a felhasználói élményt a kisebb időeltérések esetén.
• Drift észlelése és kezelése: Ha a felhasználó gyakran ad meg érvénytelen kódot az időeltérés miatt, érdemes lehet figyelmeztetni, vagy lehetőséget adni az órájának szinkronizálására a telefonján.

3. Algoritmus és paraméterek kiválasztása

• Hash algoritmus: Bár az SHA-1 még elterjedt, a HMAC-SHA256 vagy HMAC-SHA512 használata javasolt az erősebb kriptográfiai biztonság érdekében.
• Kód hossza: A 6 számjegyű kód a legelterjedtebb, de a 8 számjegyű kód nagyobb biztonságot nyújt (bár kissé csökkenti a kényelmet). A választást a kockázati profilhoz kell igazítani.
• Időlépés: A 30 másodperc a de facto szabvány. Ennél rövidebb időlépés növelheti a biztonságot (rövidebb érvényességi ablak), de egyúttal növelheti az időszinkronizációs problémák valószínűségét és a felhasználói frusztrációt.

4. Felhasználói élmény és onboarding

• Egyszerű beállítás: A QR-kód használata a leginkább felhasználóbarát módja a titkos kulcs átadásának. Fontos, hogy a QR-kód mellett a manuális kulcsbevitelre is legyen lehetőség (Base32 kódolásban), ha a felhasználó nem tudja beolvasni a kódot.
• Világos utasítások: Adjon egyértelmű, lépésről lépésre szóló utasításokat a felhasználóknak a TOTP beállításához.
• Helyreállítási kódok: A beállítás során generáljon és jelenítsen meg egyszer használatos helyreállítási kódokat, amelyeket a felhasználó biztonságosan tárolhat. Ezek kulcsfontosságúak az eszköz elvesztése vagy a fiók zárolása esetén. Kiemelten fontos, hogy a felhasználókat figyelmeztessük ezeknek a kódoknak a biztonságos, offline tárolására.
• Több TOTP kulcs kezelése: Lehetővé kell tenni a felhasználók számára, hogy több TOTP kulcsot is regisztráljanak egy fiókhoz (pl. egy telefonos alkalmazást és egy hardveres tokent).

5. API és szerveroldali implementáció

• Standard könyvtárak használata: Ne próbálja meg újra feltalálni a kereket. Használjon jól tesztelt, nyílt forráskódú vagy kereskedelmi könyvtárakat a TOTP generálásához és validálásához (pl. Google Authenticator könyvtárak különböző nyelveken).
• Rate Limiting: Implementáljon sebességkorlátozást a TOTP kód ellenőrzési végpontján, hogy megakadályozza a brute-force támadásokat. Néhány sikertelen próbálkozás után zárolja a fiókot, vagy vezessen be egyre hosszabb késleltetéseket.
• Naplózás: Naplózza a sikeres és sikertelen TOTP hitelesítési kísérleteket a biztonsági auditálhatóság és a gyanús tevékenységek észlelése érdekében.
• Tesztelés: Alaposan tesztelje az implementációt különböző időeltérésekkel, érvénytelen kódokkal, és stressztesztekkel.

6. Biztonsági mentés és helyreállítás

Amellett, hogy a felhasználóknak helyreállítási kódokat biztosítunk, a szolgáltatóknak is rendelkezniük kell egy biztonságos és ellenőrzött folyamattal a felhasználói fiókok visszaállítására, ha a felhasználó elveszíti az összes hozzáférési módját. Ez magában foglalhatja az identitás ellenőrzését (pl. személyi igazolvány felmutatása, biztonsági kérdések) a fiókhoz való hozzáférés visszaállítása előtt. A folyamatnak egyensúlyt kell teremtenie a biztonság és a felhasználói kényelem között.

7. Folyamatos auditálás és monitorozás

Rendszeresen auditálja a TOTP implementációt, és monitorozza a bejelentkezési naplókat a gyanús minták (pl. sok sikertelen TOTP kísérlet egy fióknál) észleléséhez. A biztonsági rések felderítése és javítása folyamatos feladat.

A TOTP bevezetése egy átgondolt folyamat, amely a technikai megvalósításon túl a felhasználói élményre és a vészhelyzeti protokollokra is kiterjed. Megfelelő tervezéssel és implementációval a TOTP jelentősen növelheti bármely online szolgáltatás biztonságát.

A TOTP jövője és alternatívái: Passkey-ek és FIDO2

Bár a TOTP továbbra is az egyik legszélesebb körben használt és megbízható MFA módszer, a kiberbiztonság világa folyamatosan fejlődik. Új technológiák és szabványok jelennek meg, amelyek célja a hitelesítés még biztonságosabbá és felhasználóbarátabbá tétele. Ezek közül kiemelkednek a Passkey-ek és a mögöttük álló FIDO2 szabvány.

A TOTP relevanciája a jövőben

Fontos leszögezni, hogy a TOTP nem fog azonnal eltűnni. Számos előnye (offline működés, nyílt szabvány, alacsony költség) miatt továbbra is releváns marad, különösen olyan környezetekben, ahol a FIDO2 bevezetése még gyerekcipőben jár, vagy ahol a felhasználói bázis nem rendelkezik a szükséges hardverrel (pl. biometrikus szenzorok, biztonsági kulcsok). A TOTP egy megbízható és bevált „második vonalbeli” védelmi mechanizmus marad a jelszavak mellett.

FIDO2 és Passkey-ek: A jelszómentes jövő

A FIDO (Fast IDentity Online) Alliance egy iparági konzorcium, amelynek célja a jelszómentes hitelesítés szabványosítása. A FIDO2 a legújabb specifikáció, amely a WebAuthn (Web Authentication) és a CTAP2 (Client to Authenticator Protocol 2) protokollokból áll. A FIDO2 lehetővé teszi a felhasználók számára, hogy biometrikus adatok (ujjlenyomat, arcfelismerés) vagy fizikai biztonsági kulcsok (pl. YubiKey) segítségével jelentkezzenek be, anélkül, hogy jelszót kellene használniuk.

A Passkey-ek (vagy „jelszókulcsok”) a FIDO2 implementációjának egy felhasználóbarát formája. Lényegében kriptográfiailag generált kulcspárok, amelyek a felhasználó eszközén (telefon, laptop) biztonságosan tárolódnak. Amikor a felhasználó bejelentkezik egy szolgáltatásba, az eszköz igazolja a felhasználó identitását (pl. ujjlenyomattal), majd a privát kulcs segítségével kriptográfiailag aláírja a bejelentkezési kérést. A nyilvános kulcsot a szolgáltató tárolja, és ezzel ellenőrzi az aláírást.

A Passkey-ek fő előnyei a TOTP-vel szemben:

1. Kiváló phishing-ellenállás: A Passkey-ek szinte teljesen immunisak a phishing támadásokra. Mivel a hitelesítés a privát kulcs kriptográfiai aláírásán alapul, és az csak a felhasználó eszközén található, egy hamis weboldal nem tudja „ellopni” azt, mint egy jelszót vagy egy TOTP kódot. A hitelesítési folyamat a böngésző és a szolgáltató között kriptográfiailag összekapcsolódik, így a felhasználó nem tudja véletlenül jóváhagyni egy hamis oldalon a bejelentkezést.
2. Felhasználói kényelem: Nincs szükség jelszó megjegyzésére vagy TOTP kód beírására. A bejelentkezés gyakran egyetlen érintéssel vagy biometrikus azonosítással történik.
3. Eszközök közötti szinkronizáció: A Passkey-ek szinkronizálhatók az eszközök között (pl. Apple iCloud Keychain, Google Password Manager), így a felhasználó egy új eszközön is könnyen hozzáférhet fiókjaihoz anélkül, hogy minden egyes szolgáltatáshoz újra be kellene állítania a hitelesítést. Ez megoldja a TOTP migrálási problémáját.
4. Replay-támadások elleni védelem: A FIDO2 protokoll beépített védelemmel rendelkezik a replay-támadások ellen.

Hol illeszkedik a TOTP?

Bár a Passkey-ek ígéretes jövőt vetítenek előre, a TOTP továbbra is fontos szerepet játszik:

• Visszafelé kompatibilitás: Sok régebbi rendszer és szolgáltatás még nem támogatja a FIDO2-t, de a TOTP-t igen.
• Offline hozzáférés: Ahogy korábban említettük, a TOTP offline is generálható. A Passkey-ek alapvetően online hitelesítést igényelnek (bár vannak offline forgatókönyvek is, amelyek bonyolultabbak).
• Tartalék megoldás: Még a FIDO2-t használó rendszerek is kínálhatnak TOTP-t vagy helyreállítási kódokat vészhelyzeti hozzáféréshez, ha a fő hitelesítési módszer valamilyen okból nem érhető el.
• Egyszerűség: Kisvállalkozások vagy egyéni fejlesztők számára a TOTP implementációja gyakran egyszerűbb és gyorsabb lehet, mint egy teljes FIDO2 infrastruktúra bevezetése.

A jövő valószínűleg egy hibrid megközelítés felé mutat, ahol a Passkey-ek lesznek az elsődleges, jelszómentes hitelesítési módszer, míg a TOTP, az SMS OTP (csökkentett szerepben) és a helyreállítási kódok kiegészítő, vagy tartalék opcióként szolgálnak. A TOTP továbbra is egy erős és megbízható láncszem marad a kiberbiztonsági védelemben, különösen ott, ahol a legfejlettebb technológiák még nem érhetők el vagy nem megvalósíthatók.