ช่องโหว่ใน Microsoft Authenticator ทำให้บัญชี MFA ถูกเขียนทับและผู้ใช้ถูกล็อกออก

 (csoonline.com)
2 คะแนน โดย GN⁺ 2024-08-18 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในช่วงที่การใช้งาน MFA เพิ่มขึ้น Microsoft Authenticator อาจล็อกผู้ใช้ออกได้ เพราะ บัญชี TOTP ใหม่ที่เพิ่มด้วย QR code ไปเขียนทับบัญชีเดิม
  • แกนหลักของการชนกันอยู่ที่การออกแบบที่ใช้เพียง label เพื่อแยกบัญชี ไม่ได้ใช้ issuer ร่วมกับ label เหมือน Google Authenticator, Okta และแอปอื่นๆ
  • การเขียนทับไม่ปรากฏให้เห็นทันที ผู้ใช้อาจเจอภาวะ เข้าถึงไม่ได้ ก็ต่อเมื่อพยายามเข้าบัญชีเดิมในอีกหลายสัปดาห์หรือหลายเดือนต่อมา
  • วิธีหลบเลี่ยงคือใช้แอปยืนยันตัวตนอื่น หรือ ป้อน Secret Key ด้วยตนเอง แต่สำหรับผู้ใช้ทั่วไปในสภาพแวดล้อมองค์กรแล้วไม่ค่อยใช้งานได้จริง
  • Microsoft ระบุว่าเป็นพฤติกรรมตามที่ตั้งใจไว้และมีข้อความเตือนให้แล้ว ต่อมาชี้เหตุผลว่าผู้ออกบางรายไม่ได้ใส่ issuer เหลือไว้เพียงความเป็นไปได้ที่จะปรับปรุงในอนาคต

วิธีที่การสแกน QR เขียนทับบัญชี MFA เดิม

  • เมื่อเพิ่มบัญชีใหม่ด้วย การสแกน QR Microsoft Authenticator อาจเขียนทับบัญชีเดิมที่มีชื่อผู้ใช้เดียวกัน
  • ชื่อผู้ใช้มักใช้อีเมล จึงเป็นเรื่องปกติที่บัญชี MFA ของหลายบริการจะแชร์ label เดียวกัน
  • Google Authenticator และแอปยืนยันตัวตนอื่นๆ ส่วนใหญ่ใช้ ชื่อ issuer เช่น ธนาคารหรือบริษัทผลิตรถยนต์ร่วมด้วยเพื่อหลีกเลี่ยงการชนกัน
  • Microsoft Authenticator ไม่ได้ใช้ issuer ร่วมด้วย แต่ระบุบัญชีจากชื่อผู้ใช้เพียงอย่างเดียว
  • หลังจากถูกเขียนทับ อาจเกิดปัญหาการยืนยันตัวตนทั้งกับบัญชีที่สร้างใหม่และบัญชีเดิมที่ถูกเขียนทับ

การถูกล็อกที่ยากจะรู้สาเหตุ

  • เมื่อเกิดการล็อก ผู้ใช้อาจเข้าใจผิดว่าเป็นปัญหาของบริษัทที่ให้บริการยืนยันตัวตนมากกว่า Microsoft Authenticator
  • ผลคือ helpdesk ขององค์กรต้องเสียเวลาแก้สถานการณ์ที่ไม่ได้เกิดจากระบบของตนเอง
  • ยากที่จะตรวจสอบได้ง่ายๆ ว่าบัญชีใดถูกเขียนทับ
  • ข้อเท็จจริงที่ว่าบัญชีเดิมหายไปอาจไม่ปรากฏจนกว่าผู้ใช้จะพยายามใช้งานบัญชีนั้นอีกครั้ง
    • ช่วงเวลานี้อาจเป็นหลายสัปดาห์หรือหลายเดือนให้หลัง

วิธีหลบเลี่ยงและข้อร้องเรียนที่มีมานาน

  • วิธีหลบเลี่ยงที่ง่ายที่สุดคือใช้ แอปยืนยันตัวตนอื่น แทน Microsoft Authenticator
  • หากไม่ใช้การสแกน QR code แต่ป้อน Secret Key ด้วยตนเอง จะหลีกเลี่ยงปัญหาได้
  • ปัญหานี้ดูเหมือนไม่เกิดกับบัญชีการยืนยันตัวตนที่เป็นของบัญชี Microsoft
  • CSO Online ตรวจพบข้อร้องเรียนเกี่ยวกับปัญหานี้ย้อนไปถึงปี 2020 และดูเหมือนว่าปัญหานี้มีมาตั้งแต่ Microsoft Authenticator เปิดตัวในเดือนมิถุนายน 2016
  • ในปี 2020 ผู้ใช้รายหนึ่งกล่าวถึง วิธีหลบเลี่ยงด้วยการป้อน Secret Key ของ Identity Provider ด้วยตนเอง แต่เห็นว่าวิธีให้ผู้ใช้ปลายทางทั่วไปในองค์กรจัดการกับสตริงสุ่มนั้นไม่ช่วยมากนัก

