egy korábbi bejegyzésben a Zix | AppRiver megvitatta, hogy a SolarWinds támadásért felelős személyek hogyan használták fel a tokeneket és tanúsítványokat a fertőzési lánc részeként. A rosszindulatú szereplők az azonos típusú eszközökkel visszaéltek más entitásokat célzó további kampányokban. Ez megerősített tanúsítványbiztonsági eseményt eredményezett egy e-mail biztonsági szolgáltatónál.
elismerve ezeket a rosszindulatú tevékenységeket, a Zix | AppRiver szükségesnek érezte, hogy az ügyfelek számára egy sor cikket nyújtson, amelyek megvitatják az érintett típusú hitelesítési módszereket és azok működését. Kezdjük a token alapú hitelesítéssel.
Token alapú hitelesítés: áttekintés
Token alapú hitelesítés foglalkozik a munkamenet-alapú hitelesítés néhány korlátozásával. Ez utóbbiban a kiszolgáló létrehoz egy munkamenetet a felhasználó számára, amikor bejelentkezik. A munkamenet-azonosítót egy cookie-ban tárolja, amely minden későbbi kérést kísér, ha a felhasználó bejelentkezve marad. A szerver ezután ellenőrzi a felhasználó személyazonosságát, összehasonlítva a cookie-t a memóriában tárolt munkamenet-adatokkal.
a probléma itt az, hogy a munkamenet-alapú hitelesítésnek bizonyos hátrányai vannak. Először is megköveteli, hogy a szerver tárolja a munkameneteket a memóriájában. A probléma az is, hogy a cookie-k különböző médiumok (például web és mobil) több eszközén működnek.
itt jön be a token alapú hitelesítés. A hitelesítés ezen formája egy olyan alkalmazást foglal magában, amely aláírt tokent biztosít az ügyfélnek a felhasználói hitelesítő adatok hitelesítésekor. Az ügyfél tárolja ezt a Tokent, és minden kéréssel elküldi, ekkor a szerver ellenőrzi a Tokent, és információkat küld.
ebben az értelemben a token alapú hitelesítés abban különbözik a munkamenet-alapú hitelesítéstől, hogy hontalan. Nem foglalja magában a felhasználóval kapcsolatos információk tárolását egy kiszolgálón vagy egy munkamenetben. Ez tárolja az adatokat a token a kliens oldalon.
a Token alapú hitelesítés előnyei és kihívásai
a Token alapú hitelesítés számos előnnyel jár. Chop-Chop megjegyzi, hogy a tokenek különböző weboldalakon és médiumokon is működnek, ami lehetőséget teremt a felhasználók nagyobb sokféleségére—különösen a mobil eszközöket használókra. Ráadásul a tokenek a felhasználó hitelesítő adataihoz kapcsolódnak az adatokhoz való hozzáférés folyamatában; valaki, aki veszélyeztette a tokent, nem fér hozzá automatikusan az érintett felhasználó fiókjának hitelesítő adataihoz.
ennek ellenére a token alapú hitelesítés nem mentes a kihívásoktól. A Devbridge Group megjegyzi, hogy például egyes munkamenet-tokeneket nem biztonságos módon generálnak. Ez lehetővé teszi, hogy a támadó egy elég nagy minta munkamenet azonosítók kitalálni egy mintát, és kitalálni a tokenek egy nagyobb medence felhasználók. A támadók nem biztonságos token tárolókat, több bejelentkezést és/vagy hosszú token érvényesítési időt használnak fel a hitelesítési titkok ellopására.
a Token alapú hitelesítés biztonságos használata
a fent tárgyalt kockázatok elismeréseként íme néhány bevált gyakorlat a token alapú hitelesítés biztonságos használatához:
- erős tokenek létrehozása. A Devbridge különösen azt javasolja, hogy a tokenek nagy mennyiségű lehetséges értéket tartalmazzanak, bizonyos fokú pszeudorandomitást tartalmazzanak, és legalább 16 bájt hosszúságúak legyenek.
- adj tokenek lejárati. Fontos, hogy Feltételeket állítson be arra vonatkozóan,hogy egy token mennyi ideig marad érvényben, jegyzi meg az Auth0. Nyilvánvaló, hogy ha egy felhasználó továbbra is aktív, a token automatikusan megújulhat. De van is bölcsesség, amely lehetővé teszi a token Lejár, amikor a felhasználó kijelentkezik, és megszünteti a token nem számít, mi után egy bizonyos ideig eltelt.
- több Bejelentkezés letiltása. Amint azt a Devbridge megjegyezte, lehetséges a kulcsfontosságú attribútumok használata a párhuzamos hitelesítések megakadályozására, ahol egynél több személy lép kapcsolatba ugyanazzal a felhasználói fiókkal egyszerre.
- biztonságosan tárolja a tokeneket. A helyi tárolás itt nem az út. A DEV Community a SameSite nevű cookie-szabályzat használatát javasolja azon feltételek meghatározására, amelyek mellett a cookie-k átadhatók egy domainek közötti kérelemben. A szigorú SameSite házirend, valamint az a követelmény, hogy az embereknek olyan böngészőverzióval kell rendelkezniük, amely támogatja ezt a funkciót, segít megőrizni a munkamenet-tokenek biztonságát.