3 คะแนน โดย GN⁺ 2025-11-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการเปิดเผยชุดข้อมูลขนาดใหญ่ที่ประกอบด้วย ที่อยู่อีเมลไม่ซ้ำกัน 1,957,476,021 รายการ และ รหัสผ่าน 1.3 พันล้านรายการ และถูกเพิ่มเข้าไปใน Have I Been Pwned(HIBP) ใหม่
  • ในจำนวนนี้ รหัสผ่าน 625 ล้านรายการไม่เคยถูกพบมาก่อนเลย ซึ่งนับเป็นข้อมูลขนาดใหญ่ที่สุดที่ HIBP เคยประมวลผล
  • ข้อมูลนี้รวบรวมมาจาก แพลตฟอร์มข่าวกรองภัยคุกคามของ Synthient เป็นข้อมูล credential stuffing ที่มีคู่ผสมอีเมลและรหัสผ่านจากการรั่วไหลหลายเหตุการณ์
  • HIBP ตรวจสอบความถูกต้องของข้อมูลโดยขอให้สมาชิกช่วยยืนยันโดยตรง และพบว่าบางส่วนยังคงมี รหัสผ่านที่ถูกใช้งานจริงอยู่
  • การจัดทำดัชนีครั้งนี้ ไม่ใช่การรั่วไหลของ Gmail แต่เป็นผลจากการรวบรวมข้อมูลรับรองของเหยื่อที่ติดมัลแวร์ และผู้ใช้สามารถตรวจสอบการเปิดเผยได้ผ่าน HIBP หรือ Pwned Passwords

ภาพรวมของข้อมูล

  • ชุดข้อมูลนี้มี ที่อยู่อีเมลไม่ซ้ำกัน 1,957,476,021 รายการ และ รหัสผ่าน 1.3 พันล้านรายการ
    • ในจำนวนนั้น รหัสผ่าน 625 ล้านรายการเป็นรายการที่ HIBP พบเป็นครั้งแรก
    • เป็นข้อมูล ขนาดใหญ่ที่สุด ที่ HIBP เคยประมวลผล ใหญ่กว่าการรั่วไหลครั้งก่อนหน้าสูงสุดราว 3 เท่า
  • ข้อมูลนี้เป็นส่วนหนึ่งของข่าวกรองภัยคุกคามที่ Synthient รวบรวมไว้ และมี รายการ credential stuffing รวมอยู่ด้วย
    • ข้อมูล credential stuffing เกิดจากการนำคู่ผสมอีเมลและรหัสผ่านที่รั่วไหลจากหลายเหตุการณ์กลับมาใช้ซ้ำ
    • เนื่องจากมีพฤติกรรมใช้รหัสผ่านเดียวกันในหลายเว็บไซต์ การรั่วไหลเพียงครั้งเดียวจึงอาจนำไปสู่การยึดบัญชีในบริการอื่นได้

กระบวนการตรวจสอบข้อมูล

  • การตรวจสอบเริ่มจาก ที่อยู่อีเมลส่วนตัว ของผู้เขียน และพบว่ารหัสผ่านเก่าบางส่วนตรงกันจริง
    • ส่วนรหัสผ่านอื่น ๆ ไม่คุ้นเคย และบางรายการมีค่าผิดปกติ เช่น อยู่ในรูปแบบที่อยู่ IP
  • มีการขอให้สมาชิก HIBP ช่วยตรวจสอบด้วยเพื่อรวบรวมหลายกรณี
    • ผู้ใช้รายหนึ่งพบทั้งรหัสผ่านเก่าและรหัสผ่านล่าสุดอยู่ในข้อมูล และดำเนินการเปลี่ยนทันที
    • ผู้ใช้อีกรายพบว่ามีรหัสผ่านที่เคยใช้เมื่อ 10~20 ปีก่อนรวมอยู่ด้วย
    • ผู้ตอบกลับบางรายยังพบว่ามี รหัสผ่านที่ยังใช้อยู่กับบัญชีที่ยังแอ็กทีฟ ถูกเปิดเผย
  • ผลการตรวจสอบชี้ว่าข้อมูลชุดนี้มีทั้ง ข้อมูลเก่าและรหัสผ่านที่ยังถูกใช้งานจริงปะปนกันอยู่
    • บางรายการอาจเป็นรหัสผ่านที่สร้างอัตโนมัติ หรือเก่ามากจนจำไม่ได้แล้ว