การเขียนทับที่เกิดซ้ำได้ในภาคสนาม

  • Brett Randall ที่ปรึกษา IT ในออสเตรเลียพบสถานการณ์ที่ผู้เข้าร่วมในเซสชันอบรมของ vendor สแกน QR code สำหรับ MFA ด้วย Microsoft Authenticator แล้วไปเขียนทับ TOTP key ของแอปพลิเคชันอื่น
  • ตามคำอธิบายของ Randall, QR code สำหรับ MFA สร้างสตริงที่มีค่าหลายรายการ และแอปอื่นๆ จะนำ label กับ issuer มารวมกันเพื่อสร้าง ID เฉพาะของ key นั้น
  • Microsoft Authenticator ใช้เพียง label แทนพฤติกรรมมาตรฐานนี้ โดย label นั้นมักเป็นอีเมล
  • TOTP key ล่าสุดที่ใช้อีเมลเดียวกันอาจถูกเขียนทับด้วย key ใหม่
  • Randall กล่าวว่าการทำให้ Microsoft รับรู้และดำเนินการกับปัญหานี้แทบเป็นไปไม่ได้

ปฏิกิริยาจากผู้เชี่ยวชาญด้านความปลอดภัยและ IT

  • CSO Online ขอให้ผู้เชี่ยวชาญด้านความปลอดภัยและ IT หลายรายทดลองทำซ้ำปัญหา และทุกคนทำซ้ำได้สำเร็จ
  • Gary Longsine fractional CTO ของ IllumineX มองว่านี่เป็น ข้อบกพร่องในการออกแบบ และบอกว่าจะไม่แนะนำ Microsoft Authenticator
  • Tim Erlin รองประธานฝ่ายผลิตภัณฑ์ของ Wallarm กล่าวว่าเมื่อเพิ่มรายการที่สองซึ่งใช้อีเมลเดียวกัน จะเกิดการชนกัน และหลังจากเขียนทับแล้วจะไม่รู้ว่าบัญชีใดถูกเขียนทับ
  • Erlin ระบุว่าผู้ใช้อาจไม่รู้สาเหตุ จึงเป็นไปได้ว่าปัญหานี้เป็นที่รับรู้น้อยกว่าความเป็นจริง
  • David Meltzer chief product officer ของ Netography ทดลองทำซ้ำด้วยตนเองแล้วเห็นว่าเป็นบั๊กที่ชัดเจน และเป็นปัญหาที่ Microsoft น่าจะแก้ได้ค่อนข้างง่าย
  • Kimberly Samra โฆษกของ Google ตอบว่า Google Authenticator ไม่เขียนทับ code และนี่เป็นการตัดสินใจอย่างชัดเจน

จุดยืนของ Microsoft และข้อความเตือน

  • Microsoft ยืนยันปัญหานี้แล้ว แต่ระบุว่าไม่ใช่บั๊ก เป็น พฤติกรรมตามที่ตั้งใจไว้
  • ในคำชี้แจงเป็นลายลักษณ์อักษรครั้งแรก Microsoft อธิบายว่าเมื่อผู้ใช้สแกน QR code ผู้ใช้จะได้รับข้อความยืนยันก่อนดำเนินการที่อาจเขียนทับการตั้งค่าบัญชี
  • ข้อความเตือนจริงคือ “This action will overwrite existing security information for your account. To prevent being locked out of your account, continue only if you initiated this action from a trusted source.”
  • ข้อความนี้แนะนำให้ดำเนินการต่อหากผู้ใช้เป็นผู้เริ่มเองและมาจากแหล่งที่เชื่อถือได้
    • หากผู้ใช้เริ่มสแกน QR เองจากบริการปกติอย่างธนาคารหรือโรงแรม เงื่อนไขทั้งสองนี้มักจะเป็นจริง
    • หากดำเนินการตามคำแนะนำ อาจเกิดการเขียนทับบัญชีได้
  • หน้าต่างเตือนไม่มีวิธีหลีกเลี่ยงการเขียนทับ นอกจากล้มเลิกความพยายามยืนยันตัวตน

การโยนความรับผิดชอบเรื่อง issuer ที่หายไป

  • ต่อมาในคำชี้แจงครั้งที่สองที่ยาวขึ้น Microsoft อธิบายว่าบางเว็บไซต์หรือ vendor ไม่ได้ใส่ issuer ซึ่งก็คือชื่อเว็บไซต์หรือชื่อ Identity Provider ไว้ใน label
  • หากมีบัญชีเดิมที่มี label เดียวกัน แอปอาจพยายามเขียนทับบัญชีเดิมด้วยบัญชี TOTP ที่เพิ่งสแกนใหม่
  • Microsoft ระบุว่าในสถานการณ์เช่นนี้ ผู้ใช้จะได้รับข้อความยืนยันการเขียนทับเสมอ และสามารถเลือกได้ว่าจะดำเนินการต่อหรือไม่
  • ประโยคที่ว่า “เรายังคงปรับปรุงผลิตภัณฑ์ต่อไป และจะพิจารณาเรื่องนี้เพื่อนำไปใช้กับการปรับปรุงในอนาคต” เป็นส่วนเดียวที่บ่งชี้ว่า Microsoft อาจแก้ปัญหานี้

