TrendVidStream ilihamisha mfumo wake wote wa uthibitishaji (authentication stack) kwenda kwenye mfumo wa tokeni zinazozunguka (rotating-refresh-token system) ambao unatambua tokeni iliyoibiwa mara tu inapotumiwa tena. Mabadiliko hayo yaligeuza JWT ya siku 30 ambayo hapo awali ilimruhusu mshambuliaji kutembea bila kikomo kuwa utambulisho wa muda mfupi unaozuia ufikiaji mara moja.

Uvunjaji mmoja wa usalama ulilazimisha mabadiliko haya: SDK ya mshirika ilihifadhi JWT ya siku 30 katika maandishi ya kawaida (plain text), mshambuliaji aliichukua na kuitumia tena kutoka nchi nyingine, na suluhisho pekee lilikuwa kuzungusha funguo ya kusaini (signing key)—operesheni iliyomfanya kila mtumiaji atoke kwenye mfumo (log out). Tukio hilo lilibadilisha usalama wa tokeni wa kampuni na sasa ndilo linaloendesha huduma ya utiririshaji video (video-streaming service).

Kwa nini mfumo wa zamani ulishindwa

JWTs (JSON Web Tokens) ni vitambulisho vilivyojitegemea na vilivyosainiwa ambavyo huruhusu seva kuthibitisha ombi bila kuhitaji kutafuta kwenye kanzi data (database). Urahisi huo una gharama yake: ikiwa tokeni inadumu kwa wiki kadhaa, kuiiba humpa mshambuliaji ufikiaji wa wiki kadhaa. Katika uvunjaji huo, tokeni iliyoibiwa ilibaki kuwa halali hadi muda wake wa siku 30 ulipoisha kwa sababu hakukuwa na njia ya kuifuta mapema.

Kuzungusha funguo ya kusaini (signing key) ndiyo njia pekee ya kimataifa ya kufuta tokeni zote, lakini inamlazimisha kila mtumiaji kuingia tena (log in), jambo linalovuruga huduma na kupunguza imani. Kasoro haikuwa kwenye JWT yenyewe bali katika kutegemea utambulisho mmoja tu unaodumu kwa muda mrefu.

Muhtasari wa usanifu mpya

TrendVidStream sasa hutoa aina mbili za tokeni:

  • Access tokens – zinazodumu kwa dakika 15; hubeba ruhusa zinazohitajika kwa kila wito wa API (API call).
  • Refresh tokens – tokeni za matumizi ya mara moja ambazo hubadilisha access token ya muda mfupi kuwa jozi mpya.

Mteja anapowasilisha refresh token, seva:

  1. Inathibitisha saini na madai (claims) ya tokeni.
  2. Inakagua ikiwa tokeni hiyo tayari imetumika.
  3. Ikiwa ukaguzi utafanikiwa, hutoa refresh token mpya kabisa na access token mpya ya dakika 15.
  4. Inaainisha refresh token ya zamani kama iliyotumiwa.

Ikiwa hatua ya 2 itafeli—ikimaanisha tokeni ile ile inatokea mara ya pili—seva inachukulia kama ishara ya wizi na kufuta "familia" nzima ya tokeni zilizounganishwa na kikao hicho cha kuingia (login session). Mwathiriwa na mshambuliaji wote wanalazimika kuingia tena, hivyo kukata ufikiaji wa uvunjaji huo mapema.

Kufuatilia familia za tokeni

Badala ya kuchukulia kila tokeni kama rekodi iliyotengwa, mfumo huziunganisha katika familia ambazo huanza mtumiaji anapoingia (log in). Kila mzunguko unaunda mwanachama mpya wa familia hiyo. Muundo wa SQLite (SQLite schema) unaotumika kwenye uzalishaji (production) huhifadhi:

  • family_id – utambulisho thabiti kwa ajili ya kikao chote.
  • token_id – utambulisho wa kipekee kwa kila refresh token.
  • generation – kiongezi (counter) kinachofaa kwa ajili ya kurekebisha makosa (debugging).
  • used_at – muda (timestamp) ambao tokeni ilitumiwa.
  • revoked – alama (flag) ambayo, ikipakwa, inazima familia nzima.

Tukio la utumiaji wa mara ya pili linapotambuliwa, alama ya revoked kwa family_id hiyo huwekwa, na kufanya kila tokeni inayomiliki kikao kilichoathiriwa isifanye kazi mara moja. Hii inageuza utekaji wa kimya kimya kuwa tahadhari yenye ishara kubwa inayotokea kwenye kumbukumbu (logs).

Kanuni tatu za utekelezaji zinazofanya mfumo uwe wa kuaminika

  1. Thibitisha saini kwanza Mshambuliaji anaweza kukisia ID za tokeni na kusababisha ubatilishaji wa pamoja (mass revocations) ikiwa seva itakagua "imetumika-kabla?" kabla ya kuthibitisha saini. Kuthibitisha uhalali kwanza huzuia mashambulizi yasiyo ya lazima ya kukatisha huduma (denial-of-service attacks).

  2. Ruhusu muda wa ziada (grace window) Programu za simu mara nyingi hutuma maombi mawili ya refresh kwa mfuatano wa haraka wakati tokeni inapopita muda wake. Ikiwa seva itakuwa kali sana, ombi la pili litatambulika kama utumiaji wa mara ya pili, na kumtoa mtumiaji halali kwenye mfumo. Sekunde chache za muda wa ziada (buffer) huruhusu tokeni "iliyotumika" bado irudishe jozi mpya, hivyo kurekebisha matatizo ya ushindani wa maombi (race conditions).

  3. Funga mtiririko mzima kwenye muamala (transaction) wenye ufungaji wa safu (row locking) Bila utengano (atomicity), maombi mawili yanayofanyika kwa wakati mmoja yanaweza kufikiri yote ndiyo ya kwanza kutumia tokeni, yakitoa refresh token zinazofanana na kuvunja ahadi ya matumizi ya mara moja. Muamala wa kanzi data (database transaction) unaofunga safu ya tokeni unahakikisha kuwa ombi moja tu linafanikiwa.

Funzo: Kwa kufanya refresh token kuwa za matumizi ya mara moja na kufuatilia utumiaji wa mara ya pili, mfumo unaweza kugeuza kila utambulisho ulioibiwa kuwa kingora, ukiwalinda watumiaji bila kulazimisha watu wote kutoka kwenye mfumo.