Have I Been Pwned 2.0 जारी
(troyhunt.com)- लंबे समय से तैयार किया जा रहा HIBP rebranding अब वास्तविक service में बदल गया है, और इसके साथ वेबसाइट का पूरा पुनर्निर्माण तथा लगभग हर page की feature redesign जारी की गई है
- मुख्य search में result experience बेहतर किया गया है, लेकिन वेबसाइट से username·phone number search हटा दी गई है, जबकि मौजूदा API compatibility बरकरार है
- नई breach-specific pages search results को कम जटिल बनाती हैं और incident के बाद user क्या ठोस कदम उठा सकता है, इसकी अलग guidance screen देती हैं
- email access verification की ज़रूरत वाली सुविधाओं को Sign In-आधारित dashboard में समेटा गया है, और domain search अब JSON API व client-side filtering के साथ अधिक तेज़ चलती है
- tech stack को Azure, Cloudflare, .NET 9.0, Bootstrap और TypeScript के इर्द-गिर्द व्यवस्थित किया गया है, तथा Google reCAPTCHA हटाकर सिर्फ Cloudflare Turnstile का उपयोग किया गया है
नई वेबसाइट और search experience
- नई Have I Been Pwned वेबसाइट जारी कर दी गई है
- public repository में rebranding का पहला commit फ़रवरी 2024 में किया गया था
- नया brand मार्च 2025 में soft launch किया गया था
- इस release में वेबसाइट का पूर्ण पुनर्निर्माण, लगभग सभी pages के function changes, नए features और merch store का लॉन्च शामिल है
- मुख्य search box HIBP की flagship functionality को बनाए रखता है, लेकिन result दिखाने का तरीका बदलता है
- कुछ users को बधाई वाला reaction और confetti animation दिखाई देगा
- breach मिलने पर अधिक शांत लाल response दिखाया जाता है
- results reverse chronological order में scroll की जा सकने वाली timeline के रूप में हैं, और हर breach का summary भी साथ दिया जाता है
- वेबसाइट search में username और phone number support हटा दिया गया है
- username search को 2014 के Snapchat incident के लिए जोड़ा गया था
- phone number search को 2021 के Facebook incident के लिए जोड़ा गया था
- इन दोनों data types को उन दो मामलों के अलावा कभी लोड नहीं किया गया
- username से owner की पहचान करना कठिन है, और phone number को international format व अलग-अलग notation के कारण parse करना मुश्किल है
- SMS alerts की लागत email से बहुत अधिक है
- पुरानी साइट पर ये inputs स्वीकार करने से “मेरा number किसी खास breach में क्यों नहीं है?” जैसी उलझन और support burden पैदा हुआ
- API में compatibility बनाए रखने के लिए यह support जारी रहेगा, लेकिन आगे अतिरिक्त data आने की उम्मीद नहीं करने को कहा गया है
breach-specific dedicated pages
- नई breach page मुख्य search results के ज़रूरत से ज़्यादा जटिल होने की समस्या को कम करने के लिए breach details को अलग screen पर ले जाती है
- उदाहरण: Ashley Madison breach page
- मौजूदा जानकारी को अधिक user-friendly तरीके से दिखाया गया है
- page का मुख्य बदलाव यह है कि breach के बाद user क्या कार्रवाई कर सकता है, इसकी अधिक ठोस guidance दी जाए
- focus इस बात पर है कि breach का शिकार user को क्या करना चाहिए
- इसमें identity protection provider जैसी partner services से जोड़ने की दिशा भी शामिल है
- भविष्य में breach और user-specific data को और समृद्ध करने की योजना है
- यदि संबंधित service 2FA support करती है, तो सामान्य guidance की जगह इसे विशेष रूप से दिखाया जाएगा
- passkey के लिए भी अलग section जोड़ा जाएगा
- UK NCSC के साथ चर्चा में UK users के लिए NCSC logo और संबंधित guidance resources दिखाने वाली localized data breach guide पर बात हुई
unified dashboard और domain search
- email address access confirmation की ज़रूरत वाली features कई वर्षों में बढ़ती गईं, इसलिए इन्हें एक central dashboard में एकीकृत किया गया है
- 2015 के Ashley Madison incident के समय sensitive breach की अवधारणा आई, जिससे email receipt के माध्यम से verification ज़रूरी हुआ
- 2019 में API abuse कम करने के लिए API में authentication layer जोड़ी गई, और API key खरीदने से पहले email verification अनिवार्य हुआ
- इसके बाद domain search dashboard, paid subscription management और stealer logs lookup जोड़े गए
- नया dashboard एक Sign In के पीछे email address access verify करने के बाद संबंधित features दिखाता है
- इसमें public-facing features और business-oriented features दोनों शामिल हैं
- आगे email भेजे बिना login संभव बनाने के लिए passkey support जोड़ने की योजना है
- परिवार के email addresses को alert subscription में दर्ज करके notifications किसी दूसरे address पर प्राप्त करने जैसी सुविधा dashboard के लिए उपयुक्त उदाहरण के रूप में दी गई है
- domain search में UI cleanup और filtering improvements बड़े पैमाने पर किए गए हैं
- verified domains की सूची अधिक साफ-सुथरी हो गई है
- search results अब अधिक स्पष्ट summary देते हैं
- email address के हिसाब से filtering और “सिर्फ latest breach दिखाएँ” filter जोड़ा गया है
- domain search dashboard API से JSON प्राप्त करता है और पूरा dashboard single-page app की तरह काम करता है
- filtering पूरे domain search JSON पर client-side की जाती है
- 2.5 लाख से अधिक breached email addresses वाले domain पर भी इसे काम करते हुए test किया गया
- हालांकि इतने बड़े data को browser में scroll करने के बजाय API के ज़रिए लेना अधिक उपयुक्त माना गया
- domain ownership verification भी पूरी तरह से फिर से लिखा गया है
- इसे अधिक साफ और सरल interface में बदला गया है
- email के अलावा verification methods को अभी और सुचारु बनाने का काम बाकी है
API docs और merch store
- API में स्वयं कोई बदलाव नहीं है
- इस update में breaking changes नहीं किए गए हैं
- मौजूदा API users के लिए कुछ भी टूटेगा नहीं
- API documentation को नए तरीके में migrate नहीं किया जा सका और पुराना documentation बरकरार रखा गया
- UX rebuild GitHub repo में API documentation approach पर चर्चा हुई थी, और सामान्य सहमति OpenAPI पर थी
- Scalar का उपयोग कर काम किया गया, और इसे haveibeenpwned.com/scalar पर देखा जा सकता है
- Scalar कई languages के samples और browser के भीतर test runner प्रदान करता है
- बड़े launch schedule के भीतर इसे पूरा नहीं किया जा सका, इसलिए पुराना API documentation नए site style के साथ बनाए रखा गया
- आगे समय मिलने पर Scalar implementation पर switch करने की योजना है
- HIBP merch store merch.haveibeenpwned.com पर जारी किया गया है
- यह Teespring के माध्यम से संचालित है
- सभी products cost price पर बेचे जाते हैं, कोई profit नहीं लिया जाता
- इसे community के लिए एक मज़ेदार पहल के रूप में तैयार किया गया है
- stickers के लिए Teespring का विकल्प पहले के Sticker Mule quality तक नहीं पहुँचता, इसलिए पुराना Sticker Mule store जारी रखा गया है
- open source artwork भी उपलब्ध है, ताकि चाहें तो कहीं और खुद print करा सकें
tech stack और performance
- मूल service अब भी Microsoft Azure पर चल रही है
- वेबसाइट App Service का उपयोग करती है
- अधिकतर API serverless Functions का उपयोग करती हैं
- SQL Azure Hyperscale, queues, blobs, tables जैसे storage account features का उपयोग किया जाता है
- code अधिकतर C# में है, और .NET 9.0 तथा ASP.NET MVC on .NET Core का उपयोग करता है
- Cloudflare की भी बड़ी भूमिका बनी हुई है
- Workers में काफी code है
- data R2 storage में है
- WAF और caching features का उपयोग किया जाता है
- anti-automation के लिए सिर्फ Cloudflare Turnstile का उपयोग होता है और Google reCAPTCHA पूरी तरह हटा दिया गया है
- frontend latest Bootstrap generation, SASS और TypeScript का उपयोग करता है
- CSS को SASS में लिखा गया है
- JavaScript को TypeScript में लिखा गया है
- वेबसाइट performance में मापी जा सकने वाली improvements हैं
- Pingdom tests के अनुसार page size 28% कम की गई है
- requests की संख्या 31% कम की गई है
- load time में variability ज़्यादा होने के कारण बड़े अंतर का ठोस दावा नहीं किया गया
- 11 साल बाद भी webpage size और request count में double-digit reduction हासिल करना खास बताया गया
- tracking या ad-related overhead जैसे elements नहीं जोड़े गए हैं
- वास्तविक traffic stats Cloudflare edge node से गुजरने वाले traffic पर आधारित हैं
- 1Password product placement सिर्फ text और images तक सीमित है
- outbound clicks भी track नहीं किए जाते
- intrusive tracking metrics चाहने वाली identity theft कंपनियों के साथ product placement discussions इससे और कठिन हो जाती हैं
development process में AI का उपयोग
- ChatGPT का rebuild process में, खासकर आखिरी कुछ दिनों में, व्यापक उपयोग किया गया
- Bootstrap icons में “Index” heading के लिए सही icon ढूँढने में इसका उपयोग हुआ
- 2,000 से अधिक icons में से उपयुक्त विकल्प लगभग 30 seconds में ढूँढने जैसे काम किए गए
- site migration verification में भी AI का उपयोग हुआ
haveibeenpwned.comको crawl कर unique URLs निकालने वाला PowerShell script बनवाया गया- मिले हुए paths
stage.haveibeenpwned.comपर मौजूद हैं या नहीं, यह जाँचने वाला script भी बनवाया गया - missing
security.txtfile ढूँढने में मदद मिली - कुछ ऐसी चीज़ें भी ढूँढ ली गईं जो कभी मौजूद ही नहीं थीं, इसलिए “trust, but verify” की ज़रूरत पड़ी
- CSS advice, Cloudflare rule configuration और .NET Core web app quirks जैसे छोटे कामों में भी इसका उपयोग हुआ
- जवाबों की सटीकता को लगभग 90% आंका गया
- यहाँ तक कहा गया कि software development में AI का सक्रिय उपयोग न करना गलत approach है
launch और Turnstile issues
- नई साइट लेखक के स्थानीय समय के अनुसार रविवार तड़के deploy की गई
- लगभग सब कुछ ठीक रहा, और एक-दो छोटे glitches को जल्दी fix कर deploy कर दिया गया
- लेख live होने के 2 दिन बाद प्रकाशित किया गया ताकि पहले अधिकतम समस्याएँ समेटी जा सकें
- इस बीच 12 से अधिक नए releases deploy कर तेज़ iteration किया गया
- terms और privacy policy जैसे छोटे बदलावों में भी बहुत समय लगा
- data processing के छोटे updates और stealer logs जैसी नई services को reflect करना ज़रूरी था
- वकीलों के साथ काम करने में कई घंटे और हजारों dollars खर्च हुए
- Cloudflare Turnstile, Google reCAPTCHA की तरह traffic को Google को भेजे बिना anti-automation प्रदान करता है
- इसे पूरी तरह invisible रूप में implement किया जा सकता है
- browser में Cloudflare script challenge बनाती है, जो HTTP request के साथ submit होता है और फिर server side पर verify किया जाता है
- HIBP में यह 2023 से किसी न किसी रूप में लागू था
- email भेजने वाले forms जैसी जगहों पर, जहाँ bot blocking महत्वपूर्ण है, Turnstile failure होने पर users को दोबारा कोशिश करने या page refresh करने का निर्देश दिखाया जाता है
- दूसरा click या page reload अक्सर समस्या हल कर देता था
- यदि समस्या बनी रहे, तो user interaction मांगने वाला अधिक visible Turnstile widget लागू करने पर विचार करना होगा
- मुख्य search page में भी Turnstile महत्वपूर्ण रूप से उपयोग होता है
- यह async तरीके से API endpoint को request भेजता है और challenge token साथ भेजता है
- challenge fail होने पर HIBP endpoint HTTP 401 और
Invalid Turnstile tokenलौटाता था, तब full page post पर fallback करना पड़ता था - नई साइट के शुरुआती launch पर यह fallback काम नहीं कर रहा था, लेकिन बाद में इसे ठीक किया गया
- full page post में Cloudflare managed challenge दिखता है, जो अधिक intrusive है लेकिन अधिक reliable भी है
- Cloudflare stats के अनुसार जारी किए गए challenges में से लगभग 82% सफलतापूर्वक solve हुए
- जो 18% solve नहीं हुए, उनमें से बड़ी संख्या शायद वे bots हों जिन्हें Turnstile ने इरादतन रोका
- वास्तविक इंसानी requests जो block हुईं, उनका अनुपात शायद single digits में हो, और इसे और कम करने के तरीके देखते रहने की बात कही गई है
अभी कोई टिप्पणी नहीं है.