TrendVidStream తన మొత్తం అథెంటికేషన్ స్టాక్ను 'రోటేటింగ్-రిఫ్రెష్-టోకెన్' (rotating-refresh-token) సిస్టమ్కు మార్చింది, ఇది దొంగిలించబడిన టోకెన్ను అది మళ్ళీ ఉపయోగించబడిన వెంటనే గుర్తిస్తుంది. ఈ మార్పు వల్ల, ఒకప్పుడు దాడి చేసే వ్యక్తికి (attacker) స్వేచ్ఛగా తిరిగే అవకాశం కల్పించిన 30 రోజుల JWT, ఇప్పుడు వెంటనే లాక్-అవుట్ను ట్రిగ్గర్ చేసే స్వల్పకాలిక క్రెడెన్షియల్గా మారింది.
ఒకే ఒక్క భద్రతా ఉల్లంఘన (breach) వల్ల ఈ మార్పు తప్పనిసరి అయ్యింది: ఒక పార్ట్నర్ SDK, 30 రోజుల JWTని ప్లెయిన్ టెక్స్ట్గా క్యాష్ చేసింది, ఒక అటాకర్ దానిని సేకరించి వేరొక దేశం నుండి రీప్లే చేశాడు. అప్పుడు ఉన్న ఏకైక పరిష్కారం సైనింగ్ కీని (signing key) మార్చడం మాత్రమే—ఈ ప్రక్రియ వల్ల ప్రతి యూజర్ లాగ్ అవుట్ అయిపోయారు. ఈ సంఘటన కంపెనీ యొక్క టోకెన్ సెక్యూరిటీని పునర్నిర్మించింది మరియు ఇప్పుడు వీడియో-స్ట్రీమింగ్ సర్వీస్కు శక్తినిస్తుంది.
పాత మోడల్ ఎందుకు విఫలమైంది
JWTలు (JSON Web Tokens) స్వయం సమగ్రమైన (self-contained), సైన్ చేయబడిన బ్లాబ్లు, ఇవి డేటాబేస్ లుకప్ లేకుండానే సర్వర్ ఒక రిక్వెస్ట్ను ధృవీకరించడానికి అనుమతిస్తాయి. ఈ సౌలభ్యం వెనుక ఒక నష్టం ఉంది: ఒక టోకెన్ వారాల తరబడి చెల్లుబాటు అవుతుంటే, దానిని దొంగిలించడం ద్వారా అడ్వర్సరీకి (adversary) వారాల కొద్దీ యాక్సెస్ లభిస్తుంది. ఆ భద్రతా ఉల్లంఘనలో, దొంగిలించబడిన టోకెన్ను ముందుగానే రద్దు చేయడానికి మార్గం లేకపోవడం వల్ల, అది దాని 30 రోజుల గడువు ముగిసే వరకు చెల్లుబాటు అయ్యింది.
అన్ని టోకెన్లను రద్దు చేయడానికి సైనింగ్ కీని మార్చడం (rotating the signing key) అనేది మాత్రమే ఏకైక గ్లోబల్ మార్గం, కానీ ఇది ప్రతి యూజర్ను మళ్ళీ లాగిన్ అవ్వమని బలవంతం చేస్తుంది, దీనివల్ల సర్వీస్ అంతరాయం కలిగి మరియు నమ్మకం తగ్గుతుంది. లోపం JWTలో లేదు, కానీ ఒకే ఒక దీర్ఘకాలిక క్రెడెన్షియల్పై ఆధారపడటంలో ఉంది.
కొత్త డిజైన్ క్లుప్తంగా
TrendVidStream ఇప్పుడు రెండు రకాల టోకెన్లను జారీ చేస్తుంది:
- Access tokens – 15 నిమిషాల పాటు చెల్లుబాటు అవుతాయి; ఇవి ప్రతి API కాల్కు అవసరమైన అనుమతులను (permissions) కలిగి ఉంటాయి.
- Refresh tokens – ఇవి ఒకసారి మాత్రమే ఉపయోగించగల టోకెన్లు, ఇవి స్వల్పకాలిక యాక్సెస్ టోకెన్ను కొత్త జంట (pair) కోసం మార్పిడి చేస్తాయి.
క్లయింట్ రిఫ్రెష్ టోకెన్ను సమర్పించినప్పుడు, సర్వర్:
- టోకెన్ యొక్క సిగ్నేచర్ మరియు క్లెయిమ్స్ను (claims) ధృవీకరిస్తుంది.
- టోకెన్ ఇప్పటికే ఉపయోగించబడిందో లేదో తనిఖీ చేస్తుంది.
- తనిఖీ విజయవంతమైతే, సరికొత్త రిఫ్రెష్ టోకెన్ మరియు కొత్త 15-నిమిషాల యాక్సెస్ టోకెన్ను జారీ చేస్తుంది.
- పాత రిఫ్రెష్ టోకెన్ను 'ఉపయోగించబడింది' (used) అని గుర్తిస్తుంది.
ఒకవేళ స్టెప్ 2 విఫలమైతే—అంటే అదే టోకెన్ రెండోసారి కనిపిస్తే—సర్వర్ దానిని దొంగతనం సంకేతంగా పరిగణించి, ఆ లాగిన్ సెషన్కు అనుసంధానించబడిన టోకెన్ల మొత్తం "ఫ్యామిలీ"ని (family) రద్దు చేస్తుంది. దీనివల్ల బాధితుడు మరియు అటాకర్ ఇద్దరూ మళ్ళీ లాగిన్ అవ్వాల్సి ఉంటుంది, తద్వారా భద్రతా ఉల్లంఘన త్వరగా ఆగిపోతుంది.
టోకెన్ ఫ్యామిలీలను ట్రాక్ చేయడం
ప్రతి టోకెన్ను ఒక విడిగా ఉన్న రికార్డుగా పరిగణించకుండా, యూజర్ లాగిన్ అయినప్పుడు ప్రారంభమయ్యే ఫ్యామిలీలుగా సిస్టమ్ వాటిని సమూహపరుస్తుంది. ప్రతి రోటేషన్ ఆ ఫ్యామిలీలో ఒక కొత్త సభ్యుడిని సృష్టిస్తుంది. ప్రొడక్షన్లో ఉపయోగించే SQLite schema వీటిని నిల్వ చేస్తుంది:
- family_id – మొత్తం సెషన్ కోసం ఒక స్థిరమైన ఐడెంటిఫైయర్.
- token_id – ప్రతి రిఫ్రెష్ టోకెన్ కోసం ఒక ప్రత్యేకమైన ఐడెంటిఫైయర్.
- generation – డీబగ్గింగ్ (debugging) కోసం ఉపయోగపడే కౌంటర్.
- used_at – టోకెన్ ఎప్పుడు ఉపయోగించబడిందో తెలిపే టైమ్స్టాంప్ (timestamp).
- revoked – దీనిని సెట్ చేసినప్పుడు, మొత్తం ఫ్యామిలీని నిలిపివేసే ఫ్లాగ్ (flag).
టోకెన్ మళ్ళీ ఉపయోగించబడినట్లు గుర్తించినప్పుడు, ఆ family_id కోసం revoked ఫ్లాగ్ సెట్ చేయబడుతుంది, తద్వారా రాజీ పడిన (compromised) సెషన్కు చెందిన ప్రతి టోకెన్ తక్షణమే రద్దు చేయబడుతుంది. ఇది నిశ్శబ్దంగా జరిగే హైజాకింగ్ను లాగ్లలో కనిపించే హై-సిగ్నల్ అలర్ట్గా మారుస్తుంది.
సిస్టమ్ను నమ్మదగినదిగా ఉంచే మూడు ఇంప్లిమెంటేషన్ నియమాలు
ముందుగా సిగ్నేచర్ను ధృవీకరించండి సర్వర్ సిగ్నేచర్ను ధృవీకరించే ముందు “used-before?” అని తనిఖీ చేస్తే, అటాకర్ టోకెన్ ఐడిలను ఊహించి భారీ స్థాయిలో రద్దులను (mass revocations) కలిగించవచ్చు. మొదట ప్రామాణికతను (authenticity) నిర్ధారించడం వల్ల అనవసరమైన డీనియల్-ఆఫ్-సర్వీస్ (denial-of-service) దాడులను నివారించవచ్చు.
గ్రేస్ విండోను (grace window) అనుమతించండి టోకెన్ గడువు ముగిసినప్పుడు మొబైల్ యాప్లు తరచుగా తక్కువ వ్యవధిలో రెండు రిఫ్రెష్ రిక్వెస్ట్లను పంపుతుంటాయి. సర్వర్ చాలా కఠినంగా ఉంటే, రెండో రిక్వెస్ట్ మళ్ళీ ఉపయోగించినట్లుగా గుర్తించబడి, చట్టబద్ధమైన యూజర్ను లాగ్ అవుట్ చేస్తుంది. కొన్ని సెకన్ల బఫర్ ఉండటం వల్ల, “ఉపయోగించిన” టోకెన్ కూడా కొత్త జంటను తిరిగి ఇవ్వగలదు, ఇది రేస్ కండిషన్స్ (race conditions) ను తగ్గిస్తుంది.
రో లాకింగ్తో (row locking) మొత్తం ఫ్లోను ఒక ట్రాన్సాక్షన్లో ఉంచండి అటామిసిటీ (atomicity) లేకపోతే, రెండు ఏకకాలపు (concurrent) రిక్వెస్ట్లు కూడా తామే మొదటిసారి టోకెన్ను ఉపయోగిస్తున్నామని అనుకోవచ్చు, దీనివల్ల డూప్లికేట్ రిఫ్రెష్ టోకెన్లు జారీ చేయబడతాయి మరియు సింగిల్-యూజ్ గ్యారెంటీ దెబ్బతింటుంది. టోకెన్ రోను లాక్ చేసే డేటాబేస్ ట్రాన్సాక్షన్, కేవలం ఒకే రిక్వెస్ట్ విజయవంతమవుతుందని హామీ ఇస్తుంది.
ముఖ్య అంశం (Takeaway): రిఫ్రెష్ టోకెన్లను ఒకసారి మాత్రమే ఉపయోగించేలా చేయడం మరియు వాటి పునరావృతం (reuse) కోసం గమనించడం ద్వారా, ఒక సిస్టమ్ దొంగిలించబడిన ప్రతి క్రెడెన్షియల్ను ఒక అలారమ్గా మార్చగలదు, తద్వారా ప్లాట్ఫారమ్ అంతటా లాగ్ అవుట్ చేయకుండానే వినియోగదారులను రక్షించగలదు.