Have I Been Pwned 2.0

 (troyhunt.com)
2 पॉइंट द्वारा GN⁺ 2025-05-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • डेटा लीक जांच सेवा Have I Been Pwned को पूरी तरह से नए रूप में फिर से तैयार किया गया है
  • नए डिज़ाइन के साथ प्रमुख वेब पेजों की कार्यक्षमता में बड़े पैमाने पर बदलाव और सुधार किए गए हैं
  • सर्च फीचर अब और अधिक सहज हो गया है, और अकाउंट वेरिफिकेशन के तरीके तथा विभिन्न डेटा breach मामलों की जानकारी को मजबूत किया गया है
  • यूज़र डैशबोर्ड, डोमेन सर्च, API दस्तावेज़ जैसे कई नए और बेहतर फीचर्स जोड़े गए हैं
  • वेब परफ़ॉर्मेंस और सुरक्षा को आधुनिक cloud infrastructure पर लागू किया गया है, जिससे तेज़ और सुरक्षित यूज़र अनुभव मिलता है

परिचय और पृष्ठभूमि

  • Have I Been Pwned (आगे HIBP) 2.0 को लंबे विकास काल के बाद पूरी तरह नए रूप में जारी किया गया है
  • फ़रवरी 2023 में पहला commit, मार्च 2024 में soft launch और open source प्रक्रिया के बाद, पूरी तरह से पुनर्निर्मित और नई brand identity वाले साइट के रूप में इसे खोला गया
  • पूरे साइट की संरचना और फीचर्स का पुनर्गठन किया गया है, और नए फीचर्स के साथ merchandise store भी शुरू किया गया है

सर्च फीचर

  • HIBP का मुख्य होमपेज सर्च बॉक्स अब और अधिक सहज हो गया है, और इसमें ताज़ा विज़ुअल प्रस्तुति (confetti animation) जोड़ी गई है
  • यूज़र अनुभव को बोझिल न बनाने के लिए भारी और नकारात्मक माहौल से बचते हुए, यूज़र्स को तथ्य-आधारित व्यावहारिक जानकारी देने पर ध्यान दिया गया है
  • वेबसाइट से username और फ़ोन नंबर सर्च हटा दिए गए हैं (हालांकि API में पुराना तरीका बरकरार है)
    • email address आधारित सर्च parsing, alerts और service consistency के लिहाज़ से अधिक उपयुक्त है
    • फ़ोन नंबर और username का data processing बोझ अधिक है, और वास्तव में इनका उपयोग लगभग नहीं होता, इसलिए भ्रम कम करने के लिए इन्हें हटाने का निर्णय लिया गया

डेटा breach केस पेज

  • हर breach (लीक) मामले के लिए अब समर्पित डिटेल पेज उपलब्ध कराया गया है
  • पहले की तुलना में अधिक सहज और बेहतर लेआउट के साथ, प्रभाव की स्थिति, प्रतिक्रिया के तरीके और अन्य ठोस व लागू किए जा सकने वाले अनुकूलित सुझाव दिए जाते हैं
  • अन्य संस्थाओं (जैसे NCSC) के साथ सहयोग के ज़रिए क्षेत्र-विशिष्ट जानकारी भी आगे जोड़ी जाएगी
  • आगे चलकर 2FA, passkey आदि के सपोर्ट और यूज़र-कस्टमाइज़्ड गाइड जैसी विस्तृत जानकारी जोड़े जाने की योजना है

डैशबोर्ड

  • पहले के कई फीचर्स (sensitive breach जांच, domain management, subscription management आदि) को एकीकृत डैशबोर्ड में समेकित किया गया है
  • डैशबोर्ड तक पहुंच email verification के आधार पर दी जाती है, और आगे passkey जैसे नए authentication तरीके भी जोड़े जाएंगे
  • family account alerts जैसी भविष्य की विस्तार योग्य सुविधाओं के लिए इसे एक platform के रूप में विकसित किया जा सकता है

