TrendVidStream એ તેનું સંપૂર્ણ ઓથેન્ટિકેશન સ્ટેક (authentication stack) રોટેટિંગ-રિફ્રેશ-ટોકન (rotating-refresh-token) સિસ્ટમ પર સ્થાનાંતરિત કર્યું છે, જે ચોરાયેલ ટોકનનો ફરીથી ઉપયોગ થતાની સાથે જ તેને પકડી પાડે છે. આ ફેરફારથી 30-દિવસના JWT ને, જે એક સમયે હુમલાખોરને મુક્તપણે ફરવાની મંજૂરી આપતું હતું, તેને ટૂંકા ગાળાના ક્રેડેન્શિયલમાં બદલી નાખવામાં આવ્યું છે જે તરત જ લોક-આઉટ (lock-out) ટ્રિગર કરે છે.
એક સિંગલ બ્રીચ (breach) ને કારણે આ ફેરફાર કરવો પડ્યો: એક પાર્ટનર SDK એ 30-દિવસના JWT ને પ્લેન ટેક્સ્ટમાં કેશ (cache) કરી રાખ્યું હતું, એક હુમલાખોરે તેને એક્સટ્રેક્ટ કર્યું અને બીજા દેશમાંથી તેનો ફરીથી ઉપયોગ (replay) કર્યો, અને તેનો એકમાત્ર ઉપાય સાઇનિંગ કી (signing key) ને રોટેટ કરવાનો હતો—જે એક એવી પ્રક્રિયા હતી જેના કારણે દરેક યુઝર લોગ-આઉટ થઈ ગયા હતા. આ ઘટનાએ કંપનીની ટોકન સુરક્ષાને નવો આકાર આપ્યો છે અને હવે તે વિડિયો-સ્ટ્રીમિંગ સર્વિસને સજ્જ કરે છે.
જૂનું મોડેલ કેમ નિષ્ફળ ગયું
JWTs (JSON Web Tokens) એ સેલ્ફ-કન્ટેઈન્ડ (self-contained), સાઈન્ડ બ્લોબ્સ (signed blobs) છે જે સર્વરને ડેટાબેઝ લુકઅપ વગર રિક્વેસ્ટ વેરિફાય કરવાની મંજૂરી આપે છે. આ સુવિધાની એક કિંમત છે: જો ટોકન અઠવાડિયા સુધી ચાલતું હોય, તો તેને ચોરી કરવાથી હુમલાખોરને અઠવાડિયા સુધીનો એક્સેસ મળી જાય છે. બ્રીચ દરમિયાન, ચોરાયેલ ટોકન તેના 30-દિવસના એક્સપાયરી સમય સુધી માન્ય રહ્યું કારણ કે તેને વહેલું ઇનવેલિડેટ (invalidate) કરવાનો કોઈ રસ્તો નહોતો.
સાઇનિંગ કીને રોટેટ કરવી એ તમામ ટોકન્સને ઇનવેલિડેટ કરવાની એકમાત્ર વૈશ્વિક રીત છે, પરંતુ તે દરેક યુઝરને ફરીથી લોગ-ઇન કરવા માટે મજબૂર કરે છે, જેનાથી સર્વિસમાં વિક્ષેપ પડે છે અને વિશ્વાસ ઘટે છે. ખામી JWT માં નહીં, પરંતુ સિંગલ, લાંબા સમય સુધી ચાલતા ક્રેડેન્શિયલ પર નિર્ભર રહેવામાં હતી.
નવા ડિઝાઇનની ટૂંકમાં સમજૂતી
TrendVidStream હવે બે પ્રકારના ટોકન્સ ઇશ્યૂ કરે છે:
- Access tokens – 15 મિનિટ માટે માન્ય; તેઓ દરેક API કોલ માટે જરૂરી પરમિશન ધરાવે છે.
- Refresh tokens – સિંગલ-યુઝ ટોકન્સ જે ટૂંકા ગાળાના એક્સેસ ટોકનને નવા જોડી (pair) સાથે બદલે છે.
જ્યારે ક્લાયન્ટ રિફ્રેશ ટોકન રજૂ કરે છે, ત્યારે સર્વર:
- ટોકનના સિગ્નેચર અને ક્લેમ્સ (claims) વેરિફાય કરે છે.
- તપાસે છે કે ટોકનનો ઉપયોગ અગાઉ થઈ ગયો છે કે નહીં.
- જો તપાસ સફળ થાય, તો એક બ્રાન્ડ-ન્યૂ રિફ્રેશ ટોકન અને નવો 15-મિનિટનો એક્સેસ ટોકન ઇશ્યૂ કરે છે.
- જૂના રિફ્રેશ ટોકનને 'વપરાયેલ' (used) તરીકે માર્ક કરે છે.
જો સ્ટેપ 2 નિષ્ફળ જાય—એટલે કે એ જ ટોકન બીજી વખત દેખાય—તો સર્વર તેને ચોરીના સંકેત તરીકે ગણે છે અને તે લોગિન સેશન સાથે જોડાયેલા તમામ ટોકન્સના આખા "ફેમિલી" (family) ને રિવોક (revoke) કરી દે છે. પીડિત અને હુમલાખોર બંનેને ફરીથી લોગ-ઇન કરવા માટે મજબૂર કરવામાં આવે છે, જેનાથી બ્રીચનો સમયગાળો ટૂંકો થઈ જાય છે.
ટોકન ફેમિલીઝને ટ્રેક કરવી
દરેક ટોકનને અલગ રેકોર્ડ તરીકે ગણવાને બદલે, સિસ્ટમ તેને ફેમિલીઝમાં ગ્રુપ કરે છે જે યુઝર લોગ-ઇન કરે ત્યારે શરૂ થાય છે. દરેક રોટેશન તે ફેમિલીના નવા સભ્ય બનાવે છે. પ્રોડક્શનમાં વપરાતું SQLite સ્કીમા આ માહિતી સ્ટોર કરે છે:
- family_id – આખા સેશન માટે એક સ્ટેબલ આઇડેન્ટિફાયર.
- token_id – દરેક રિફ્રેશ ટોકન માટે એક યુનિક આઇડેન્ટિફાયર.
- generation – ડિબગિંગ માટે ઉપયોગી કાઉન્ટર.
- used_at – ટોકન ક્યારે રિડીમ (redeem) કરવામાં આવ્યું તેનો ટાઇમસ્ટેમ્પ.
- revoked – એક ફ્લેગ જે સેટ કરવામાં આવે ત્યારે આખી ફેમિલીને ડિસેબલ કરી દે છે.
જ્યારે ફરીથી ઉપયોગ (reuse) થવાની ઘટના પકડાય છે, ત્યારે તે family_id માટે revoked ફ્લેગ સેટ કરવામાં આવે છે, જે તરત જ કમ્પ્રમાઇઝ્ડ (compromised) સેશનના દરેક ટોકનને ઇનવેલિડેટ કરી દે છે. આ રીતે એક શાંત હાઇજેક (hijack) ને હાઇ-સિગ્નલ એલર્ટમાં બદલી નાખવામાં આવે છે જે લોગ્સમાં દેખાય છે.
સિસ્ટમને વિશ્વસનીય રાખતા અમલીકરણના ત્રણ નિયમો
સૌ પ્રથમ સિગ્નેચર વેરિફાય કરો જો સર્વર સિગ્નેચર વેરિફાય કરતા પહેલા “used-before?” તપાસે, તો હુમલાખોર ટોકન ID નો અંદાજ લગાવી શકે છે અને સામૂહિક રિવોકેશન (mass revocations) ટ્રિગર કરી શકે છે. સૌ પ્રથમ પ્રમાણિકતા (authenticity) ની ખાતરી કરવાથી બિનજરૂરી ડિનાયલ-ઓફ-સર્વિસ (denial-of-service) હુમલા અટકાવી શકાય છે.
ગ્રેસ વિન્ડો (grace window) ની મંજૂરી આપો જ્યારે ટોકન એક્સપાયર થાય છે ત્યારે મોબાઈલ એપ્સ ઘણીવાર ઝડપથી બે રિફ્રેશ રિક્વેસ્ટ મોકલે છે. જો સર્વર ખૂબ જ કડક હોય, તો બીજી રિક્વેસ્ટને 'રીયુઝ' તરીકે ફ્લેગ કરવામાં આવશે, જેનાથી કાયદેસરનો યુઝર લોગ-આઉટ થઈ જશે. થોડી સેકન્ડોનો બફર (buffer) "વપરાયેલ" ટોકનને પણ નવો જોડી (pair) આપવા દે છે, જેનાથી રેસ કન્ડિશન (race conditions) સરળ બને છે.
આખા ફ્લોને રો લોકિંગ (row locking) સાથે ટ્રાન્ઝેક્શનમાં લપેટો એટોમિસિટી (atomicity) વગર, બે એકસાથે આવતી રિક્વેસ્ટ બંને એમ વિચારી શકે છે કે તેઓ ટોકનનો ઉપયોગ કરનાર પ્રથમ છે, જેનાથી ડુપ્લીકેટ રિફ્રેશ ટોકન્સ ઇશ્યૂ થઈ શકે છે અને સિંગલ-યુઝ ગેરંટી તૂટી શકે છે. ડેટાબેઝ ટ્રાન્ઝેક્શન જે ટોકન રો (row) ને લોક કરે છે તે ખાતરી આપે છે કે માત્ર એક જ રિક્વેસ્ટ સફળ થાય.
સારાંશ: રિફ્રેશ ટોકન્સને સિંગલ-યુઝ બનાવીને અને ફરીથી ઉપયોગ પર નજર રાખીને, સિસ્ટમ દરેક ચોરાયેલ ક્રેડેન્શિયલને એલાર્મમાં બદલી શકે છે, જેનાથી પ્લેટફોર્મ-વાઈડ લોગ-આઉટ કર્યા વગર યુઝર્સનું રક્ષણ કરી શકાય છે.