KO NAPADALEC NE POTREBUJE VEČ TVOJEGA GESLA

Gesla smo podaljšali, jim dodali posebne znake, upravljalnike gesel in večfaktorsko avtentikacijo. Vse z dobrim razlogom. Če nekdo pridobi uporabniško ime in geslo, mu lahko drugi faktor prepreči prijavo, dodatne varnostne politike pa dostop še dodatno omejijo.

Toda uspešna prijava je samo začetek seje. Ko sistem preveri uporabnika, mu praviloma ni treba pri vsakem naslednjem zahtevku znova vpisovati gesla in potrjevati drugega faktorja. Identitetni sistemi zato uporabljajo različne artefakte, med njimi dostopne in osvežitvene žetone, prijavne sejne žetone, piškotke ter trditve o identiteti in avtorizaciji. Njihove naloge niso enake, imajo pa pomembno skupno lastnost: omogočajo nadaljevanje že vzpostavljenega zaupanja brez popolne ponovitve prvotnega postopka prijave.

In prav to je lahko tarča napada.

Geslo je samo ena od poti do računa

Pri klasičnem prevzemu računa napadalec poskuša pridobiti poverilnice in se z njimi prijaviti. Večfaktorska avtentikacija takšen napad bistveno oteži, še posebej pri uporabi metod, odpornih proti phishingu.

Kraja veljavnega prijavnega sejnega ali dostopnega artefakta odpira drugačen problem. Če okoliščine in uporabljeni protokol dopuščajo njegovo ponovno uporabo, napadalcu ni nujno treba ponoviti prvotne avtentikacije. Sistem lahko prejme dokazilo, ki je bilo pred tem legitimno izdano.

Microsoft zato med mehanizmi za zaščito identitet obravnava tudi krajo in ponovno uporabo prijavnih sejnih žetonov. Token Protection je kontrola Conditional Access, ki pri podprtih scenarijih zahteva uporabo prijavnih sejnih žetonov, kriptografsko vezanih na napravo. Mednje sodi Primary Refresh Token oziroma PRT. Če napadalec takšen žeton ukrade, ga zaradi vezave ne more preprosto prenesti na drugo napravo in tam uporabiti na enak način.

To ne zmanjšuje pomena MFA. Pokaže pa mejo njegove naloge: uspešna večfaktorska avtentikacija sama po sebi ne odpravi vseh tveganj, ki nastanejo po prijavi.

NIST je problem postavil v samostojen dokument

Ameriški National Institute of Standards and Technology je 15. septembra 2026 objavil končno različico poročila NIST IR 8587 Protecting Tokens and Assertions from Forgery, Theft, and Misuse: Implementation Recommendations for Agencies and Cloud Service Providers.

Dokument je namenjen predvsem ameriškim zveznim agencijam in ponudnikom oblačnih storitev, vendar obravnava mehanizme, ki so sestavni del veliko širšega identitetnega okolja. Osredotoča se na zaščito identity tokenov, access tokenov in assertions pred ponarejanjem, krajo in zlorabo ter zajema upravljanje ključev, preverjanje žetonov in nadzor njihovega življenjskega cikla. Obravnava tudi enotno prijavo, federacijo in dostop do API-jev.

Pomemben je tudi kontekst dokumenta. NIST navaja, da priporočila obravnavajo grožnje, ki so se pokazale v odmevnih napadih na identitetne sisteme, ter poudarja varnost po načelu secure by design, interoperabilnost, nastavljivost in neprekinjeno spremljanje.

Problem zato ni omejen na vprašanje, ali je uporabnik izbral dovolj dobro geslo. Del varnostne meje je v infrastrukturi, ki po uspešni avtentikaciji izdaja, podpisuje, preverja in upravlja dokazila, s katerimi sistemi nadaljujejo že vzpostavljeno zaupanje.

Veljaven žeton še ne pove vsega

Pri bearer access tokenih je osnovno tveganje preprosto. Če napadalec pridobi veljaven žeton in ga lahko uporabi v ustreznem kontekstu, samo posedovanje tega žetona lahko zadostuje za dostop do zaščitenega vira, dokler tega ne prepreči drug mehanizem.