डोमेन सर्च फीचर

  • डोमेन वेरिफिकेशन/सर्च फीचर को पूरी तरह से फिर से डिज़ाइन किया गया है, जिसमें अधिक साफ़ UI और कई filters (जैसे केवल नवीनतम leaks देखना) जोड़े गए हैं
  • पूरी तरह single-page app (SPA) संरचना पर आधारित होने के कारण, सर्च परिणाम API के ज़रिए JSON में तेज़ी से दिए जाते हैं
  • domain ownership verification प्रक्रिया को भी नए सिरे से सरल बनाया गया है
  • email के अलावा अन्य authentication तरीकों में अलग से सुधार की योजना है

API

  • इस अपडेट में API में स्वयं कोई बदलाव या बंदी बिल्कुल नहीं है
  • API documentation को OpenAPI-आधारित Scalar टूल पर लाने की तैयारी है, लेकिन फिलहाल मौजूदा दस्तावेज़ बनाए रखते हुए उन्हें नई शैली में एकरूप किया गया है
  • आगे चलकर इन्हें Scalar-आधारित आधुनिक दस्तावेज़ में बदला जाएगा

merchandise और stickers

  • HIBP ब्रांडेड goods shop आधिकारिक रूप से खुल गई है, और T-shirt जैसे उत्पादों की बिक्री शुरू हो गई है (Teespring आधारित, बिना margin)
  • stickers को Sticker Mule store पर पहले की तरह जारी रखा गया है, और artwork open source के रूप में स्वतंत्र रूप से इस्तेमाल किया जा सकता है

तकनीक और इन्फ्रास्ट्रक्चर

  • साइट का backend Microsoft Azure पर आधारित है, जिसमें App Service, Functions, Hyperscale SQL, Storage आदि का उपयोग किया गया है
  • मुख्य web app को C# और .NET 9.0, ASP.NET MVC (.NET Core) में लिखा गया है
  • Cloudflare का उपयोग WAF, caching, Turnstile (anti-bot), R2 storage आदि के लिए प्रभावी रूप से किया गया है
  • frontend में आधुनिक interface के लिए नवीनतम Bootstrap, SASS और TypeScript का उपयोग किया गया है
  • Iceland-आधारित डेवलपर Ingiber सहित प्रमुख सदस्यों के योगदान से उच्च गुणवत्ता और आकर्षक UI हासिल किया गया है
  • वेब पेज का आकार और request की संख्या क्रमशः लगभग 28% और 31% तक घटाई गई है, जिससे 11 साल पहले की तुलना में अधिक प्रभावी optimization हासिल हुआ है
  • tracking, ad data जैसी अनावश्यक चीज़ों को पूरी तरह हटाया गया है, और यूज़र privacy को महत्व दिया गया है

AI का उपयोग

  • इस साइट rebuild प्रक्रिया में Chat GPT का सक्रिय रूप से उपयोग CSS, icon recommendations, Cloudflare settings, .NET Core के विशेष बिंदुओं और कई अन्य development समस्याओं को हल करने में किया गया
  • AI के तेज़ सुझावों और code automation से productivity में बड़ा सुधार महसूस किया गया
  • तेज़ migration और task automation जैसे कामों में इसकी उच्च सटीकता और उपयोगिता की पुष्टि हुई

विकास यात्रा और निष्कर्ष

  • legal documents को अपडेट करने जैसे कई अदृश्य कामों में लंबे समय और लागत की आवश्यकता पड़ी
  • launch से पहले और बाद में कई बार urgent fixes और दोहराए गए releases के ज़रिए समस्याओं को तेज़ी से हल किया गया
  • मूल उद्देश्य को बनाए रखते हुए service की विशेषज्ञता, scalability और आरामदायक उपयोग अनुभव को बरकरार रखकर नया आरंभ पूरा किया गया
  • HIBP, 2013 से जीवन के एक चौथाई हिस्से की लगन का परिणाम है, और इस 2.0 के साथ community service के रूप में नई छलांग की उम्मीद है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-05-20
