पासवर्ड में यह शामिल नहीं हो सकता: select, insert, update, delete, drop

मूल लेख ↗ Hacker News चर्चा ↗

एक university password-reset पेज, जो `select`, `insert`, और `drop` जैसे SQL keywords वाले passwords को प्रतिबंधित करता है, ने उसकी security practices को लेकर बहस छेड़ दी है। Commenters का तर्क है कि ऐसे keyword filters क्लासिक “security theater” हैं, जो plaintext passwords के unsafe handling और parameterized queries की कमी का संकेत देते हैं; हालांकि कुछ लोग इन्हें legacy systems या overzealous web application firewalls वाले environments में नुकसान कम करने का एक crude तरीका मानते हैं। यह चर्चा आगे बढ़कर password storage, client-side hashing, और data breaches के लिए regulatory accountability के कमजोर industry standards की आलोचना तक जाती है।

पासवर्ड कीवर्ड प्रतिबंध के निहितार्थ

  • बहुत से लोग पासवर्ड में “no select/insert/update/delete/drop” नियम को खराब सुरक्षा प्रथाओं का संकेत मानते हैं, जिससे यह संदेह पैदा होता है कि:
    • संभवतः parameterized queries के बजाय string‑concatenated SQL queries इस्तेमाल हो रही हैं।
    • संभवतः SQL के भीतर plaintext passwords को ही संभाला जा रहा है, केवल hashes को नहीं।
  • कुछ अन्य लोग तर्क देते हैं कि यह बस किसी misconfigured WAF या legacy system का परिणाम हो सकता है, जरूरी नहीं कि मौजूदा backend का, लेकिन फिर भी यह दिखाता है कि कुछ न कुछ ठीक से implement नहीं हुआ है।
  • साइट से एक commenter स्पष्ट करता है कि यह विशेष पेज सिर्फ external account management के लिए एक interface है और text request पर जोड़ा गया था; इसका कोई स्पष्ट technical कारण नहीं है।

SQL और Passwords का सही हैंडलिंग

  • व्यापक सहमति: SQL injection से सही बचाव parameterized queries हैं, keyword blacklists या manual escaping नहीं।
  • Blacklist/“sanitization” approaches को fragile, bypassable, और कठिन-maintenance वाला बताया गया है।
  • कई comments इस बात पर जोर देते हैं कि passwords को:
    • Server-side पर, यथासंभव जल्दी, hash किया जाना चाहिए (salt के साथ, slow KDF)।
    • Plaintext में कभी store या log नहीं करना चाहिए।
    • आदर्श रूप से plaintext में database तक कभी नहीं पहुंचना चाहिए; केवल hashed values ही होनी चाहिए।

Client-Side Hashing, WAFs, और Protocols

  • Client-side hashing को सामान्यतः आलोचना का सामना करना पड़ता है:
    • जो भी भेजा जाता है (hash या password), वही credential बन जाता है; इससे “pass-the-hash” attacks संभव होते हैं और MITM या database leaks से सार्थक सुरक्षा नहीं मिलती।
  • कुछ लोग PAKE/SRP-शैली के protocols का उल्लेख करते हैं जो password भेजे बिना काम करते हैं, लेकिन नोट करते हैं कि वे web apps में दुर्लभ हैं।
  • कई लोग अनुमान लगाते हैं कि overly aggressive WAF rules SQL-जैसे substrings को block कर रहे हैं (पासवर्ड और form text में भी), जिससे user-visible failures हो रहे हैं और ऐसे “don’t use SQL words” notices आने पड़ रहे हैं।

Password Policy और Usability समस्याएँ

  • select जैसे सामान्य शब्दों पर प्रतिबंध passphrase guidance और xkcd-शैली के multi-word passwords से टकराता है।
  • उदाहरण दिए गए हैं:
    • मनमानी length और character limits (जैसे 6-digit PINs, 9-character max, ASCII-only)।
    • “create” और “login” forms के बीच mismatched limits।
    • Filters जो user input को बिगाड़ देते हैं या चुपचाप उस सामग्री को drop कर देते हैं जो “SQL” या HTML/JS जैसी दिखती है।

Security Theater बनाम Harm Reduction

  • एक पक्ष: ये उपाय हानिकारक security theater हैं; ये:
    • मूल incompetence को ढकते हैं।
    • false confidence देते हैं।
    • attackers के लिए trivially bypassable होते हैं, लेकिन users को frustrate करते हैं।
  • दूसरा पक्ष: ऐसे संसार में जहाँ बहुत-सी systems खराब बनी हैं और जिन्हें हम आसानी से ठीक नहीं कर सकते, यदि crude mitigations obvious injection patterns को block करके कुछ नुकसान कम कर दें, तो भी लाभ हो सकता है, खासकर यदि auditors या regulations उन्हें आसानी से test कर सकें।
  • Counter-argument: ऐसे half-measures निम्न standards को जड़ जमा देते हैं और वास्तविक fixes में देरी करते हैं; इसके बजाय मजबूत legal और professional accountability का समर्थन किया जाता है।