มาตราฐาน MFA ใน Authenticator

มาตราฐาน MFA ที่ใช้เป็นแบบตัวเลขเปลี่ยนแปลงไปเรื่อย ๆ ตามเวลาเดินหน้า นั้นมีหลายมาตราฐาน แต่ที่นิยมใช้มี 2 ตัวคือ TOTP และ HOTP

  1. TOTP (TOTP: Time-Based One-Time Password Algorithm) RFC 6238
  2. HOTP (HOTP: HMAC-based one-time password) RFC 4226

โดย Google Authenticator และ Microsoft Authenticator รองรับทั้ง 2 รูปแบบ และในความเป็นจริง Authenticator ทางเลือกอีกหลาย ๆ เจ้าก็รองรับ TOTP และ HOTP กันเป็นปรกติ เพราะเป็นมาตราฐานกลางอยู่แล้ว ฉะนั้นจึงไม่แปลกที่เราสามารถใช้งานข้ามยี่ห้อกันได้

รายการแอปทางเลือกเท่าที่ทราบ

  • Authy (รองรับ sync และ backup/restore)
  • FreeOTP (opensource ไม่รองรับ backup/restore)
  • FreeOTP+ (opensource ที่ folk จาก FreeOTP เพื่อให้รองรับการ backup/restore)
  • 1Password (เสียเงิน และรองรับ field OTP)
  • LastPass (เสียเงิน และรองรับ field OTP)

จริง ๆ มีแอปอีกหลายตัวลองศึกษาเพิ่มเติมและดูความเสี่ยงกันได้ โดยดูว่ารองรับ TOTP/HOTP ตามาตราฐานหรือไม่เป็นอันดับแรก

สำหรับแอป Authenticator ควรจะรองรับการ backup/restore ได้หรือไม่ ก็ยังถกเถียงกันอยู่ต่อไป แต่ผู้ใช้งานต้องยอมรับคามเสี่ยงเพิ่มเติมในการรั่วไหลของข้อมูลเพิ่มเติมหากสำรองข้อมูลอย่าง QR code หรือ secret key ของ TOTP/HOTP ไว้เพื่อเรียกคืนค่าเดิมหากต้องเปลี่ยนโทรศัพท์แล้วเจน TOTP ใน Authenticator ใหม่

วิธีที่ผู้ให้บริการมีเป็นทางเลือกคือ backup code ตัวนี้เป็นท่าพื้นฐาน เราก็เอา backup code การบันทึกเก็บไว้ในที่ปลอดภัย และหวังว่าจะไม่ลืมหรือโดนขโมย ซึ่งวิธีนี้แม้จะคล้ายกับการเก็บ QR code หรือ secret key ในข้างต้น แต่แตกต่างตรง backup code ที่ได้ จะใช้ได้แค่ครั้งเดียว เมื่อใช้ไปแล้ว code ที่เราเลือกใช้ จะใช้ซ้ำอีกไม่ได้ และหากรั่วไหลสามารถขอสร้างใหม่ได้ง่ายกว่ามาก

อีกวิธีก็คือใช้ Security Key เป็นอุปกรณ์อีกตัว มันสามารถเก็บ TOTP/HOTP และเป็น FIDO U2F แทนก็ได้ เพราะปรกติการเปิดใช้งาน MFA มักจะมีทางเลือกให้อย่างน้อย 2 ทางในการใช้งาน MFA อยู่เสมอ หรือถ้ายินยอมรับความเสี่ยงที่จะใช้ตัวเดียวก็จะแจ้งเตือนไว้

หมายเหตุ แม้จะยังมีตัวเลือกให้รับ OTP ผ่านมือถือเป็นทางเลือกสำรอง แต่ในระยะหลัง ก็เริ่มไม่ปลอดภัย และหลายบริการก็แจ้งเตือนความเสี่ยงไว้แล้ว

multi-factor authentication (MFA) ของ Google account และ Microsoft account ไม่บังคับใช้หมายเลขโทรศัพท์มือถือเพื่อรับ OTP ผ่าน SMS

