2 अरब ईमेल पते लीक हुए, और उन सभी को Have I Been Pwned में index किया गया

 (troyhunt.com)
3 पॉइंट द्वारा GN⁺ 2025-11-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • कुल 1 अरब 95 करोड़ 7,47 लाख अद्वितीय ईमेल पते और 1.3 अरब पासवर्ड वाला एक विशाल डेटा सेट सार्वजनिक हुआ है, जिसे Have I Been Pwned(HIBP) में नया जोड़ा गया है
  • इनमें से 62.5 करोड़ पासवर्ड पहले कभी नहीं मिले थे, और यह HIBP द्वारा प्रोसेस किए गए डेटा में अब तक का सबसे बड़ा सेट है
  • यह डेटा Synthient के threat intelligence platform से जुटाए गए credential stuffing डेटा से आया है, जिसमें कई breaches से लीक हुए email-password combinations शामिल हैं
  • डेटा की प्रामाणिकता जांचने के लिए HIBP ने subscribers से सीधे पुष्टि मांगी, और कुछ में अब भी वास्तविक उपयोग में मौजूद पासवर्ड शामिल थे
  • यह index Gmail leak नहीं, बल्कि malware infection के शिकार लोगों से जुटाए गए credentials का परिणाम है; उपयोगकर्ता HIBP या Pwned Passwords के जरिए अपना exposure जांच सकते हैं

डेटा का अवलोकन

  • डेटा सेट में 1,95,74,76,021 अद्वितीय ईमेल पते और 1.3 अरब पासवर्ड शामिल हैं
    • इनमें 62.5 करोड़ पासवर्ड ऐसे थे जो HIBP में पहली बार मिले
    • यह HIBP द्वारा अब तक संभाले गए डेटा में सबसे बड़ा है, और पिछले सबसे बड़े leak से लगभग 3 गुना बड़ा है
  • यह डेटा Synthient द्वारा एकत्र किए गए threat intelligence डेटा का हिस्सा है, जिसमें credential stuffing lists शामिल हैं
    • credential stuffing डेटा कई breaches से लीक हुए email-password combinations के दोबारा उपयोग से बनता है
    • कई sites पर एक ही password इस्तेमाल करने की आदत के कारण, एक बार का leak दूसरे services के accounts compromise होने तक पहुंच सकता है

डेटा सत्यापन प्रक्रिया

  • सत्यापन की शुरुआत लेखक के व्यक्तिगत ईमेल पते से हुई, और कुछ पुराने passwords वास्तव में मेल खाते थे
    • दूसरे passwords अपरिचित थे, और कुछ में IP address जैसे असामान्य values भी शामिल थे
  • HIBP subscribers से भी सत्यापन के लिए कहा गया और कई उदाहरण जुटाए गए
    • एक उपयोगकर्ता के मामले में पुराना password और हाल का password दोनों शामिल थे, जिसके बाद उसने तुरंत बदलाव किया
    • एक अन्य उपयोगकर्ता के 10~20 साल पहले इस्तेमाल किए गए passwords भी शामिल थे
    • कुछ उत्तरदाताओं के अब भी सक्रिय accounts में उपयोग हो रहे passwords भी उजागर हुए
  • सत्यापन के परिणाम से पता चला कि डेटा में पुरानी जानकारी और अभी उपयोग में मौजूद passwords का मिश्रण है
    • कुछ entries auto-generated passwords थीं, या इतनी पुरानी कि लोग उन्हें पहचान नहीं पाए

Pwned Passwords search सुविधा

  • HIBP की Pwned Passwords सेवा ईमेल पते और passwords को अलग-अलग स्टोर करती है
    • यह security और privacy के लिए किया गया उपाय है, ताकि email-password pair के उजागर होने का जोखिम न बने
  • उपयोगकर्ता निम्न तरीकों से password exposure जांच सकते हैं
    1. Pwned Passwords search page का उपयोग
    2. k-anonymity API के जरिए code-based lookup
    3. 1Password Watchtower फीचर के जरिए automatic जांच
  • सभी 4-digit PIN combinations पहले ही लीक हो चुके हैं, और HIBP डेटा पर आधारित PIN usage pattern visualization भी उपलब्ध है

Gmail leak नहीं

  • यह घटना Gmail security vulnerability से असंबंधित है; यह malware infection के जरिए इकट्ठा किए गए victim credentials का डेटा है
  • पूरे डेटा में 3.2 करोड़ email domains शामिल हैं, जिनमें gmail.com के 39.4 करोड़ हैं
    • Gmail addresses कुल का लगभग 20% ही हैं, जबकि बाकी 80% दूसरे domains से हैं
    • इसका Google की किसी security flaw से संबंध नहीं है