ฟังก์ชันค้นหา Pwned Passwords

  • บริการ Pwned Passwords ของ HIBP จัดเก็บที่อยู่อีเมลและรหัสผ่านแยกจากกัน
    • นี่เป็นมาตรการด้านความปลอดภัยและความเป็นส่วนตัว เพื่อป้องกันความเสี่ยงจากการเปิดเผยคู่ข้อมูลอีเมล-รหัสผ่าน
  • ผู้ใช้สามารถตรวจสอบได้ว่ารหัสผ่านถูกเปิดเผยหรือไม่ด้วยวิธีต่อไปนี้
    1. ใช้ หน้าค้นหา Pwned Passwords
    2. ค้นหาผ่านโค้ดด้วย k-anonymity API
    3. ตรวจสอบอัตโนมัติผ่านฟีเจอร์ 1Password Watchtower
  • ชุดค่าผสม PIN 4 หลักทั้งหมดเคยรั่วไหลแล้ว และยังมี สื่อภาพแสดงรูปแบบการใช้งาน PIN ที่อ้างอิงจากข้อมูลของ HIBP ด้วย

ไม่ใช่การรั่วไหลของ Gmail

  • เหตุการณ์นี้ ไม่เกี่ยวข้องกับช่องโหว่ด้านความปลอดภัยของ Gmail แต่เป็นข้อมูลรับรองของเหยื่อที่ถูกรวบรวมจากการติดมัลแวร์
  • ในข้อมูลทั้งหมดมี โดเมนอีเมล 32 ล้านโดเมน โดยในนั้น gmail.com มี 394 ล้านรายการ
    • ที่อยู่ Gmail คิดเป็นเพียงราว 20% ของทั้งหมด ส่วนอีก 80% อยู่ในโดเมนอื่น
    • ไม่เกี่ยวข้องกับข้อบกพร่องด้านความปลอดภัยของ Google

กระบวนการประมวลผลทางเทคนิค

  • ข้อมูลชุดนี้มีขนาดประมาณ ใหญ่กว่า 3 เท่า ของการรั่วไหลครั้งก่อนหน้าที่ใหญ่ที่สุด ทำให้กระบวนการประมวลผลซับซ้อนมาก
    • HIBP ประมวลผลข้อมูลในสภาพแวดล้อม Azure SQL Hyperscale(80 คอร์) เป็นเวลาประมาณ 2 สัปดาห์
    • ระหว่างการสร้าง แฮช SHA1 ของที่อยู่อีเมล การอัปเดตจำนวนมากล้มเหลว จึงเปลี่ยนเป็น ประมวลผลแบบแบตช์ละ 1 ล้านรายการ
  • ในสมาชิกทั้งหมด 5.9 ล้านคน มี 2.9 ล้านคน ที่อยู่ในข้อมูลชุดนี้
    • เพื่อหลีกเลี่ยงการกรองสแปมและข้อจำกัดของเซิร์ฟเวอร์ระหว่างการส่งอีเมลจำนวนมาก จึงใช้ กลยุทธ์การส่งแบบค่อยเป็นค่อยไป
    • ปรับปริมาณการส่งด้วยอัตราเพิ่มขึ้น 1.015 เท่าต่อชั่วโมง หรือเพิ่มราว 45% ต่อวัน
    • รักษาความน่าเชื่อถือด้วยการตั้งค่า DKIM, DMARC, SPF และใช้ IP เฉพาะ
  • ขนาดการตอบกลับของ Pwned Passwords API เพิ่มจากค่าเฉลี่ย 26KB เป็น 40KB
    • เป็นผลจากขนาดของช่วงแฮชที่ใหญ่ขึ้นราว 50% และยังคงประสิทธิภาพไว้ด้วยการบีบอัดแบบ brotli