การเปิดใช้ multi-factor authentication (MFA) ของ Google account และ Microsoft account ตอนนี้ไม่บังคับว่าจะต้องใช้หมายเลขโทรศัพท์มือถือในการรับ OTP ผ่าน SMS แล้ว

โดยแนวทางอื่นๆ ในการทำ MFA คือ

  1. ใช้ TOTP ผ่าน Authenticator app
  2. ใช้การยืนยัน push notification ผ่าน Authenticator app (Google เรียก Google prompt)
  3. ใช้ backup code หรือ recovery code ผ่านการจดหรือบันทึกไว้ในที่ที่ปลอดภัย

ส่วนที่ต่างของ Microsoft account มีเพิ่มเติมให้คือ
– ใช้ alternative E-mail ในการรับ OTP ได้ด้วย (ของ Google ไม่มี)

ส่วนที่ต่างของ Google account มีเพิ่มเติมให้คือ
– ใช้ USB FIDO Universal 2nd Factor (U2F) มาใช้ร่วมกับการเข้าระบบ

สำหรับความสามารถ Sign in Without Password ผ่าน Authenticator ที่เป็นการกดยืนยันเข้าระบบโดยไม่ต้องใช้ password ใดๆ ผ่านตัวแอป Authenticator ของทั้งสองค่ายนั้น มีจุดที่แตกต่างคือ Microsoft account ยินยอมให้เปิด MFA ไปพร้อมๆ กันได้ แต่ถ้าเป็น Google จะไม่ยอม จะต้องเลือกอย่างใดอย่างหนึ่ง

สำหรับผู้ให้บริการค่ายอื่นๆ ก็มีแนวทางประมาณนี้เยอะขึ้น ซึ่งส่วนใหญ่จะใช้ backup code เป็นตัวทดแทนการรับรหัส OTP ผ่าน SMS

เหตุผลที่ถอด SMS ออกจากการรับ OTP เพราะช่องโหว่บนระบบ Signalling System No. 7 (SS7) ในระบบสื่อสารผ่านโทรศัพท์ที่สามารถถูกดังฟังได้ อ้างอิง (1), (2) และ (3)

multi-factor authentication ด้วย OTP ก็ไม่ได้ปลอดภัย 100% หากโดน intercept หมายเลขโทรศัพท์มือถือ

บริการต่างๆ ที่ให้เปิด multi-factor authentication มีจุดที่สำคัญที่มักจะให้เราจดจำ และตั้งค่าเพิ่มเติม นั้นคือ backup code และหมายเลขโทรศัพท์มือถือสำหรับรับ reset password หากตัว authenticator ใช้งานไม่ได้

แน่นอน backup code ซ่อนและเก็บได้ ตรงนี้น่าจะพออุ่นใจบ้างหากเก็บไว้ในที่ที่ลับมากๆ ส่วนหมายเลขโทรศัพท์มือถือนั้นแตกต่าง เพราะอาจโดน intercept ตัวเบอร์โทรศัพท์นั้นๆ แล้วนำ code ที่ได้จาก OTP ไปใช้งาน

ซึ่งเมื่อเร็วๆ นี้นักเคลื่อนไหวทางการเมืองถูก hack บัญชี Telegram โดยเกิดจากถูก intercept หมายเลขโทรศัพท์ เพื่อรับรหัส OTP สำหรับเข้าใช้งาน account แอพ Telegram ของเค้า ซึ่งเป็นสิ่งที่เกิดขึ้นได้จริงแล้ว

เพราะโดยปรกติ Telegram ไม่มีการให้ตั้งรหัสผ่านในครั้งแรก แต่ใช้การส่งรหัส OTP เพื่อยืนยันการใช้งานผ่านหมายเลขโทรศัพท์มือถือที่ลงทะเบียนไว้ อ้างอิง Is Telegram Really Safe for Activists Under Threat? These Two Russians Aren’t So Sure.