Hacker News प्रतिक्रियाएँ
  • एक कानूनी फर्म के साथ पार्टनरशिप करके, लापरवाही से होने वाले हर डेटा breach (व्यावहारिक रूप से लगभग हर मामले) पर class action मुकदमों को आगे बढ़ाने की इच्छा जताई गई, फिर भुगतान बैंकिंग service के साथ जोड़कर settlement राशि सीधे लाखों लोगों को भेजी जाए, तो यह किसी आधुनिक नायक जैसा काम हो सकता है—ऐसी कल्पना साझा की गई। इस बात पर ज़ोर दिया गया कि वास्तव में लापरवाह कंपनियों को कड़ा दंड दिला सकने वाले वकीलों के साथ काम करना महत्वपूर्ण है; सिर्फ छोटे-मोटे settlement गैर-जिम्मेदार प्रबंधन को जारी रहने देने का जोखिम पैदा करते हैं। वैकल्पिक रूप से, मुकदमे से ठीक पहले की डेटा जानकारी निवेश फर्मों को बेचने की संभावना का भी उल्लेख किया गया। अंततः ऐसी सामाजिक स्थिति बनने की आशा जताई गई जिसमें सिर्फ डेटा breach की खबर से ही संबंधित कंपनी के stock price पर चोट पहुँचे।
    • यह इच्छा जताई गई कि अगर settlement होने पर हर बार एक छोटी राशि तुरंत किसी अच्छे उद्देश्य के लिए दान की जा सके, तो class action में शामिल होने की प्रेरणा और बढ़ेगी।
    • उस बैंकिंग service को लेकर मज़ाकिया चिंता जताई गई कि उस सिस्टम में संग्रहीत डेटा खुद कब तक सुरक्षित रहेगा, और उसके भी लीक होने में कितना समय लगेगा।
    • चिंता जताई गई कि ऐसी प्रणाली का उल्टा असर भी हो सकता है। कंपनियों के लिए breach का खुलासा करना पहले से ही कठिन है; ऐसी संरचना सिर्फ जोखिम बढ़ाएगी और खुलासा टालने की प्रवृत्ति बढ़ा सकती है। राय दी गई कि यह जानना बेहतर है कि मेरी जानकारी लीक हुई है ताकि मैं पासवर्ड बदल सकूँ।
    • यह शिकायत जताई गई कि Google को मेरी निजी जानकारी बेचे जाने के कारण Blue Shield से मुआवज़ा मिलने का इंतज़ार अब भी है, और साथ ही ऐसी service का उपयोग करने की इच्छा भी व्यक्त की गई।
  • यह हैरानी जताई गई कि पिछले सिर्फ 10 वर्षों के भीतर भी LinkedIn जैसे विशाल site ने बिना salt लगाए password स्टोर किए थे; सवाल उठाया गया कि आज के समय में ऐसी गलती कैसे हो सकती है।
    • समझाया गया कि अनजाने में ऐसी घटना उम्मीद से अधिक आसानी से हो सकती है। middleware के नज़रिये से JSON डेटा में password field बस एक और field लग सकती है, और अगर API या logging system पूरा request body log कर दे तो वास्तविक समस्या पैदा हो सकती है। बिना salt वाले password को सीधे password store में रखना दुर्लभ होगा, लेकिन उदाहरण के लिए Android app के API gateway में ‘password recovery’ जैसी flow को sensitive information के रूप में चिह्नित करना भूल जाएँ तो मिलती-जुलती समस्या हो सकती है—ऐसा अनुभव साझा किया गया।
    • मज़ाक में कहा गया कि ऐसी गलतियाँ इसलिए होती हैं क्योंकि engineering interview में पर्याप्त Leetcode Hard प्रश्न नहीं पूछे गए।
    • यह कहा गया कि AI Slop की बहुत चर्चा होती है, लेकिन लंबे समय से Outsourced Slop की समस्या भी गंभीर रही है। अनुभव के आधार पर यह भी कहा गया कि LinkedIn में भी outsourced programmers का output एक प्रमुख कारण रहा होगा। तर्क दिया गया कि सिर्फ मजबूत और सक्षम managers ही quality standard तय करके और सत्यापन करके ऊपर से ठीक दिखने वाले लेकिन अंदर से कमज़ोर उत्पादों से बचा सकते हैं।
    • यह संभावना जताई गई कि ऐसी गलतियाँ पुराने legacy mainframe जैसे सिस्टमों के कारण होती हैं, जिन्हें कोई समय या budget न मिलने से maintain या migrate नहीं कर पाता। कहा गया कि बड़ी कंपनियों में महत्वपूर्ण सिस्टमों की जड़ता इतनी बढ़ जाती है कि लगभग 1 घंटे का downtime भी लाखों रुपये के ‘नुकसान’ के रूप में देखा जाता है, जिससे maintenance और भी असंभव हो जाती है।
  • यह राय दी गई कि बहुत से आम लोग Have I Been Pwned का नियमित उपयोग करते हैं और 1Password की ओर जाना सबसे अच्छा विकल्प है। वास्तव में 1Password के साथ promotion बहुत उपयुक्त collaboration है। यह सुझाव दिया गया कि उस banner के वाक्य को "ज़ोरदार सिफारिश" जैसा कुछ बनाकर और अधिक प्रमुख किया जाए। इस बात पर ज़ोर दिया गया कि social account hacks के अधिकांश मामले password reuse के कारण होते हैं, और ऐसे अनुभवों से सुरक्षित password उपयोग की शिक्षा और password manager की ओर लोगों को लाना बहुत सकारात्मक है। पिछले 1 वर्ष में 20 से अधिक वास्तविक मामलों में मदद करने का अनुभव साझा करते हुए redesign पर बधाई दी गई।
  • सभी डेटा breach रिकॉर्ड को लोगो और परिचय पाठ के साथ vertical scroll रूप में दिखाने वाली सुविधा को डरावनी लेकिन शानदार बताया गया।
    • डेटा breach देखते समय बेबसी महसूस होती है, और credit freeze के अलावा लगभग कोई कार्रवाई संभव नहीं लगती—ऐसी आत्म-विडंबनात्मक प्रतिक्रिया दी गई।
  • यह जिज्ञासा जताई गई कि सबसे ज़्यादा डेटा breach रिकॉर्ड किसके पास होगा। अनुभव साझा किया गया कि मेरा मुख्य email अब तक 40 breach में आया है; सबसे पुराना जून 2011 का है (HackForums, याद भी नहीं), और सबसे हालिया सितंबर 2024 का (FrenchCitizens, फ्रांस से कोई संबंध नहीं)।
    • किसी ने जवाब दिया कि उसने यह रिकॉर्ड 1 से पार कर लिया है।
    • यह चौंकाने वाला रिकॉर्ड साझा किया गया कि john@yahoo.com email 322 breach में सामने आया है।
  • अधिक privacy चाहने वालों के लिए यह टिप दी गई कि उस service में opt-out सुविधा है, जिससे email search result छिपाए जा सकते हैं।
  • यह इच्छा जताई गई कि कई email alias उपयोग करने के कारण एक-एक करके खोज पाना संभव नहीं, इसलिए domain के आधार पर एक साथ खोजने की सुविधा होनी चाहिए।
    • बताया गया कि "The Domain Search Feature" अनुभाग के तहत domain ownership verify करने के बाद एक साथ परिणाम देखे जा सकते हैं।
  • site को वास्तव में शानदार बताया गया और यह उम्मीद जताई गई कि सरकारें इस समस्या को अधिक गंभीरता से लें। इस बात पर ज़ोर दिया गया कि identity theft और account takeover जैसी समस्याएँ अंततः डेटा breach से शुरू होती हैं, और आज के समय में वास्तविक घर में चोरी होने से भी अधिक गंभीर आपदा डिजिटल accounts का compromise होना है। कहा गया कि physical break-in के मामले में 911 जैसी reporting और tracking व्यवस्था स्पष्ट होती है, लेकिन digital compromise के मामले में न संपर्क बिंदु होते हैं, न समाधान प्रक्रिया; इसलिए सामाजिक प्रतिक्रिया बदलनी चाहिए।
  • redesign की बहुत सकारात्मक सराहना की गई, और कहा गया कि Troy के updates को follow करना आनंददायक है, हालांकि कभी-कभी इसमें black humor जैसा आकर्षण भी महसूस होता है। यह भ्रम साझा किया गया कि timeline शायद सबसे पुराने breach से नए breach तक sorted लगती है, लेकिन date display वास्तव में breach होने की तारीख नहीं बल्कि उसके सार्वजनिक होने की तारीख है। समाधान के रूप में सुझाव दिया गया कि sorting और display दोनों को ‘प्रकाशन तिथि’ के आधार पर किया जाए, और card के भीतर वास्तविक breach date को मानक format में अलग से दिखाया जाए ताकि बात अधिक स्पष्ट हो।