छोटी session expiry सुरक्षा में मदद नहीं करती

• वेब applications आमतौर पर एक निश्चित समय या उपयोगकर्ता की निष्क्रियता की अवधि के बाद session को expire कर देती हैं, और मौजूदा security सलाह छोटी session timeout का सुझाव देती है
• लेकिन Gmail या GitHub जैसे कई लोकप्रिय वेब applications इस practice का पालन नहीं करते, जिससे यह सवाल उठता है कि क्या छोटी session timeout वास्तव में security को मजबूत करने में प्रभावी है
• यहाँ विचार किया गया threat model उन attackers को शामिल करता है जो session cookie चुरा लेते हैं, session fixation vulnerability का दुरुपयोग करते हैं, या पीड़ित के समान device का उपयोग करके उपयोगकर्ता के active session तक unauthorized access प्राप्त करते हैं
• जब उन scenarios की बात की जाती है जहाँ छोटी session timeout उपयोगी हो सकती है, तो उदाहरण के तौर पर ऐसे attacker का उल्लेख किया जाता है जो logs या चोरी हुए computer में पुराने session token ढूंढ़ता है, लेकिन यह सामान्य session timeout के पक्ष में तर्क है, जरूरी नहीं कि खास तौर पर छोटी timeout के लिए
• साझा public computer की समस्या अधिकांश वेब applications के लिए व्यावहारिक नहीं है, और unlocked device तक पहुँच रखने वाला attacker active session की आवश्यकता के बिना नया session बनाकर इसे bypass कर सकता है
• यानी, छोटी session उपयोगकर्ता अनुभव और security दोनों के लिए नुकसानदेह हो सकती है, और बार-बार re-authentication उपयोगकर्ताओं को कम सुरक्षित practices अपनाने के लिए प्रेरित कर सकती है
• निष्कर्ष यह है कि session token आमतौर पर सुरक्षित होते हैं, और छोटी session timeout से रोके जा सकने वाले attacks दुर्लभ हैं. Disk encryption और computer lock जैसी अन्य उपाय अधिक प्रभावी security दे सकते हैं
• Facebook, Google, Amazon, GitHub जैसी प्रमुख कंपनियों में non-expiring sessions हैं, जिससे लगता है कि वे इस risk को स्वीकार्य मानती हैं

[GN⁺]

Hacker News राय

• बैंक और वित्तीय ऐप्स में छोटा session expiry आम है, और व्यापक user base, अवसरवादी हमलावरों के लिए आकर्षण, तथा तनावपूर्ण या असामान्य परिस्थितियों में उपयोग के कारण इसे उचित ठहराया जा सकता है।
• जब कोई भरोसेमंद backchannel नहीं होता और identity provider के लिए service को session expiry की सूचना देना संभव नहीं होता, तब कमजोर authentication standards की कमी पूरी करने के लिए छोटा session expiry अक्सर इस्तेमाल किया जाता है।
• shared device पर application इस्तेमाल करने का खतरा एक समस्या है, और खासकर परिवार जैसे वातावरण में जहाँ device साझा किए जाते हैं, session expiry application-specific होना चाहिए।
• कुछ users का तर्क है कि छोटा session expiry usability की कीमत पर security measure के रूप में इस्तेमाल होता है, और वे self-checkout systems का उदाहरण देते हैं।
• user separation के बिना shared computers वास्तविकता हैं, और इनका इस्तेमाल अक्सर sensitive information वाले web applications तक पहुँचने के लिए किया जाता है।
• इस लेख की आलोचना की जा रही है कि यह बिना आधार वाली धारणाएँ बनाता है और काल्पनिक end-user setups के आधार पर छोटे sessions को security control के रूप में खारिज करता है।
• कुछ users का कहना है कि Google का छोटे sessions का उपयोग न करने का फैसला security concerns से अधिक advertising उद्देश्यों के लिए अधिक user data इकट्ठा करने की इच्छा से प्रेरित हो सकता है।
• छोटे sessions users के लिए प्रतिकूल और असुविधाजनक हो सकते हैं, खासकर जब वे workflow में बाधा डालते हैं और बिना चेतावनी के re-authentication की माँग करते हैं।
• कुछ users लंबी session timeouts को पसंद करते हैं, और उनका तर्क है कि छोटे session timeouts अप्रभावी हैं तथा केवल auditors और pentesters द्वारा किए जाने वाले checkbox tests को संतुष्ट करने के लिए उपयोग होते हैं।
• user activity के आधार पर reset होने वाले soft session timeout और user activity की परवाह किए बिना एक निश्चित अवधि के बाद session समाप्त करने वाले hard session timeout के बीच अंतर होता है।