ทางแก้ที่ Telegram แนะนำ ณ ตอนนี้คือตั้งรหัสผ่านเพิ่มเข้ามาช่วยในการยืนยันตัวตน (ในเมนูของ Telegram มีให้ตั้ง) ทางแก้ไขนี้รวมไปถึง คำแนะนำที่ว่า ควรสื่อสารด้วย secret chat (end-to-end encryption) และตรวจสอบ fingerprints (encryption key) ของคนที่กำลังคุยด้วยเสมอ

จากเหตุการณ์ของ Telegram นี้ ก็กลับมาดูที่ประเทศไทยของเรา การออกซิมการ์ดใหม่ผ่านช่องทางที่มีการตรวจสอบไม่รัดกุม อาจจะเป็นช่องทางที่การใช้งาน multi-factor authentication ด้วย OTP นั้นมีจุดโหว่ และสร้างความไม่มั่นใจต่อหมายเลขโทรศัพท์ที่จะใช้งานควบคู่กับ multi-factor authentication ว่าจะอยู่รอดปลอดภัยได้มากแค่ไหน ตรงนี้เป็นสิ่งที่ผู้ให้บริการต้องตระหนักและช่วยเหลือผู้ใช้งานให้ได้รับความปลอดภัยสูงสุด

ต่อไปรหัสผ่านอาจจะไม่จำเป็นสำหรับทุกๆ เว็บ

เรื่องรหัสผ่านนั้น มาในระยะหลังๆ ก็พบว่า บ้างเว็บก็เก็บรักษารหัสผ่านเราอย่างดี บ้างก็เก็บไว้ห่วยๆ นั้นยังไม่เท่าไหร่ (โดยเฉพาะเว็บของคนไทยหลายๆ เว็บ) แต่จากปัญหา Hearbleed ถึงแม้เว็บจะเก็บรหัสผ่านเราดีเพียงใด แต่ก็มีช่องโหว่ได้เช่นกัน ทำให้การให้เว็บต่างๆ เก็บรหัสผ่านเพื่อยืนยันการเข้าใช้ระบบต่างๆ นั้นเริ่มรู้สึกว่ามันจำเป็นน้อยลง เรื่อยๆ

ผมจึงมีแนวคิดที่เพิ่งคิดได้ว่าต่อไปทำเว็บอาจจะไม่จำเป็นต้องใช้รหัสผ่านแล้ว ใช้การเข้าระบบคล้ายๆ forgot password และมี activate link แทน หรือส่งเป็น OTP ผ่านมือถือแทนโดยใช้ลักษณะเป็นรายครั้ง โดยในส่วนของ OTP ผ่าน SMS นั้นแน่นอนว่าต้องขึ้นอยู่กับบริการแหละว่าแบบไหนควรใช้หรือไม่ควรใช้ ใช้อีเมลเป็นหลัก ส่วนบริการไหนมันซีเรียสมากๆ หรือลูกค้าที่จ่ายเงินใช้บริการ ก็คิดเป็นต้นทุนไป

ส่วนการเชื่อมต่อระหว่างแอพต่างๆ ใช้แนวคิด OAuth 2.0 แทน น่าจะปลอดภัยกว่ามากจากการไม่ต้องจดจำรหัสผ่านมากมายและแตกต่างกันในหลายๆ เว็บ ใช้การเข้าระบบผ่านช่องทางอีเมล หรือส่งรหัสผ่านเข้ามือถือเป็นหลักก็น่าจะเพียงพอและปลอดภัยขึ้น

เราใช้คุกกี้เพื่อพัฒนาประสิทธิภาพ และประสบการณ์ที่ดีในการใช้เว็บไซต์ของคุณ คุณสามารถศึกษารายละเอียดได้ที่ นโยบายความเป็นส่วนตัว

Privacy Preferences

คุณสามารถเลือกการตั้งค่าคุกกี้โดยเปิด/ปิด คุกกี้ในแต่ละประเภทได้ตามความต้องการ ยกเว้น คุกกี้ที่จำเป็น

Allow All
Manage Consent Preferences
  • Always Active

Save