TrendVidStream தனது முழுமையான authentication stack-ஐ, ஒரு திருடப்பட்ட டோக்கன் மீண்டும் பயன்படுத்தப்படும் தருணத்திலேயே அதைக் கண்டறியும் rotating-refresh-token முறைக்கு மாற்றியது. இந்த மாற்றம், ஒருமுறை தாக்குதல் நடத்துபவர் சுதந்திரமாகச் செயல்பட அனுமதித்த 30-நாள் JWT-ஐ, உடனடியாக லாக்-அவுட்டைத் தூண்டும் ஒரு குறுகிய கால credential ஆக மாற்றியது.
ஒரு பாதுகாப்பு மீறலே இந்த மாற்றத்திற்குத் தூண்டுகோலாக அமைந்தது: ஒரு கூட்டாளர் SDK, 30-நாள் JWT-ஐ plain text வடிவில் சேமித்து வைத்திருந்தது; ஒரு தாக்குதல் நடத்துபவர் அதைத் திருடி, வேறொரு நாட்டிலிருந்து மீண்டும் பயன்படுத்தினார். இதற்கு ஒரே தீர்வு signing key-ஐ மாற்றுவதுதான்—இந்தச் செயல் அனைத்து பயனர்களையும் லாக்-அவுட் செய்தது. இந்தச் சம்பவம் நிறுவனத்தின் token பாதுகாப்பை மறுசீரமைத்தது மற்றும் இப்போது வீடியோ-ஸ்ட்ரீமிங் சேவைக்குத் தேவையான பாதுகாப்பை வழங்குகிறது.
பழைய மாதிரி ஏன் தோல்வியடைந்தது
JWTs (JSON Web Tokens) என்பவை தரவுத்தளத் தேடல் (database lookup) இல்லாமலேயே ஒரு சர்வர் கோரிக்கையைச் சரிபார்க்க அனுமதிக்கும் சுயமான, கையெழுத்திடப்பட்ட தரவுத் தொகுப்புகள் (signed blobs) ஆகும். இந்த வசதி ஒரு பாதிப்பைக் கொண்டுள்ளது: ஒரு டோக்கன் வாரக்கணக்கில் நீடித்தால், அதைத் திருடுவது ஒரு தாக்குதல் நடத்துபவருக்கு வாரக்கணக்கில் அணுகல் உரிமையை வழங்கும். அந்தப் பாதுகாப்பு மீறலில், திருடப்பட்ட டோக்கனை முன்கூட்டியே செல்லாததாக்க வழியில்லாததால், அதன் 30-நாள் காலாவதி வரை அது செல்லுபடியாகும் நிலையில் இருந்தது.
அனைத்து டோக்கன்களையும் செல்லாததாக்க signing key-ஐ மாற்றுவது மட்டுமே ஒட்டுமொத்த வழி, ஆனால் இது ஒவ்வொரு பயனரையும் மீண்டும் லாக்-இன் செய்ய நிர்ப்பந்திக்கிறது, இது சேவையைத் தடுப்பதோடு நம்பிக்கையையும் சிதைக்கிறது. இதில் உள்ள குறைபாடு JWT-இல் இல்லை, மாறாக ஒரு ஒற்றை, நீண்ட காலம் நீடிக்கக்கூடிய credential-ஐச் சார்ந்திருப்பதே ஆகும்.
புதிய வடிவமைப்பு சுருக்கமாக
TrendVidStream இப்போது இரண்டு வகையான டோக்கன்களை வழங்குகிறது:
- Access tokens – 15 நிமிடங்கள் செல்லுபடியாகும்; இவை ஒவ்வொரு API call-க்கும் தேவையான அனுமதிகளைக் கொண்டுள்ளன.
- Refresh tokens – ஒருமுறை மட்டுமே பயன்படுத்தக்கூடிய டோக்கன்கள்; இவை குறுகிய கால access token-க்கு பதிலாக ஒரு புதிய ஜோடியை (pair) மாற்றிக் கொடுக்கின்றன.
ஒரு கிளையண்ட் refresh token-ஐ வழங்கும்போது, சர்வர்:
- டோக்கனின் signature மற்றும் claims-ஐச் சரிபார்க்கிறது.
- டோக்கன் ஏற்கனவே பயன்படுத்தப்பட்டுள்ளதா என்று சோதிக்கிறது.
- சரிபார்ப்பு வெற்றியடைந்தால், ஒரு புதிய refresh token மற்றும் புதிய 15-நிமிட access token-ஐ வழங்குகிறது.
- பழைய refresh token-ஐப் பயன்படுத்தப்பட்டது (used) எனக் குறிக்கிறது.
படி 2 தோல்வியடைந்தால்—அதாவது அதே டோக்கன் இரண்டாவது முறையாகத் தோன்றினால்—சர்வர் அதைத் திருட்டுக்கான அறிகுறியாகக் கருதி, அந்த லாக்-இன் அமர்வுடன் (login session) தொடர்புடைய டோக்கன்களின் முழு "குடும்பத்தையும்" (family) ரத்து செய்கிறது. பாதிக்கப்பட்டவர் மற்றும் தாக்குதல் நடத்துபவர் ஆகிய இருவருமே மீண்டும் லாக்-இன் செய்ய வேண்டிய கட்டாயத்திற்குத் தள்ளப்படுகிறார்கள், இதன் மூலம் பாதுகாப்பு மீறல் விரைவாகத் தடுக்கப்படுகிறது.
டோக்கன் குடும்பங்களைக் கண்காணித்தல்
ஒவ்வொரு டோக்கனையும் ஒரு தனித்தனிப் பதிவாகக் கருதுவதற்குப் பதிலாக, ஒரு பயனர் லாக்-இன் செய்யும்போது தொடங்கும் குடும்பங்களாக இந்த அமைப்பு அவற்றை வகைப்படுத்துகிறது. ஒவ்வொரு சுழற்சியும் (rotation) அந்த குடும்பத்தின் ஒரு புதிய உறுப்பினரை உருவாக்குகிறது. தயாரிப்பு நிலையில் (production) பயன்படுத்தப்படும் SQLite schema பின்வருவனவற்றைச் சேமிக்கிறது:
- family_id – முழு அமர்வுக்கும் (session) நிலையான அடையாளங்காட்டி.
- token_id – ஒவ்வொரு refresh token-க்கும் தனித்துவமான அடையாளங்காட்டி.
- generation – பிழைத்திருத்தத்திற்கு (debugging) பயனுள்ள ஒரு கவுண்டர்.
- used_at – டோக்கன் எப்போது பயன்படுத்தப்பட்டது என்பதற்கான நேர முத்திரை (timestamp).
- revoked – இது அமைக்கப்பட்டால், முழு குடும்பத்தையும் முடக்கும் ஒரு கொடி (flag).
ஒரு டோக்கன் மீண்டும் பயன்படுத்தப்படும் நிகழ்வு கண்டறியப்படும்போது, அந்த family_id-க்கான revoked flag அமைக்கப்படுகிறது, இது பாதிக்கப்பட்ட அமர்விற்குச் சொந்தமான ஒவ்வொரு டோக்கனையும் உடனடியாகச் செல்லாததாக்குகிறது. இது ஒரு அமைதியான கடத்தலை (silent hijack), லாக்-களில் (logs) தோன்றும் ஒரு தெளிவான எச்சரிக்கையாக (high-signal alert) மாற்றுகிறது.
அமைப்பை நம்பகமானதாக வைத்திருக்கும் மூன்று செயலாக்க விதிகள்
முதலில் signature-ஐச் சரிபார்க்கவும் சர்வர் signature-ஐச் சரிபார்க்கும் முன்பே “ஏற்கனவே பயன்படுத்தப்பட்டதா?” என்று சோதித்தால், ஒரு தாக்குதல் நடத்துபவர் டோக்கன் ID-களைக் கணித்து மொத்தமாக ரத்து செய்யும் (mass revocations) செயலைத் தூண்டக்கூடும். முதலில் நம்பகத்தன்மையை உறுதிப்படுத்துவது தேவையற்ற denial-of-service தாக்குதல்களைத் தடுக்கிறது.
ஒரு சிறிய கால இடைவெளியை (grace window) அனுமதிக்கவும் ஒரு டோக்கன் காலாவதியாகும் போது, மொபைல் செயலிகள் பெரும்பாலும் மிக விரைவாக இரண்டு refresh கோரிக்கைகளை அனுப்பும். சர்வர் மிகவும் கண்டிப்பாக இருந்தால், இரண்டாவது கோரிக்கை மீண்டும் பயன்படுத்தப்பட்டது எனக் கருதப்பட்டு, ஒரு உண்மையான பயனர் லாக்-அவுட் செய்யப்படுவார். சில வினாடிகள் கால இடைவெளி (buffer) விடுவது, “பயன்படுத்தப்பட்ட” டோக்கன் மூலம் ஒரு புதிய ஜோடியைப் பெற அனுமதிக்கும், இது race conditions சிக்கல்களைத் தவிர்க்க உதவும்.
முழுச் செயல்பாட்டையும் row locking கொண்ட ஒரு transaction-க்குள் கொண்டு வரவும் Atomicity இல்லையென்றால், ஒரே நேரத்தில் வரும் இரண்டு கோரிக்கைகளும் தாங்களே டோக்கனைப் பயன்படுத்துவதற்கான முதல் கோரிக்கை என்று நினைக்கக்கூடும், இதனால் நகல் refresh tokens வழங்கப்பட்டு, ஒருமுறை மட்டுமே பயன்படுத்தும் உத்தரவாதம் உடைந்துவிடும். டோக்கன் வரிசையை (token row) லாக் செய்யும் ஒரு database transaction, ஒரே ஒரு கோரிக்கை மட்டுமே வெற்றி பெறுவதை உறுதி செய்கிறது.
Takeaway: refresh tokens-களை ஒருமுறை மட்டுமே பயன்படுத்தக்கூடியதாக மாற்றுவதன் மூலமும், அவற்றை மீண்டும் பயன்படுத்துவதைக் கண்காணிப்பதன் மூலமும், ஒரு அமைப்பு திருடப்பட்ட ஒவ்வொரு சான்றளிப்பையும் (credential) ஒரு எச்சரிக்கையாக மாற்ற முடியும், இதன் மூலம் தளத்தின் ஒட்டுமொத்த லாக்-அவுட்டையும் தவிர்க்காமல் பயனர்களைப் பாதுகாக்க முடியும்.