Zato varnostna priporočila poskušajo zmanjšati prenosljivost takšnih dokazil. RFC 9700, ki ga je IETF januarja 2025 objavil kot Best Current Practice for OAuth 2.0 Security, priporoča uporabo sender-constrained access tokenov. Pri njih posedovanje žetona ni edini pogoj za njegovo uporabo. Odjemalec mora dokazati tudi poznavanje ustrezne skrivnosti oziroma kriptografskega ključa. Dokument med mehanizmi za takšno zaščito navaja mutual TLS in DPoP.

Podobna previdnost velja za refresh tokene. RFC 9700 pri javnih odjemalcih zahteva uporabo sender-constrained refresh tokenov ali rotacijo refresh tokenov. Pri rotaciji avtorizacijski strežnik ob osvežitvi izda nov refresh token, prejšnjega pa razveljavi. Ponovna uporaba že razveljavljenega tokena lahko tako razkrije, da isti niz poverilnic uporabljata legitimni odjemalec in nekdo drug.

To je precej širši problem od ugibanja ali kraje gesla. Vprašanje ni več samo, kdo se lahko prijavi, temveč tudi, kdo lahko uporabi dokazilo, izdano po uspešni prijavi.

Zaupanje dobi napravo, namen in rok

Microsoftov Token Protection uporablja sorodno načelo pri podprtih prijavnih sejah. Prijavni sejni žeton je kriptografsko vezan na napravo, zato njegova kopija na drugi napravi nima enake uporabnosti.

Toda tudi tu so omejitve pomembne. Token Protection ni univerzalna zaščita vseh žetonov, aplikacij in platform. Microsoft navaja konkretne podprte odjemalce, platforme in vire. Pri izvornih aplikacijah so med podprtimi viri Exchange Online, SharePoint Online in Microsoft Teams, na sistemih Windows pa tudi Azure Virtual Desktop in Windows 365. Podpora spletnih aplikacij ima dodatne omejitve.

Primer pokaže širše načelo. Digitalno dokazilo je mogoče omejiti na določenega odjemalca, napravo, vir ali namen. Sistem lahko zahteva dodaten kriptografski dokaz, da ga uporablja odjemalec, ki mu je bilo izdano, ali omeji čas in okoliščine njegove uporabe. Kraja podatka zato ni nujno tudi kraja njegove uporabnosti.

Ko težava ni samo v prijavnem oknu

Identitetna varnost je odvisna tudi od tega, kako dobro organizacija vidi dogajanje po prijavi.

CISA je julija 2025 pri obravnavi osrednje oblačne identitetne infrastrukture opozorila na več področij, ki so se pokazala kot pomembna pri naprednih napadih: token authentication, upravljanje ključev, mehanizme beleženja, odvisnosti od tretjih strani in upravljanje varnosti.

Pomanjkljiva telemetrija in prekratka hramba dnevnikov lahko otežita ugotavljanje, kaj se je zgodilo po kompromitaciji. To je posebej pomembno pri incidentih, povezanih s ponarejenimi žetoni, kompromitiranimi podpisnimi ključi ali nepooblaščenim izdajanjem žetonov.

Za uporabnika je ta del skoraj neviden. Lahko ga naučimo prepoznati sumljivo prijavno stran ali nepričakovano zahtevo za MFA, ne moremo pa nanj prenesti odgovornosti za način podpisovanja tokenov, upravljanje ključev, beleženje dogodkov ali preverjanje njihove veljavnosti. To so naloge arhitekture, implementacije in nadzora.

Seja, ki je bila veljavna zjutraj, ni nujno veljavna popoldne

Med aktivno sejo se okoliščine lahko spremenijo. Uporabniški račun je lahko onemogočen, geslo ponastavljeno, administrator lahko prekliče uporabnikove refresh tokene ali pa sistem zazna visoko tveganje uporabnika.