การเปรียบเทียบกับแอปยืนยันตัวตนอื่น

  • Randall มองว่ามีสองวิธีที่จะป้องกันไม่ให้ผู้ใช้ปลายทางเขียนทับ key ของแอปอื่นโดยไม่ได้ตั้งใจ
    • audit otpauth ของทุกแอปพลิเคชัน และโน้มน้าวให้แต่ละบริษัทแก้ส่วนที่ใช้งานผิด
    • ให้ Microsoft แก้เพียงครั้งเดียว เพื่อไม่ต้องกังวลเรื่องเดิมอีก
  • Randall กล่าวว่าเขาทดสอบพฤติกรรมการชนกันแบบเดียวกันในแอปยืนยันตัวตนอื่น 14 แอป แต่ไม่มีแอปใดทำงานเหมือน Microsoft Authenticator
  • แอปที่ทดสอบประกอบด้วย Google Authenticator, Okta Verify, Duo Mobile, LastPass Authenticator, 2FA Authenticator, Twilio Authy, Salesforce Authenticator, OneAuth, ForgeRock Authenticator, Authenticator 7, Authenticator App, Auth0 Guardian, OTP Auth, Authenticator 2FA Sentinel

บทความที่เกี่ยวข้อง

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

 
GN⁺ 2024-08-18
ความคิดเห็นบน Hacker News

  • เป็นตัวอย่างเล็ก ๆ ที่สะท้อนปัญหาใหญ่ของ ความปลอดภัยที่ไม่มี usability ได้ชัดมาก
    ลองนึกถึงเรื่องไร้เหตุผลที่เราต้องเจอภายใต้ชื่อ “ความปลอดภัย” ดูก็พอ เช่น การบังคับเปลี่ยนรหัสผ่านเป็นระยะ ๆ, กฎรหัสผ่านบ้าบอ, ข้อกำหนดที่ไม่ได้ทำเอกสารไว้และต้องเดาเอาจากการลองผิดลองถูก, ข้อความผิดพลาดซับซ้อนที่เต็มไปด้วยศัพท์เทคนิคด้านความปลอดภัย, “คำถามลับ” ที่จำคำตอบไม่ได้ อะไรพวกนี้
    แต่ตัวระบบพวกนี้เองกลับมีช่องโหว่พรุนเหมือนตะแกรง ข่าวข้อมูลรั่วและข้อมูลถูกเปิดเผยมีให้เห็นแทบทุกวัน จนหลายครั้งก็สงสัยว่าทำไมเรื่องพวกนี้ถึงยังผ่านไปได้เรื่อย ๆ

    • Capital One อยู่ดี ๆ ก็เพิ่ม “ชื่อผู้ใช้” เข้ามา แล้วทำให้การล็อกอินด้วยอีเมลเสีย แต่ไม่ได้ทำเอกสารอธิบายไว้ และก็ไม่ได้ห้ามใช้อีเมลเป็นชื่อผู้ใช้ด้วย
      หลายเดือนที่ทุกครั้งที่ล็อกอินต้องใช้ “ค้นหาบัญชีของฉัน” และทุกครั้งก็ต้องตั้งชื่อผู้ใช้กลับไปเป็นอีเมลอีกครั้ง มันก็สมเหตุสมผลอยู่ เพราะนั่นเป็นข้อมูลล็อกอินมาตลอดเกือบ 10 ปี
      ข้อจำกัดที่ห้ามใช้ @ หรือ . ในชื่อผู้ใช้ไม่เคยถูกบังคับใช้เลยจนกว่าจะถึงตอนล็อกอิน สุดท้ายผ่านไปหลายเดือนถึงได้รู้ว่าต้องเปลี่ยนเป็นค่าอื่น
      เดิมทีบัญชีนี้เป็นของ ING Direct จากนั้นเป็น Capital One 360 แล้วค่อยถูกผนวกรวมเข้ากับความวุ่นวายส่วนอื่น ๆ ของ Capital One แบบเต็มตัว ผมคิดว่าปัญหาชื่อผู้ใช้นี้ก็น่าจะเกี่ยวข้องกับเรื่องนั้น
    • เมื่อวานเพิ่งเจอตัวอย่างดี ๆ มา
      เว็บไซต์: “โปรดเลือกรหัสผ่านที่ซับซ้อน ความยาวอย่างน้อย 8 ตัวอักษร รวมอักขระพิเศษและตัวเลข”
      เปิดตัวจัดการรหัสผ่าน แล้วสร้าง รหัสผ่านสุ่ม 128 ตัวอักษร ด้วยความภูมิใจ
      ครั้งถัดมาที่เข้าเว็บ เว็บไซต์: “กรุณาใส่อักขระตัวที่ 31, 98 และ 102 ของรหัสผ่าน”
      เป็นเว็บไซต์สินเชื่อบ้านในสหราชอาณาจักร
      พอมาคิดดูตอนนี้ ถ้าจะทำแบบนี้ได้ แปลว่าพวกเขาต้อง เก็บรหัสผ่านเป็นข้อความล้วน หรืออย่างน้อยก็ไม่ได้แฮช แต่เข้ารหัสไว้เพื่อให้ถอดกลับมาได้ทุกเมื่อ
    • สิ่งที่เกลียดที่สุดคือแพตเทิร์นแบบนี้: รู้ว่ามีบัญชีอยู่บนเว็บไซต์ที่ไม่ได้ใช้นานแล้ว เข้าไปใส่อีเมลกับรหัสผ่านที่ถูกต้องซึ่งสร้างจากอัลกอริทึมโดยอิงจาก URL ของเว็บ แต่กลับล็อกอินไม่ผ่าน
      คิดว่าอาจเป็นรหัสผ่านที่สร้างด้วยอัลกอริทึมเวอร์ชันเก่า เลยลองอีกครั้งก็ยังไม่ผ่าน สุดท้ายกดรีเซ็ตรหัสผ่าน รับอีเมล คลิกลิงก์ แล้วใส่รหัสผ่านที่สร้างด้วยอัลกอริทึมเป็นรหัสผ่านใหม่ ก็ขึ้นว่า “ใช้อักขระพิเศษตัวนั้นไม่ได้”
      พอเปลี่ยนอักขระพิเศษตัวนั้นเป็นตัวถัดไปตามกฎของตัวเอง คราวนี้ขึ้นว่า “ไม่สามารถรีเซ็ตเป็นรหัสผ่านปัจจุบันได้”
    • จากที่เคยเห็นมา https://studentaid.gov/ แย่ที่สุด ผมไม่อยากใส่ข้อมูลปลอม และก็ไม่สามารถสร้างบัญชีซ้ำเพื่อกลับไปตรวจสอบข้อกำหนดได้
      เท่าที่จำได้มี “ห้ามใช้คำในพจนานุกรม”, “ห้ามใช้ซ้ำ รหัสผ่าน 24 ครั้งล่าสุด”, “ยกเว้นอักขระพิเศษบางตัว”, “คำถามความปลอดภัย 5 ข้อ” และข้อกำหนดรหัสผ่านอื่น ๆ อีกหลายอย่าง
      ไม่มีใครรู้ว่าคำตอบของคำถามความปลอดภัยแยกตัวพิมพ์เล็กใหญ่หรือไม่
      ยังมีข้อความว่าต้องรับรองว่าข้อมูลที่ใช้สร้างบัญชีเป็นความจริงและเป็นตัวคุณจริง ๆ และหากให้ข้อมูลเท็จหรือชวนให้เข้าใจผิด อาจถูกปรับ จำคุก หรือทั้งสองอย่าง
    • ข่าวดีคือ สิ่งที่ยกมาพวกนี้ล้วนเป็นที่รู้กันว่าเป็น ไอเดียที่แย่ ทั้งสำหรับผู้ใช้ปลายทางและคนที่เข้าใจความปลอดภัย น่าเสียดายที่คนส่วนใหญ่ที่นำ policy ด้านความปลอดภัยไป implement ไม่ได้อยู่ในกลุ่มนั้น
      ถ้าใช้คำจากพจนานุกรมตั้งแต่ 4 คำขึ้นไป ก็ได้ความปลอดภัยของรหัสผ่านที่ดีมากแล้ว และใช้วิธีเดียวกันกับคำตอบคำถามความปลอดภัยได้ด้วย มีตัวจัดการรหัสผ่านทั้งฟรีและเสียเงินมากมายที่ช่วยแก้ปัญหาการต้องจำค่าลับทั้งหมดเอง และยังดีสำหรับการสำรองค่าลับของการยืนยันตัวตนสองขั้นตอนด้วย
      ถ้า “ข้อความผิดพลาดซับซ้อน” เป็นข้อผิดพลาดที่คาดหวังให้ผู้ใช้แก้เองได้ ก็อาจแค่ส่งข้อความผิดพลาดทั่วไปพร้อม ID เฉพาะ แล้วให้ติดต่อทีมซัพพอร์ตแทน การยัดศัพท์เทคนิคใส่มาเต็ม ๆ มันน่ารำคาญก็จริง แต่ดูเหมือนจะเป็นความไร้ความสามารถทั่วไปของมนุษย์ในการอธิบายข้อผิดพลาด มากกว่าจะเป็นปัญหาเฉพาะของความปลอดภัย
      องค์กรส่วนใหญ่ แม้ธุรกิจโดยรวมจะประสบความสำเร็จ ก็ยังทำหลายอย่างพังไปพร้อมกันได้ และความปลอดภัยก็เป็นหนึ่งในนั้น ถ้าองค์กรใหญ่พอ ผมว่าหลีกเลี่ยงได้ยากที่จะมีคนไร้ความสามารถทำงานแบบไร้ความสามารถ

  • เรื่องนี้ไม่สมเหตุสมผลในหลายระดับ หมายความว่า Microsoft Authenticator เก็บรายการโดยอิงแค่ label อย่างนั้นหรือ? ไม่ได้สร้าง internal key อะไรเลยหรือไง?
    แล้วจากนั้นก็จะอ้างว่าเป็นความผิดของเว็บไซต์ที่ใส่ issuer ไว้ใน field issuer ซึ่งควรอยู่ตรงนั้นอยู่แล้ว แทนที่จะใส่ไว้ใน label อย่างนั้นหรือ?
    ผมสงสัยว่ามีคนที่ Microsoft ใช้ Authenticator ของตัวเองจริง ๆ บ้างไหม ถ้าผมไม่ได้พลาดอะไรไป แปลว่าทันทีที่ใช้อีเมลกับเว็บหนึ่งแล้ว ก็จะเพิ่มเว็บอื่นด้วยอีเมลเดียวกันไม่ได้ ทำให้แทบใช้กับแอปพลิเคชันส่วนใหญ่ไม่ได้เลย

    • คล้าย ๆ กัน Google ซึ่งเป็นยักษ์ใหญ่ด้านการค้นหา เคยปล่อย Google Authenticator บน Android โดยไม่มีช่องค้นหา และแม้จะมีคนขอฟีเจอร์นี้หลายครั้ง ก็ยังจงใจไม่ใส่มา
      แต่เวอร์ชัน iOS กลับมีช่องค้นหา ไม่เข้าใจเลยว่าทำไม
      ใน repo Piper ขนาดมหึมาน่าจะมีไลบรารี local search ที่ยัดเข้ามาได้ด้วย changelist เดียวอยู่แล้ว เพียงแต่มันไม่ใช่โมเดลภาษาใหญ่เท่านั้นเอง
    • ตามบทความ Microsoft ไม่คิดจะแก้ เพราะเป็น ผลิตภัณฑ์ฟรี จึงไม่ได้สร้างรายได้
    • ถ้าพนักงาน Microsoft ใช้ Authenticator ของตัวเอง ก็น่าจะใช้แค่กับบัญชีงานของบริษัทที่ Microsoft เป็น issuer รายเดียวเท่านั้นอย่างมาก
      และผมคิดว่าคนจำนวนมากคงไม่ใช้เลยด้วยซ้ำ
    • ตรงนี้เหมือนมีอะไรไม่ลงรอยกัน ผมมีหลายบัญชีที่ใช้อีเมลเดียวกัน และลองเทียบโค้ดจาก Authenticator ซึ่งเป็นแอป TOTP สำรองของผมกับโค้ดที่ถูกต้องแล้ว ก็ตรงกัน
      แต่ผมเจอ ปัญหา UI ที่อาจทำให้ผู้ใช้เห็นโค้ดผิดได้ โค้ดของบัญชีไม่กี่รายการแรกที่มองเห็นบนหน้าจอจะรีเฟรชทุก 30 วินาที แต่โค้ดที่อยู่นอกหน้าจอไม่รีเฟรช
      เมื่อเลื่อนเพื่อดึงโค้ดที่อยู่นอกหน้าจอกลับมา จะเห็นโค้ดเก่า และในกรณีหนึ่งโค้ดที่แสดงช้ากว่าโค้ดที่ถูกต้องไป 4 รอบ
    • น่าจะใช้กับบัญชี MS สำหรับงานที่บริษัทบังคับให้ใช้แค่บัญชีเดียวเท่านั้น ส่วนที่อื่นคงไม่ใช้ เพราะรู้ว่ามันไม่ค่อยดี

  • แปลกดี ผมได้รับอีเมลจาก Microsoft ที่ดูเหมือนฟิชชิงแต่ก็ดูเหมือนจะไม่ใช่
    เนื้อหาบอกว่า “ต้องดำเนินการ: เปิดใช้งานการยืนยันตัวตนหลายปัจจัยสำหรับเทนแนนต์ของคุณภายในวันที่ 15 ตุลาคม 2024” และบอกว่าผมได้รับเพราะเป็น “ผู้ดูแลระบบส่วนกลาง” แต่ไม่มีชื่อองค์กร มีแค่ UUID เขียนไว้
    ตั้งแต่วันที่ 15 ตุลาคม 2024 การเข้าสู่ระบบ Azure portal, Microsoft Entra admin center และ Intune admin center จะต้องใช้ MFA จึงเป็นคำแนะนำให้เปิดใช้งาน MFA ภายในเวลานั้น ถ้าทำไม่ได้ให้ยื่นขอเลื่อนวันบังคับใช้
    ปัญหาคือผมไม่ได้ดูแลองค์กรใด ๆ ใน Microsoft เลย มีแค่บัญชีส่วนตัวอย่าง Office365 Family และในบัญชีก็ตั้งค่าการยืนยันตัวตน 2 ขั้นตอนไว้แล้ว
    ในอีเมลไม่มีทั้งชื่อผมและชื่อองค์กร supposed มีแค่ ID เลยไม่เข้าใจเลยว่าหมายถึงอะไร แต่ก็เป็นอีเมลที่มาจาก Microsoft จริง ๆ

    • ถ้าเข้าสู่ระบบ Azure portal น่าจะเห็นข้อความคล้ายกันและไปยัง resource ที่เกี่ยวข้องได้

  • หลังสร้างบัญชี Gmail แล้ว ผมเปลี่ยนประเทศและคอมพิวเตอร์จนเสียบัญชีไปหลายบัญชี พอจะล็อกอิน Google บอกว่ารหัสผ่านถูก แต่ไม่คุ้นกับอุปกรณ์และ IP
    จำไม่ได้ชัดเจนว่าทำไมการกู้คืนผ่านที่อยู่สำรองถึงใช้ไม่ได้ ทั้งที่ยังเข้าถึงอีเมลสำรองนั้นได้อยู่ แต่ก็ล้มเหลว อาจเป็นเพราะ Google ให้บอกว่าที่อยู่อีเมลสำรองคืออะไร และผมอาจเคยใช้ suffix แบบสุ่มที่มี + กับที่อยู่สำรอง
    เมื่อก่อนผมใช้ Google Authenticator กับบัญชี Gmail แต่ปิดไปเพราะกลัวว่าจะเพิ่มจุดที่อาจพังอีกหนึ่งจุด ในสถานการณ์ที่ Google แทบไม่ให้ทางเยียวยาอะไร
    รหัสผ่านมี entropy มากกว่าประมาณ 96 บิต โดยดึง 256 บิตจาก /dev/urandom มาทำเป็นจำนวนเต็มแบบ multiple-precision จากนั้นใช้ divmod เลือกอย่างละหนึ่งตัวจากตัวเลข·ตัวพิมพ์เล็ก·ตัวพิมพ์ใหญ่·สัญลักษณ์ ส่วนที่เหลือเลือกจากตัวอักษรทั้งหมด แล้วใช้ entropy ที่เหลือทำ Fisher-Yates shuffle เพื่อไม่ให้ตัวแรกเป็นตัวเลขเสมอ
    เป็นรหัสผ่านแยกตามแต่ละเว็บ และเก็บไว้ใน password manager ฐาน gpg ที่ผมทำเองตั้งแต่ต้นยุค 2000
    การยืนยันตัวตนหลายปัจจัยช่วยได้กับการบุกรุกเชิงรุกที่กำลังดำเนินอยู่บางส่วน แต่ไม่ได้ช่วยกับการ dump hash รหัสผ่านจากการรั่วของฐานข้อมูล การที่รู้รหัสผ่านแล้วแต่ยังกู้คืนผ่านอีเมลสำรองไม่ได้มันทรมานจริง ๆ
    ถ้าไม่ได้ล็อกอินจากที่ไหนเลยมาหลายเดือนและมีรหัสผ่านที่ถูกต้อง อย่างน้อยก็ควรส่งลิงก์หรือโค้ดยืนยันไปยังที่อยู่สำรอง แทนที่จะบังคับให้บอกที่อยู่สำรองด้วยซ้ำ ไม่ต้องบอกก็ได้ว่าจะส่งไปที่ไหน แต่การทำให้อีเมลสำรองกลายเป็นรหัสผ่านอีกชุดที่ต้องจำ น่าหงุดหงิดจริง ๆ

    • ผมไม่รู้เรื่องนี้เลย ตั้งที่อยู่อีเมลกู้คืนเป็นบัญชี Gmail ที่ไม่ได้ใช้งานอีกบัญชี เพื่อเพิ่มความเสี่ยงให้มากขึ้น
      ตอนนี้ผมไม่ไว้ใจ Google เกินกว่าข้อมูลที่เคยให้ไปแล้วและข้อมูลที่จำเป็นต้องให้จริง ๆ
      ผมมีกำหนดย้ายประเทศ เลยต้องเร่งย้ายชีวิตอีเมลไปยัง Proton Mail ซึ่งเป็นบัญชีแบบเสียเงินที่กำลังทดสอบอยู่ ก่อนจะเกิดปัญหาร้ายแรง
      ในยุคที่ Gmail ยังดูใสซื่อ ตอนที่งานราชการเริ่มออนไลน์ ผมเริ่มให้ Gmail เป็นช่องทางติดต่อกับที่ต่าง ๆ เช่น ภาษี การแพทย์ หน่วยงานรัฐ มันใช้ได้ดีจนระหว่างการย้ายประเทศหลายครั้ง Gmail กลายเป็นเครื่องมือสำคัญด้านธุรการ
      มีบัญชีที่ไม่ได้ใช้งานกระจัดกระจายอยู่หลายที่ แต่ยังมีเรื่องสำคัญที่สักวันอาจต้องใช้เหลืออยู่ เช่น ใบอนุญาตเดินทางไปออสเตรเลียที่มีอายุหลายปี
      แม้หลังจากการสอดส่องมวลชนเร่งตัวขึ้น Gmail ก็ยังดูค่อนข้างไม่เป็นพิษเป็นภัย และแทบไม่มีความลับจริง ๆ หรือเรื่องส่วนตัวลึก ๆ นอกจากข้อเท็จจริงว่าผมติดต่อทำธุรกรรมกับหน่วยงานใดบ้าง
      แต่ตอนนี้เมื่อระบบราชการออนไลน์แทบกลายเป็นสิ่งจำเป็น และช่องทางอื่นเหลืออยู่น้อยที่สุด Gmail ก็กลายเป็นศูนย์กลางจนน่าอึดอัดเกินไป เรื่องน่ากังวลที่บอตอัตโนมัติทำกับผู้ใช้ที่ไม่ได้ทำตัวน่าสงสัยโดยไม่มีความปรานีหรือช่องทางอุทธรณ์ ทำให้ผมจำเป็นต้องเริ่มย้ายออก
      มันกระจายไปทั่วมากจนไม่มีเวลาตามหาให้ครบ และบัญชีที่ถูกลืมก็เหมือนการทรมานที่ต้องขุดความทรงจำเลือนรางขึ้นมา แต่ก็ต้องทำ
      ผมไม่อยากให้ลูกสาวฝาแฝดต้องไปอยู่ใต้ ความปรานีของบอต Google เมื่อถึงวัยที่ต้องใช้อีเมลกับงานทางการ
    • ตอนที่เพิ่มอีเมลกู้คืน คุณน่าจะได้รับอีเมลแจ้งเตือนไปยังบัญชีนั้น ถ้าหาอีเมลนั้นในกล่องจดหมาย อาจดู suffix แบบสุ่มได้จากฟิลด์ to
    • ผมเคยเจอเรื่องคล้ายกัน ถูกเพิ่มเข้าไปในโดเมน Google ของโปรเจกต์โอเพนซอร์สบางอันและได้รับที่อยู่อีเมล แต่ Google ขอเบอร์โทรศัพท์ ทำให้ล็อกอินไม่ได้
      อาจคุยกับผู้ดูแลระบบให้รีเซ็ตได้ แต่การจับบัญชีเป็นตัวประกันโดยพฤตินัยจนกว่าจะยอมส่งข้อมูลส่วนตัวให้นั้นค่อนข้างน่ารังเกียจ
    • เพราะไม่มีใครให้คุยด้วยเลย พอคอมพิวเตอร์บอกว่าไม่ได้ ก็คือจบแค่นั้น

  • ผมใช้ของ Microsoft มาตลอดเพราะบัญชีงาน ยังไงมันก็ฝังลึกอยู่ใน Office365 อยู่แล้ว เลยไม่มีเหตุผลที่จะไม่ใช้
    ผมไม่เคยเห็นกล่องโต้ตอบแบบนั้น และบัญชีที่เพิ่มไว้ก็ไม่มีปัญหา เพราะเป็นบัญชีงาน 99% ก็ใช้อีเมลบริษัทของผมเป็นชื่อบัญชี
    งั้นแปลว่าผมโชคดีที่เว็บที่ผมใช้ให้ป้ายกำกับที่เป็นเอกลักษณ์พอหรือเปล่า? รู้สึกว่ายังไม่เข้าใจเต็มที่ว่าปัญหาคืออะไรกันแน่

    • ผมอยากใช้คีย์ฮาร์ดแวร์เป็นการยืนยันตัวตนสองขั้นตอน แต่ไม่ใช่ทุกระบบจะรองรับ และหลายระบบก็รองรับได้ไม่ดีด้วย ถ้าจำกัดว่าลงทะเบียนคีย์ได้สูงสุด 1 อัน แล้วจะให้ทำยังไงกันแน่
      สุดท้ายเวลาก็ผ่านไป และนี่ไม่ใช่งานที่หาเลี้ยงครอบครัว แต่เป็นเรื่องน่ารำคาญที่ต้องมาขุดคุ้ยว่าต้องทำยังไงถึงจะล็อกอินได้ ผมเลยตัดสินใจใช้ของ MS ที่ที่ทำงานเก่าบังคับใช้
      ผมเสียเวลาไปมากเกินไปแล้วกับการง่วนอยู่กับเรื่องพวกนี้แทนที่จะทำสิ่งที่มีความหมายเพียงเพราะต้องใช้บัญชีออนไลน์
      ระบบยืนยันตัวตนออนไลน์ทั้งหมดไม่น่าเชื่อถืออย่างร้ายแรง เต็มไปด้วยช่องโหว่ใหญ่และความเสี่ยงที่ใหญ่กว่า แต่เรากลับสร้างทั้งชีวิตไว้บนสิ่งนั้น
      แม้จะมีความเสียหายร้ายแรงจากจุดอ่อนของรหัสผ่านมาหลายสิบปี เราก็ยังใช้รหัสผ่านอยู่ และพยายามปะผุด้วยพลาสเตอร์หรือทาสีทับ
      แทบทุกสัปดาห์มีระบบออนไลน์สักแห่งปล่อยข้อมูลส่วนบุคคลจำนวนมากที่เอาไปใช้โจมตีได้ง่าย แต่เราก็นั่งพูดว่า “ไม่เป็นไร ไม่เป็นไร” เหมือนมีมหมานั่งจิบกาแฟกลางห้องไฟไหม้
      เราบอกกันว่าถ้าใช้รหัสผ่านยาวอย่างน้อย 8 ตัวอักษรที่ต่างกันในทุกระบบก็จะปลอดภัย แล้วก็เชื่อว่าทุกอย่างจะโอเค
    • บั๊กนี้ดูเหมือนจะเกิดเฉพาะตอนสแกน QR code ใน แอป iOS
    • ผมก็เหมือนกัน บัญชีส่วนตัว 3 บัญชีใช้อีเมลเดียวกัน โดยสองบัญชีเป็นของ FAANG และใช้มาเกือบ 10 ปีโดยไม่มีปัญหา
    • ถ้าอ่านคำตอบของ Microsoft จะเห็นว่า Microsoft โทษบริษัทที่ออก MFA ว่า “ไม่ได้ใส่ issuer ไว้ใน label” MSFT คาดหวังว่า issuer ควรอยู่ตรงนั้น
      ถ้าคาดหวังแบบนั้น ผลิตภัณฑ์ของ Microsoft ก็น่าจะใส่ issuer ไว้ใน label เอง จึงไม่มีปัญหา
      ปัญหาเกิดเมื่อใช้ผู้ให้บริการรายอื่นที่ใช้อีเมลเดียวกันเป็นตัวระบุ แต่ใส่ issuer ไว้ใน issuer field ซึ่งมีไว้ให้เก็บ issuer อยู่แล้ว เหมือนจะบอกว่านั่นเป็นพฤติกรรมประหลาดเสียอย่างนั้น

  • Safari ก็มีบั๊กคล้ายกัน ทำให้ เขียนทับ passkey โดยไม่มีคำเตือนใด ๆ จนถูกล็อกออกจากบัญชีอย่างสิ้นเชิง ภายหลังแก้แล้ว แต่เพราะเรื่องนี้ผมเลยเสียสิทธิ์เข้าถึง GitHub
    https://bugs.webkit.org/show_bug.cgi?id=270553
    Safari ยังมีบั๊กที่แยกเว็บไซต์ซึ่งโฮสต์อยู่คนละ subdomain กันไม่ได้ นอกจากข้อยกเว้นที่ hardcode ไว้ และเขียนทับรหัสผ่านของ subdomain หนึ่งด้วยของอีก subdomain เรื่องนี้เจอทุกเดือน

    • หนึ่งในเหตุผลที่ทำให้ผมไปใช้ ตัวจัดการรหัสผ่านของบุคคลที่สาม ซึ่งสามารถเพิ่มหลายเว็บไซต์ไว้ในรายการเดียวได้ด้วยตัวเอง คือ Keychain เตือนว่า StackOverflow กับ subdomain ต่าง ๆ ของ StackExchange ใช้รหัสผ่านซ้ำกัน
      แต่ไม่รู้เลยว่าความงี่เง่าแบบนี้จะลึกไปกว่านั้นอีก

  • นี่แหละเหตุผลที่ การยืนยันตัวตนหลายขั้นตอนผ่าน SMS ยังเป็นที่นิยมในหมู่ผู้ใช้ แม้จะมีช่องโหว่ด้านความปลอดภัย
    โดยทั่วไปมันก็ใช้ได้ดีพอ ตราบใดที่ไม่ได้ตกเป็นเป้าของการโจมตีแบบ SIM swap คนส่วนใหญ่ไม่ได้เป็นเป้าหมาย แต่มีโอกาสพอสมควรที่จะเจอปัญหาทำคีย์ MFA หาย

    • ใช่ เรียบง่ายและแทบทุกคนเข้าใจ เหมือนรหัสผ่านเองนั่นแหละ
      นี่ก็เป็นเหตุผลที่วิธีที่ปลอดภัยกว่าอย่าง YubiKey แพร่หลายสู่คนทั่วไปไม่ได้ มันวุ่นวายและชวนสับสน
    • ผมเคยเปิดใช้สองครั้ง ครั้งแรกโทรศัพท์พังสนิททันทีหลังเปิดใช้ และครั้งที่สองถูกขโมย
      ตอนนี้เลยพึ่งรหัสผ่านที่สุ่มสร้างอย่างเดียว
    • ผมคิดว่าหนทางข้างหน้ามีแค่ FIDO กับคีย์การ์ด NFC ราคาถูกมาก ๆ
      เมื่อต้องล็อกอินที่ไหนสักแห่ง ก็หยิบการ์ดจากกระเป๋าสตางค์มาแตะกับโทรศัพท์หรือแล็ปท็อป
      สำหรับบริษัทที่มีลูกค้าจ่ายเงิน มันควรถูกพอจนการส่งบัตรจริงทางไปรษณีย์ให้ลูกค้าเมื่อเขาไม่มีบัตร ยังสมเหตุสมผลกว่าการรองรับวิธียืนยันตัวตนทางเลือก
      บริการส่วนใหญ่อาจไม่จำเป็นต้องมีชั้นการยืนยันตัวตนที่สองด้วยซ้ำ ต่อให้มีคนขโมยกระเป๋าสตางค์ไป เขาจะสนใจบัญชี Reddit จริง ๆ หรือ

  • ผมลองทดสอบแล้ว ไม่พบการชนกันระหว่างหลายบัญชีที่ใช้ชื่อบัญชี/อีเมลเดียวกัน
    แต่ละรายการแสดงไอคอน issuer ถูกต้อง และมีการบันทึก issuer ไว้ในแต่ละรายการ
    ผมใช้ MS Authenticator มาหลายปีแล้ว และไม่เคยเจอปัญหาประเภทนี้เลย แน่นอนว่าผมมักใช้อีเมลเดียวกันเป็นชื่อบัญชีหรือชื่อผู้ใช้เสมอ
    แค่บอกผลการทดสอบเฉย ๆ คงไม่ทำให้ความเห็นที่มีต่อ Authenticator หรือ Microsoft เปลี่ยนไปหรอก

    • อยากรู้ว่าเป็นแพลตฟอร์มไหน ได้ยินมาว่าปัญหานั้น หรือจะเรียกว่า “ฟีเจอร์” ก็ได้ จำกัดอยู่แค่ เวอร์ชัน iOS

  • เรื่องนี้เกิดกับผมเหมือนกัน ตอนที่อัปเดต MS Authenticator หลังไม่ได้อัปเดตมาพักใหญ่
    ข้อมูลทั้งหมดถูกลบ และผมถูกล็อกออกจากทุกบัญชี MS Authenticator ไม่ใช่ผลิตภัณฑ์ที่ถูกทำมาอย่างรอบคอบ

  • ประมาณ 1 ปีก่อน ผมเคยเจอเรื่องคล้ายกันตอนแอป Google Authenticator อัปเดตอัตโนมัติเป็นเวอร์ชันใหม่
    ระหว่างการอัปเดต ผมเสียบัญชีทั้งหมดไป และได้บทเรียนมาหลายอย่างแน่นอน

    • เพราะฝันร้ายแบบนี้ ผมเลยสำรอง MFA QR code ไว้เสมอ และใช้มันเพิ่มเข้าไปในแอปโอเพนซอร์สที่สามารถสำรองข้อมูลไว้ที่อื่นได้ด้วย