บทสรุปและคำแนะนำ

  • ข้อมูลชุดนี้สามารถค้นหาได้ใน HIBP ภายใต้ชื่อ “Synthient Credential Stuffing Threat Data”
    • เป็นชุดข้อมูลแยกจากข้อมูล Synthient ก่อนหน้า แม้จะมีบางส่วนซ้ำกัน
  • HIBP ระบุว่าได้ตรวจสอบความสมบูรณ์ของข้อมูล และให้บริการค้นหาที่เน้น การคุ้มครองความเป็นส่วนตัว
  • มาตรการด้านความปลอดภัยที่แนะนำสำหรับผู้ใช้
    • ใช้ตัวจัดการรหัสผ่าน
    • สร้างรหัสผ่านที่แข็งแรงและไม่ซ้ำกัน
    • ใช้ passkey และเปิดใช้งานการยืนยันตัวตนหลายปัจจัย(MFA)
  • HIBP ระบุว่างานครั้งนี้เป็น โครงการที่ใช้ทั้งเวลาและค่าใช้จ่ายสูงมาก และขอให้ผู้ใช้มุ่งเน้นที่ การปรับปรุงพฤติกรรมด้านความปลอดภัย แทนการร้องขอเข้าถึงข้อมูล

1 ความคิดเห็น

 
GN⁺ 2025-11-07
ความเห็นบน Hacker News
  • จนถึงตอนนี้มี ข้อมูลรั่วไหล มากเกินไปแล้ว ดูเหมือนว่าที่อยู่, SSN, หมายเลขโทรศัพท์, อีเมล และข้อมูลทุกอย่างของฉันจะถูกเปิดเผยไปหลายรอบ
    ฉันได้รับการแจ้งเตือนเรื่องข้อมูลรั่วจากมหาวิทยาลัย, เว็บไซต์หางาน, โซเชียลมีเดีย และนอกจากนั้นข้อมูลของฉันก็คงถูกหมุนเวียนอยู่ผ่าน การวิเคราะห์บิ๊กดาต้า ที่ถูกกฎหมายด้วย
    ตอนนี้ฉันเก็บและจัดการรหัสผ่านที่แข็งแรงไว้ใน Bitwarden แล้ว แต่ก็คงยังมีบัญชีเก่าๆ ที่เคยใช้ซึ่งยังเสี่ยงอยู่
    พูดตรงๆ ตอนนี้ก็ไม่รู้ว่าจะทำอะไรได้บ้างแล้ว น่าเสียดายที่ข้อมูลของฉันออกไปอยู่ข้างนอกหมดแล้ว

    • ฉันใช้อีเมลนามแฝงและตัวจัดการรหัสผ่านคนละชุดสำหรับแต่ละบัญชี
      ช่วงเวลาว่างก็กำลังทยอยเก็บกวาดบัญชีเก่าๆ อยู่ วิธีนี้ช่วยให้รู้ได้ทันทีจากอีเมลว่าต้นตอของสแปมหรือการรั่วมาจากไหน
      ถ้าใช้ Sieve filtering จะจัดหมวดหมู่ได้ละเอียดกว่านี้มาก และถ้าใช้ envelope to กับ header to ร่วมกัน ก็กรองเมล BCC หรือเมลนามแฝงได้แม่นยำ
      เอกสารที่เกี่ยวข้อง: RFC5228 Sieve Filtering
      เมื่อก่อนฉันเคยได้กู้คืนบัญชีที่ลืมไปแล้ว เพราะมีอีเมลสแปมที่ใส่รหัสผ่านเก่าของฉันมาด้วย
    • Bitwarden ดีจริงๆ ฉันแนะนำคนรอบตัวอยู่ตลอด แต่กระแสตอบรับค่อนข้างเงียบ
      ภรรยาฉันบอกว่าการปกป้องข้อมูลออนไลน์เป็น สงครามที่แพ้ไปแล้ว ซึ่งบางทีเธอก็อาจพูดถูก
    • ที่อยู่ส่วนใหญ่เป็น ข้อมูลสาธารณะ อยู่แล้ว ค้นหาในเว็บอย่าง fastpeoplesearch.com ก็เจอทันที
      หมายเลขโทรศัพท์ก็เมื่อก่อนอยู่ในสมุดหน้าเหลืองกันหมด มันยังให้ความรู้สึกว่าเป็นข้อมูลสาธารณะอยู่ดี
    • ฉันก็อยู่ในสถานการณ์คล้ายกัน สิ่งสำคัญคือการ อายัดเครดิต กับบริษัทจัดอันดับเครดิตใหญ่ 3 แห่งของสหรัฐ
      เมื่อก่อนเคยมีคนเอาข้อมูลของฉันไปเปิดบริการเคเบิลทีวี ทำเอาต้องลำบากกว่าจะลบออกจากประวัติเครดิตได้
    • ตอนรับราชการทหารอยู่ จีนถึงขั้นขโมย โปรไฟล์ DNA ของฉันไปด้วย ตอนนี้เลยปลงแล้ว
  • ดูเหมือนว่า Troy น่าจะประหยัดพื้นที่ DB ได้มากขึ้นแล้ว
    แค่ทำแบบนี้

    def email_compromised(email):
        return True
    

    ก็พอแล้ว เพราะให้ความรู้สึกว่าอีเมลทุกอันโดนเจาะหมดแล้ว

    • ก็ไม่ถึงขนาดนั้น อีเมลหลักสองอันของฉันยังสะอาดอยู่
      แต่อีเมลที่ใช้จุกจิกกลับมีประวัติรั่วถึง 9 ครั้ง
  • ดูเหมือนว่าข้อมูลชุดนี้จะมี ข้อมูลรั่วที่ยังไม่เปิดเผยของ Spotify รวมอยู่ด้วย
    ต้นปี 2020 บัญชี Spotify ของฉันที่ใช้รหัสผ่านอ่อนแอเคยถูกล็อกอินจาก IP ในสหรัฐ
    ไม่กี่ชั่วโมงต่อมา Spotify ก็ส่งรีเซ็ตรหัสผ่านอัตโนมัติมาให้ แต่ไม่เคยมีการแจ้งข้อมูลรั่วอย่างเป็นทางการ
    ตอนนี้อีเมลนั้นเพิ่งมาโผล่ใน HIBP

    • ถ้าเป็นบริษัทใหญ่ระดับ Spotify ก็ควรจะ รายงานอย่างเป็นทางการ เรื่องการรั่วไหลแบบนี้
  • ฉันเคารพงานของ Troy Hunt แต่ต่อให้ค้นหาอีเมลของตัวเองใน Have I Been Pwned ก็ไม่มี วิธีลงมือทำที่เป็นรูปธรรม อะไรนัก
    ในเว็บมีแค่ข้อความประมาณว่า “คุณเสี่ยงแล้ว จัดการรหัสผ่านให้ดี”
    การจะเปลี่ยนรหัสผ่านมากกว่า 500 อันทั้งหมดเป็นเรื่องที่เป็นไปไม่ได้ในทางปฏิบัติ สุดท้ายก็ต้องพึ่ง ตัวจัดการรหัสผ่าน อย่าง Bitwarden, 1Password, Chrome อยู่ดี

    • แต่ละเว็บควรใช้ รหัสผ่านสุ่มที่ไม่ซ้ำกัน
      ฉันเองเมื่อก่อนก็เคยใช้รหัสผ่านซ้ำ แล้วสุดท้ายบัญชีทั้งหมดก็โดนเจาะ
      ตอนนี้ฉันจำแค่รหัสผ่านมาสเตอร์ของตัวจัดการรหัสผ่าน, Gmail และรหัสผ่านสำหรับการเข้ารหัสดิสก์ ส่วนที่เหลือให้ตัวจัดการสร้างทั้งหมด
      ที่ไหนเปิดได้ก็เปิด 2FA (U2F/WebAuthn) ด้วย
    • ใช่ สุดท้ายแล้วตัวจัดการรหัสผ่านคือหัวใจสำคัญ
    • ในหน้า HIBP Passwords สามารถป้อนรหัสผ่านเพื่อตรวจอย่างปลอดภัยได้โดยตรงว่ารั่วหรือไม่
      1Password ก็ใช้วิธีเดียวกัน และไม่ได้เก็บชื่อบัญชีไว้ จึงไม่สร้างความเสี่ยงจากการรั่วใหม่
    • ชุดข้อมูลนี้เป็นข้อมูลแบบรวมจากหลายการรั่ว ที่ถูกรวมเข้าด้วยกัน เลยไม่รู้ที่มาแน่ชัด
    • เมื่อก่อนฉันเคยได้รับการแจ้งเตือนจาก HIBP แล้วรีเซ็ตรหัสผ่านผู้ใช้ทันที
      แต่ส่วนใหญ่ก็เป็นรหัสผ่านที่มาจากข้อมูลรั่วเก่าอยู่แล้ว เลยพยายามหลีกเลี่ยงการดำเนินการที่ไม่จำเป็น
  • พอใช้งาน อีเมลแบบกำหนดเองหลายชุด จะตรวจใน HIBP ก็ต้องสมัครแบบเสียเงิน
    ฉันมีอีเมลอยู่หลายร้อยอันเลยค่อนข้างลำบาก แต่ถึงอย่างนั้นการใช้อีเมลแยกเฉพาะแต่ละเว็บก็ยังคุ้มค่าอยู่

    • เมื่อก่อน ฟีเจอร์ค้นหาโดเมน เคยใช้ฟรี ฉันลงทะเบียนไว้ตั้งแต่ปี 2017 แล้วได้รับการแจ้งข้อมูลรั่วในปี 2020 กับ 2022
    • จริงๆ แล้วถ้าใช้อีเมลนามแฝง พอมีข้อมูลรั่วก็จะรู้ได้ทันที และแค่อีเมลอย่างเดียวก็ยากจะเอาไป สวมรอยตัวตน ได้
    • ฉันก็เหมือนกัน ฉันติดตามอีเมลทั้งหมดไว้ในตัวจัดการรหัสผ่าน แต่การต้องเช็กใน HIBP ทีละอันมันยุ่งยาก
    • ตามความเป็นจริงคงต้องสมมติไว้ก่อนว่าอีเมลทุกอันถูกเปิดเผยแล้ว อีเมลไม่ใช่ความลับ
    • สุดท้ายแล้ว รหัสผ่านต่างหากที่เป็นความลับจริงๆ ถ้ายังรักษารหัสผ่านที่แข็งแรงไว้ได้ก็โอเค
  • เมื่อก่อนอีเมลเก่าของฉันหลุดจากข้อมูลรั่วของ Facebook แล้วมีคนไปจดโดเมนนั้นใหม่เพื่อ พยายามยึดบัญชี
    โชคดีที่ 2FA กับคำเตือนความปลอดภัยของ Facebook ช่วยกันไว้ได้
    ที่อยู่อีเมลที่เลิกใช้แล้วควรลบออกจากบัญชีให้หมด

    • ถ้าใช้อีเมลบนโดเมนส่วนตัว จะมี ค่าใช้จ่ายในการถือครองตลอดชีวิต ถ้าปล่อยโดเมนหลุด คนอื่นก็อาจซื้อไปเพื่อพยายามกู้บัญชีของคุณได้
      พอ iCloud กับ Gmail ทำให้เชื่อมต่อโดเมนแบบกำหนดเองได้ง่ายขึ้น ความเสี่ยงแบบนี้ก็ยิ่งมากขึ้น
    • น่าตกใจที่มีคนยอมทำถึงขนาดนั้นเพื่อเล่นงานแค่บัญชีเดียว
    • แปลกดีที่คนนั้นยอมเสียเงินซื้อโดเมนมาเพื่อลองทำ ทั้งที่ฉันก็ไม่ใช่คนดังอะไร
  • ตรงที่บอกว่าใช้ Azure SQL Hyperscale แบบ 80 คอร์อยู่ 2 สัปดาห์นี่น่าสนใจ
    แค่จัดการอีเมลกับรหัสผ่าน SQL ดูเหมือนจะเป็นตัวเลือกที่ เกินความจำเป็น
    ต่อให้มี 15 พันล้านรายการ ถ้าราว 600GB ก็น่าจะจัดการได้ด้วยเซิร์ฟเวอร์ทั่วไป

    • จริงๆ ปัญหาคือการอัปเดต แฮช SHA1 จำนวน 1.9 พันล้านรายการ
      การอัปเดตแบบ in-place ช้าเกินไป เลยต้องสร้างตารางแยก และตอนส่งอีเมลแจ้งเตือนก็ยังติด ข้อจำกัดของผู้ให้บริการอีเมล อีก
    • ฉันก็คิดเหมือนกัน ดูเหมือนว่า Troy จะใช้ Azure เพราะมีความสัมพันธ์กับ Microsoft
      ตำแหน่ง “Microsoft Regional Director and MVP” ทำให้ชวนสับสนอยู่เหมือนกัน
    • Azure SQL น่าจะเป็นตัวเลือกที่ผิดชัดเจน ถ้าเป็นแค่การค้นหาแฮช โครงสร้างแบบ ไฟล์ไบนารี จะมีประสิทธิภาพกว่ามาก
      สร้างไฟล์ขนาด 20GB ที่เรียงแฮช SHA1 ไว้ แล้วใช้ binary search หรือดัชนีตามการกระจายของแฮช ก็สามารถค้นหาได้ด้วย I/O เพียงครั้งเดียว
      ถ้าแบ่งเป็น 65,536 ชังก์แล้วเรียง ก็แก้ปัญหาเรื่องหน่วยความจำได้ด้วย
      โครงสร้างแบบนี้สามารถรันบน Blob Storage ได้ในต้นทุนที่ถูกกว่า Azure SQL ราว 50 เท่า
  • ดูเหมือนว่าข้อมูลใน HIBP จะมี วันหมดอายุ อยู่เหมือนกัน เมื่อก่อนอีเมลของฉันเคยอยู่ในข้อมูลรั่วของ Dropbox แต่ตอนนี้ระเบียนนั้นหายไปแล้ว
    หน้า Dropbox breach

  • สงสัยว่า Bitwarden / 1Password / Proton Pass อันไหนดีกว่ากัน
    Proton Pass ยังดูเร็วเกินไปที่จะเชื่อใจ และก็นึกถึงคำพูดที่ว่า “อย่าใส่ทุกอย่างไว้ในตะกร้าใบเดียว”
    ฉันเลือก Bitwarden ที่เป็นโอเพนซอร์ส เพราะหวังว่าฐานผู้ใช้ฟรีที่ใหญ่จะช่วยให้ปัญหาถูกค้นพบและแก้ไขได้เร็ว

    • ฉันใช้ 1Password อยู่ และ UI กับฟีเจอร์จัดการสำหรับองค์กร ใช้งานสะดวกกว่ามาก
      ถ้าใช้บัญชีธุรกิจ ก็ยังได้บัญชีครอบครัวฟรีด้วยซึ่งเป็นข้อดี
      แต่แนวคิดโอเพนซอร์สของ Bitwarden ก็เป็นสิ่งที่ควรนำมาพิจารณาอย่างจริงจังเหมือนกัน
  • ชื่อบทความนี้ ถ้าเป็น “รหัสผ่าน 1.3 พันล้านรายการรั่วไหล” น่าจะตรงกว่ามาก
    ตัวเลขอาจเล็กลงนิดหน่อย แต่ความหมายใหญ่กว่ามาก

    • จำนวนรหัสผ่านจริงน่าจะน้อยกว่านั้นอีก 😉