तकनीकी प्रोसेसिंग

  • यह डेटा पिछले सबसे बड़े leak से लगभग 3 गुना बड़ा था, इसलिए processing काफी जटिल रही
    • HIBP ने Azure SQL Hyperscale(80-core) environment में लगभग 2 हफ्तों तक डेटा प्रोसेस किया
    • ईमेल पतों के SHA1 hash generation के दौरान large-scale updates फेल हो गए, इसलिए 10 लाख records के batch processing पर स्विच किया गया
  • 59 लाख subscribers में से 29 लाख इस डेटा में शामिल थे
    • bulk email भेजते समय spam filtering और server limits से बचने के लिए gradual sending strategy अपनाई गई
    • प्रति घंटे 1.015x की दर से भेजने की मात्रा बढ़ाई गई, जो प्रतिदिन लगभग 45% की वृद्धि के बराबर थी
    • DKIM, DMARC, SPF configuration और dedicated IP के उपयोग से trust बनाए रखा गया
  • Pwned Passwords API response size औसतन 26KB से बढ़कर 40KB हो गया
    • ऐसा hash range size लगभग 50% बढ़ने के कारण हुआ, और brotli compression से efficiency बनाए रखी गई

निष्कर्ष और सुझाए गए कदम

  • इस डेटा को HIBP में “Synthient Credential Stuffing Threat Data” नाम से खोजा जा सकता है
    • यह पहले के Synthient डेटा से अलग data set है, हालांकि कुछ overlap मौजूद है
  • HIBP ने डेटा की integrity verify की है और privacy-focused search functionality उपलब्ध कराई है
  • उपयोगकर्ताओं के लिए सुझाए गए security steps
    • password manager का उपयोग
    • मजबूत और unique passwords बनाना
    • passkey का उपयोग और multi-factor authentication(MFA) सक्षम करना
  • HIBP ने कहा कि यह काम बहुत समय और लागत वाला project था, और उपयोगकर्ताओं से डेटा access request करने के बजाय अपनी security habits बेहतर करने पर ध्यान देने का आग्रह किया

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