Če bi sistem čakal samo na običajni potek veljavnosti access tokena, bi lahko med spremembo okoliščin in naslednjim preverjanjem obstajalo obdobje, ko bi se dostop nadaljeval po starih pogojih.

Microsoftov Continuous Access Evaluation oziroma CAE pri podprtih storitvah omogoča drugačen pristop. Storitve lahko spremljajo kritične dogodke Microsoft Entra in zaradi njih zavrnejo tudi access token, ki še ni potekel. Microsoft med takšnimi dogodki navaja izbris ali onemogočenje uporabniškega računa, spremembo oziroma ponastavitev gesla, omogočenje MFA, administratorski preklic refresh tokenov in zaznano visoko tveganje uporabnika.

Zanimivo je, da rešitev ni preprosto krajšanje življenjske dobe vseh tokenov. Microsoft navaja, da je pri CAE mogoče uporabljati dalj časa veljavne tokene, saj lahko podprte aplikacije ob pomembnih dogodkih dostop zavrnejo še pred njihovim običajnim iztekom.

Čas veljavnosti tako ni več edini trenutek, ko je mogoče ponovno preveriti, ali prvotno odobren dostop še vedno ustreza trenutnim okoliščinam.

Varnost se po prijavi ne konča

Gesla ostajajo pomembna. Enako velja za večfaktorsko avtentikacijo in še posebej za metode, odporne proti phishingu. Toda zaščita identitete se ne more končati pri vprašanju, ali smo uporabnika ob prijavi pravilno preverili.

Pomembno je tudi, kaj se zgodi z dokazili, ki jih sistemi ustvarijo po tej prijavi. Kako dolgo veljajo, komu in za kateri vir so namenjena, ali jih je mogoče prenesti na drugo napravo, kako hitro jih je mogoče razveljaviti ter ali imamo dovolj podatkov, da bomo njihovo nenavadno uporabo sploh zaznali.

Pred leti je bilo osrednje vprašanje pogosto, kdo pozna geslo. Danes mu moramo dodati še eno. Kdo lahko uporabi dokaz, da je bila prijava že uspešno opravljena?

EVIDENCE PROFILE

Dokazni profil članka

Profil pokaže vrsto dokazne podlage in omejitve osrednjega argumenta.

OSREDNJI DOKAZIdentitetna varnost se ne konča pri MFA; zaščititi je treba tudi žetone, trditve in sejne artefakte, s katerimi sistemi nadaljujejo že vzpostavljeno zaupanje.

RAZISKAVE2

DOKUMENTACIJA3

PREDOBJAVE0

UREDNIŠKI PREIZKUSNE

PREVERJENO2026-09-28

Viri

1. 01PRIMARY RESEARCHNational Institute of Standards and Technology (NIST)
   Galluzzo, R., Regenscheid, A., Nelson, S., Lazcano, C. (2026). Protecting Tokens and Assertions from Forgery, Theft, and Misuse: Implementation Recommendations for Agencies and Cloud Service Providers. NIST IR 8587. National Institute of Standards and Technology, 15. september 2026. DOI: 10.6028/NIST.IR.8587.Odpri vir ↗
2. 02PRIMARY RESEARCHInternet Engineering Task Force (IETF)
   Lodderstedt, T., Bradley, J., Labunets, A., Fett, D. (2025). Best Current Practice for OAuth 2.0 Security. RFC 9700, BCP 240. Internet Engineering Task Force, januar 2025. DOI: 10.17487/RFC9700.Odpri vir ↗
3. 03PRIMARY DOCUMENTATIONRomans, C.
   Romans, C. (2025). Securing Core Cloud Identity Infrastructure: Addressing Advanced Threats through Public-Private Collaboration. Cybersecurity and Infrastructure Security Agency, 15. julij 2025.
4. 04PRIMARY DOCUMENTATIONMicrosoft
   Microsoft.Token Protection in Microsoft Entra Conditional Access. Microsoft Learn.
5. 05PRIMARY DOCUMENTATIONMicrosoft
   Microsoft.Continuous access evaluation in Microsoft Entra. Microsoft Learn.