1 टिप्पणियां

 
GN⁺ 2025-11-07
Hacker News टिप्पणियाँ

  • अब तक बहुत सारे डेटा लीक हो चुके हैं। मेरा पता, SSN, फोन नंबर, ईमेल वगैरह सब कई बार उजागर हो चुके लगते हैं
    मुझे यूनिवर्सिटी, जॉब साइट्स, सोशल मीडिया वगैरह से लीक नोटिफिकेशन मिले हैं, और इसके अलावा भी वैध big data analysis के जरिए मेरी जानकारी घूम रही होगी
    अब मैं Bitwarden में मजबूत पासवर्ड सेव करके मैनेज करता हूँ, लेकिन पहले इस्तेमाल किए गए पुराने अकाउंट्स अब भी जोखिम में लगते हैं
    सच कहूँ तो अब समझ नहीं आता कि मैं क्या कर सकता हूँ। अफसोस यही है कि मेरी जानकारी पहले ही बाहर जा चुकी है

    • मैं हर अकाउंट के लिए अलग ईमेल alias और password manager इस्तेमाल करता हूँ
      फुर्सत में पुराने अकाउंट्स साफ कर रहा हूँ। इससे स्पैम या लीक का स्रोत ईमेल पते से तुरंत पता चल जाता है
      Sieve filtering का इस्तेमाल करें तो और भी बारीक वर्गीकरण संभव है। envelope to और header to को साथ में इस्तेमाल करें तो BCC या alias मेल भी सही तरह फ़िल्टर हो जाते हैं
      संबंधित दस्तावेज़: RFC5228 Sieve Filtering
      पहले कभी पुराने स्पैम मेल में मेरा पुराना पासवर्ड शामिल होने की वजह से मैं भूला हुआ अकाउंट भी वापस पा सका था
    • Bitwarden सच में बेहतरीन है। मैं निजी तौर पर आसपास के लोगों को इसकी सिफारिश कर रहा हूँ, लेकिन प्रतिक्रिया बहुत कम है
      मेरी पत्नी कहती है कि ऑनलाइन जानकारी की सुरक्षा तो हारी हुई लड़ाई है। शायद वह सही कहती है
    • पते ज्यादातर public records होते हैं। fastpeoplesearch.com जैसी साइट पर खोजो तो तुरंत मिल जाते हैं
      फोन नंबर भी पहले टेलीफोन डायरेक्टरी में होते थे। अब भी यह सार्वजनिक जानकारी जैसा ही लगता है
    • मेरी भी ऐसी ही स्थिति है। अमेरिका की तीनों बड़ी क्रेडिट एजेंसियों में credit freeze लगाना ज़रूरी है
      पहले किसी ने मेरी जानकारी से cable TV कनेक्शन खुलवा लिया था, और उसे क्रेडिट रिकॉर्ड से हटवाने में बहुत परेशानी हुई
    • मैं सैन्य सेवा में था, और चीन ने मेरी DNA profile तक चुरा ली। अब तो मैंने बस मान लिया है

  • लगता है Troy अब DB space काफी बचा पाएगा
    बस

    def email_compromised(email):
    return True

    इतना कर देने भर से काम चल जाए, ऐसा लगता है जैसे हर ईमेल लीक हो चुका है

    • ज़रूरी नहीं। मेरे दो मुख्य ईमेल अभी भी साफ दिखते हैं
      हाँ, बाकी इधर-उधर के काम वाले ईमेल 9 बार तक लीक में आए हैं

  • लगता है इस डेटा में Spotify का अप्रकाशित लीक डेटा शामिल है
    2020 की शुरुआत में मेरे कमजोर पासवर्ड वाले Spotify अकाउंट में एक अमेरिकी IP से लॉगिन हुआ था
    कुछ घंटों बाद Spotify ने अपने-आप password reset भेजा, लेकिन कोई आधिकारिक लीक नोटिस नहीं था
    अब जाकर वह ईमेल HIBP में दिख रहा है

    • Spotify जैसी बड़ी कंपनी को ऐसे लीक की औपचारिक रिपोर्ट देनी चाहिए थी

  • मैं Troy Hunt के काम का सम्मान करता हूँ, लेकिन Have I Been Pwned पर अपना ईमेल खोजने के बाद व्यावहारिक रूप से क्या करना है, यह स्पष्ट नहीं होता
    साइट बस यही कहती है कि “जोखिम है, इसलिए पासवर्ड अच्छी तरह मैनेज करें”
    500 से ज़्यादा पासवर्ड बदलना व्यवहारिक नहीं है। आखिरकार Bitwarden, 1Password, Chrome जैसे password managers पर निर्भर होना पड़ता है

    • हर साइट के लिए random unique password इस्तेमाल करना चाहिए
      मैंने भी पहले वही पासवर्ड दोबारा इस्तेमाल किया था, और फिर मेरे सारे अकाउंट्स हैक हो गए थे
      अब मैं सिर्फ password manager का master password, Gmail, और disk encryption का पासवर्ड याद रखता हूँ, बाकी सब manager जनरेट करता है
      जहाँ संभव हो वहाँ 2FA(U2F/WebAuthn) भी चालू करता हूँ
    • सही बात है। आखिरकार password manager ही सबसे अहम है
    • HIBP Passwords पेज पर आप पासवर्ड सीधे डालकर सुरक्षित तरीके से देख सकते हैं कि वह लीक हुआ है या नहीं
      1Password भी इसी तरीके से काम करता है, और अकाउंट नाम सेव नहीं करता, इसलिए नया लीक जोखिम नहीं बनता
    • यह डेटा सेट कई लीक को जोड़कर बनाया गया aggregate data है, इसलिए स्रोत पता नहीं चल सकता
    • पहले कभी HIBP अलर्ट मिलने पर मैंने यूज़र पासवर्ड तुरंत reset किए थे
      लेकिन ज़्यादातर पासवर्ड पहले के पुराने लीक से आए हुए थे, इसलिए अब मैं गैरज़रूरी कार्रवाई से बचना चाहता हूँ

  • कई custom email addresses इस्तेमाल करने की वजह से HIBP में जाँच करने के लिए paid subscription चाहिए
    मैं सैकड़ों ईमेल चला रहा हूँ, इसलिए यह असुविधाजनक है। फिर भी हर साइट के लिए अलग पता इस्तेमाल करना अब भी फायदेमंद है

    • पहले domain search feature मुफ़्त था। मैंने 2017 में रजिस्टर किया था, और 2020 व 2022 में लीक अलर्ट मिले थे
    • सच तो यह है कि alias ईमेल इस्तेमाल करें तो लीक होने पर उसी समय पता चल जाता है। सिर्फ ईमेल से identity theft करना आसान नहीं होता
    • मेरी भी यही स्थिति है। मैं password manager में सभी ईमेल ट्रैक करता हूँ, लेकिन HIBP में एक-एक करके चेक करना झंझट है
    • वास्तविकता यही है कि मान लेना चाहिए कि सभी ईमेल पहले ही उजागर हो चुके हैं। ईमेल कोई रहस्य नहीं है
    • आखिरकार पासवर्ड ही असली रहस्य है। मजबूत पासवर्ड बनाए रखें तो ठीक है

  • पहले Facebook लीक में मेरा पुराना ईमेल उजागर हुआ था, और बाद में किसी और ने उस domain को फिर से रजिस्टर करके account takeover की कोशिश की
    अच्छी बात यह रही कि 2FA और Facebook के security alert की वजह से उसे रोका जा सका
    जो ईमेल पते अब इस्तेमाल नहीं होते, उन्हें अकाउंट से ज़रूर हटा देना चाहिए

    • अगर व्यक्तिगत domain को ईमेल के लिए इस्तेमाल करते हैं, तो आजीवन maintenance cost रहती है। domain छूट गया तो कोई और उसे खरीदकर account recovery की कोशिश कर सकता है
      iCloud या Gmail में custom domain को आसानी से जोड़ने की सुविधा आने के बाद यह जोखिम और बढ़ गया है
    • सिर्फ एक अकाउंट को निशाना बनाने के लिए कोई इतना आगे जाएगा, यह हैरान करता है
    • यह और भी अजीब है कि उस व्यक्ति ने पैसे देकर domain खरीदा और कोशिश की। मैं कोई मशहूर आदमी भी नहीं हूँ

  • यह हिस्सा दिलचस्प था कि Azure SQL Hyperscale को 80 cores पर 2 हफ्ते तक चलाया गया
    सिर्फ ईमेल और पासवर्ड मैनेज करने के लिए SQL कुछ overkill जैसा लगता है।
    15 अरब रिकॉर्ड भी हों तो 600GB के आसपास हो सकता है, जो किसी सामान्य सर्वर पर भी संभल जाए

    • असली समस्या 1.9 अरब SHA1 hash updates थी
      in-place update धीमे थे, इसलिए अलग टेबल बनाई गई, और ईमेल नोटिफिकेशन भेजते समय mail provider limits में भी अटकना पड़ा
    • मेरा भी यही विचार है। लगता है Troy ने Microsoft के साथ अपने रिश्ते की वजह से Azure चुना
      “Microsoft Regional Director and MVP” जैसा टाइटल थोड़ा उलझन पैदा करता है
    • Azure SQL निश्चित रूप से गलत विकल्प है। अगर सिर्फ hash lookup करना है, तो binary file based structure कहीं ज़्यादा कुशल है
      SHA1 hash को sort करके 20GB की फ़ाइल बनाई जा सकती है, और binary search या hash distribution आधारित index से एक I/O lookup में काम हो सकता है
      इसे 65,536 chunks में बाँटकर sort करें तो memory समस्या भी हल हो जाती है
      ऐसी संरचना को Blob Storage पर Azure SQL की तुलना में लगभग 50 गुना सस्ता चलाया जा सकता है

  • लगता है HIBP डेटा में expiry point होता है। पहले Dropbox लीक में मेरा ईमेल शामिल था, लेकिन अब वह रिकॉर्ड गायब है
    Dropbox breach page

  • सोच रहा हूँ Bitwarden / 1Password / Proton Pass में कौन बेहतर है
    Proton Pass पर अभी पूरी तरह भरोसा करना जल्दी होगा, और “सब कुछ एक ही टोकरी में मत रखो” वाली बात भी याद आती है
    मैंने open source होने की वजह से Bitwarden चुना है, क्योंकि उम्मीद है कि इसका free user base बड़ा होने से समस्याएँ जल्दी सामने आएँगी और हल भी होंगी

    • मैं 1Password इस्तेमाल करता हूँ, और उसका UI और enterprise management features कहीं ज़्यादा सुविधाजनक हैं
      business account लेने पर family account मुफ़्त मिलना भी एक फायदा है
      लेकिन Bitwarden की open source philosophy भी पूरी तरह विचार करने लायक है

  • इस लेख का शीर्षक “1.3 अरब पासवर्ड लीक हुए” होता तो शायद ज़्यादा सटीक रहता
    संख्या थोड़ी छोटी है, लेकिन अर्थ कहीं ज़्यादा बड़ा है

    • असल पासवर्ड की संख्या शायद इससे भी कम होगी 😉