WebAuthn มาตรฐาน “Password Less” บน Web Browser

เผอิญอ่านบทความผ่านๆไป พึ่งเห็นว่าวันที่ 4 มีนาคม 2562, ทาง W3C (องค์กรที่พัฒนาเทคโนโลยี WWW) และ FIDO Alliance (Fast IDentity Online, กลุ่มบริษัทพันธมิตรยักษ์ใหญ่ที่ร่วมกันแก้ปัญหาเรื่อง User / Password ในการยืนยันตัวตนแบบ Online) ได้ประกาศให้ “WebAuthn (Web Authentication) เป็นมาตรฐานของเวปอย่างเป็นทางการ” ซึ่งหมายความว่า ในอนาคตอันใกล้เราจะสามารถเข้าถึงเวป โดยไม่ต้องใช้ User / Password แต่จะใช้ Authenticator อื่นๆ เข้ามาช่วยในการ Authenticate ผู้ใช้งานแทน ซึ่งจะช่วยเพิ่มความปลอดภัยให้กับเวปแอพพลิเคชั่นเป็นอย่างมาก มันเป็นยังไง ไปดูกันครับ

Reference :

https://fidoalliance.org/w3c-and-fido-alliance-finalize-web-standard-for-secure-passwordless-logins/

https://www.w3.org/2019/03/pressrelease-webauthn-rec.html.en

** เนื้อหาใน Blog นี้จะค่อนข้างใช้พื้นฐานความรู้ของ Public Key Cryptography  ศัพท์บางคำจะขอเรียกทับศัทพ์เพื่อให้กระชับมากขึ้นนะครับ

เดี๋ยวก่อน User / Password มันไม่เพียงพอจริงๆหรือ?

ปัญหาเรื่องของ User / Password เป็นปัญหาระดับโลกมาสักพักใหญ่ๆแล้วครับ โดยจากที่ FIDO Alliance สรุปไว้คร่าวๆ จะตามข้อมูลด้านล่าง ซึ่งมีผลกระทบต่อผู้ใช้งาน โลกธุรกิจ และความปลอดภัยโดยรวมของโลกอินเทอร์เนตอย่างยิ่งยวดครับ

Reference : https://fidoalliance.org/what-is-fido/

ที่ผ่านมาตั้งแต่ตอนเรียน Computer Security เรามักจะได้ศึกษาข้อกำหนดต่างๆนาๆเกี่ยวกับการตั้ง Password ที่ดีเต็มไปหมด เช่น Password ต้องมีความยาวอย่างน้อย 8-16 ตัวอักษร, ไม่เป็นคำใน Dictionary, ไม่ควรใช้ชื่อสัตว์เลี้ยง วันเดือนปีเกิด เบอร์โทร ที่อาจจะเดาได้จาก Social Network ต่างๆ, Password ให้มีความซับซ้อน (Password Complexity) โดยมีส่วนผสมของตัวเลข (0-9), ตัวอักษรทั้งเล็ก – ใหญ่ (a/A-z/Z), อักขระพิเศษ (!@#*$%) เป็นต้น รวมถึงต้องเปลี่ยนทุกๆ 90 วัน แถมถ้าเปลี่ยนแล้วห้ามใช้ Password ซ้ำของเก่าอีกอย่างน้อย 5 รอบอีกตะหาก โอว! อยู่ยากจริงถ้าทำตามนี้ได้ รับรองว่าคนอายุเกิน 50 ไม่น่าจะทำตามแน่ อย่างน้อยก็ญาติๆผมละ 🙂

ขอนอกเรื่องนิดนึง หลายๆท่านอาจจะยังไม่ทราบ ประมาณ June 2017 NIST ได้ออก Guidline NIST-SP800-63B Digital Identity Guidelines, Authentication and Lifecycle Management โดย Guideline ดังกล่าวได้ปรับปรุงข้อแนะนำเกี่ยวกับการตั้ง Password บางส่วนไว้ดังนี้

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

เอาละ สมมุติว่าเราตั้งไปตามข้อกำหนดที่เขาแนะนำอันแสนวุ่นวาย แล้วมันยังไม่ Secure พออีกเหรอ? จริงๆมันก็พอละ แต่….ระบบก็ยังถูก hack ได้น่ะสิ!

 

 

เมื่อไม่นานมานี้ หลายท่านอาจจะเคยได้ยินข่าว E-Mail / Password หลุดออกไป 773 ล้านบัญชีและถูกเปิดเผยบนโลกออนไลน์ ส่วนใหญ่คนรู้จักรอบๆตัวผมโดนหมดเลยเปลี่ยนกันใหญ่ หรือสามารถตรวจสอบแบบออนไลน์ได้ผ่าน https://haveibeenpwned.com/ เรื่องนี้แสดงถึงอะไร? “ต่อให้เราตั้ง Password ดีแค่ไหน ถ้าระบบนั้นถูก Hack ไป Password ซึ่งเป็นสิ่งที่ใช้ยืนยันตัวตนของเราก็หลุดไปด้วยเช่นกันนั่นเองครับ” นี่ยังไม่รวมถึง Phishing Site ต่างๆ ที่จะคอยล่อหลอกให้เรา Login ผ่านช่องทางออนไลน์ต่างๆ เพื่อดักจับ User / Password ของผู้ใช้งานในอินเตอร์เนต

Password เพียงอย่างเดียวจึงไม่เพียงพออีกต่อไปเพราะมีช่องทางให้หลุดเยอะมาก และมีผลกระทบสูงต่อผู้ใช้งาน ดังนั้นจึงจำเป็นที่จะต้องมีแฟคเตอร์อื่นมาเสริม โดยอาจจะเป็น MFA (Multi Factor Authentication) โดยใช้ Hint, E-Mail, SMS,USB Token, Fingerprint, Face Recognition มาทำงานร่วมกับ Password แต่เอาจริงๆ MFA บางตัว เช่น Timebase OTP ก็ยังถูก Hack ได้อยู่ดีจากการทำ Phishing และ Man in the middle attack รวมถึงเทคนิคการ Next Generation ของ Phishing อย่าง Evilginx 2 ที่นอกจากจะได้ User / Password ของผู้ใช้งานแล้ว ยังได้ Session Information เช่น Authentication Token, Session Information ใน Cookies สามารถ Bypass MFA ได้

* ข้อมูล Evilginx 2 ลองดูจากลิงค์ที่ผมแนบไว้นะครับ ไม่อยากยกมาตรงนี้เพราะจะยาวจนเป็นบทความใหม่ได้อีกเรื่อง ถ้ามีโอกาสจะย้อนกลับมาเขียนละเอียดๆอีกทีครับ

จากที่ผมเล่ามาข้างต้นทุกท่านน่าจะเห็นปัญหาตรงกันนะครับ ว่าทำไม W3C พยายามขยับเรื่อง Identity ให้เป็นมาตรฐานของเวป ซึ่งมันสำคัญจริงๆนะ สำคัญมานานมากแล้วด้วย! 

 

WebAuthn คืออะไรและทำงานยังไงล่ะ?

WebAuthn ถูกพัฒนามาจาก Specification ของ FIDO2 ออกแบบมาเพื่อให้ Web Application ที่ทำงานร่วมกับ Browser สามารถยืนยันตัวตนและป้องกันผู้ใช้งานจากการถูก Phishing ได้, สามารถใช้งานได้ง่าย ผู้ใช้งานเพียงแค่สัมผัสหรือมองไปที่ Authenticator จากนั้นระบบจะทำการยืนยันตัวตนได้ทันทีโดยที่ไม่ต้องใช้ Passsword เช่น ยืนยันผ่าน Touch ID ของ Laptop บน Macbook, IPhone หรือ External Authentication ที่เชื่อมต่อผ่าน Bluetooth, NFC หรือ USB เป็นต้น”

FIDO2 ใช้หลักการของ Public Key Cryptography ในการทำงาน โดยเก็บ Private Key เอาไว้ที่ Authenticator และไม่สามารถนำออกไปจาก Authenticator ได้ แต่ Authenticator จะสร้าง Public Key Pair ของแต่ละ Account เพื่อใช้ในการยืนยันตัวตน และตรวจสอบ AppID / Application URL เพื่อป้องกันการ Phishing ให้กับผู้ใช้งานอีกด้วย

Component ของ WebAuthn แบ่งเป็น 2 ส่วนใหญ่ๆ ดังนี้

  • CTAP (Client to Authenticator Protocol) เป็น Low-Level Protocol ในการเชื่อมต่อระหว่าง Bluetooth, NFC หรือ USB เพื่อสื่อสารกับ Authenticator โดย FIDO2 Authenticator สามารถรองรับทั้งแบบ Internal และ External Devices แต่โดยรวมจะต้องเป็น Device ที่สามารถสร้างและเก็บ Public Key Pair ของผู้ใช้งานไว้บน Devices นั้นๆ ได้ โดยแบ่ง Authenticator ออกเป็น 2 ประเภท คือ
    • Internal Authenticator คือ Authenticator ที่ Build-in มากับ Platform เช่น TouchID ของ Macbook, IPhone เป็นต้น
    • External Authenticator คือ Authenticator ที่ Add-On เพิ่มเติม โดยสื่อสารกับ Device ผ่าน Bluetooth, NFC และ USB รวมถึง PIN บน โทรศัพท์มือถือก็สามารถใช้เป็น External Authenticator ได้ถ้าเชื่อมต่อผ่าน Labtop ผ่าน Bluetooth, NFC หรือ USB เป็นต้น
  • WebAuthn (Web Authentication) เป็น API ที่สนับสนุนโดย Browser ที่มีผู้ใช้งานจำนวนมาก เช่น Chorme, Microsoft Edge, FireFox, iOS, Android, Opera เป็นต้น โดย WebAuthn API ยอมให้ Web Site สามารถ Authenticate กับ Authenticator ที่รองรับ CTAP เพื่อยืนยันตัวตนของผู้ใช้งานโดยไม่ต้องใช้ Password โดย WebAuthn API จะใช้ Public Key Cryptography เพื่อสร้าง Public Key และ Private Key จาก Authenticator จากนั้นจะใช้ Public Key และ Credential ID แทน Password ของผู้ใช้งานนั่นเอง

โดยหลักๆ WebAuthn มีโฟลการทำงานสองโฟลคือ Registration (ตอน Register ผู้ใช้งานและ Authenticator กับ Server ครั้งแรก) กับ Authentication (โฟลที่ทำการ Authenticate เพื่อเข้าใช้งาน Server โดยใช้ ผู้ใช้งานและ Authenticator ที่ทำการ Register กับ Server แล้ว)

จากภาพ WebAuthn มีโฟลการทำงานเพื่อ Register ผู้ใช้งานดังนี้

  1. เมื่อผู้ใช้งานต้องการลงทะเบียน (Register) ผู้ใช้กับและ Authenticator เข้ากับ www.tamacorp.co (Relying Party Application) จะเริ่มจาก ผู้ใช้งานส่งเพียง UserName เข้าไปในระบบเพื่อ Register User เข้ากับ www.tamacorp.co (Relying Party Application)
  2. เมื่อ www.tamacorp.co (Relying Party Application หรือ RP) ได้รับ Registration Request แล้ว RP สร้าง Challenge message (Random messages ที่ยาวและมั่วมากพอที่ จะไม่มีใครปลอมได้ ประมาณ Nonce เพื่อพิสูจน์ทีหลังว่าคือผู้ที่ RP คุยอยู่ด้วยจริงๆ) และส่ง UserName, RP Info (Domain ของ RP) กลับไปยัง WebAuthn บน Browser
  3. เมื่อ WebAuthn API ได้รับข้อมูลจาก Server (Challenge + UserName + RP Info) จากนั้นจะส่งข้อมูลดังกล่าวไปยัง Authenticator
  4. เมื่อ Authenticator ได้รับ Challenge + UserName + RP Info จาก WebAuthn API, Authenticator จะทำการตรวจสอบ RP Info ว่ามาจาก URL อะไร แล้วจะแจ้งผู้ใช้งานให้ทำ Action บางอย่างที่ Devices (User Verification) เช่น กด, ใส่ PIN หรือ ถ่ายภาพหน้า (Face Recognition) เป็นต้น เพื่อเป็นการยืนยันตัวตน และจะทำการสร้าง ดังนี้เพิ่มขึ้นมา
    1. Public Key Pair (Public Key + Private Key) สำหรับ Account นั้นๆ
    2. Atteststation Object ใน Authenticator จะมี Attestation Ceritificate ที่ Build-in มาจากโรงงานที่แตกต่างกันในแต่ละ Authenticator และทุกครั้งที่ Authenticator สร้าง Public Key และ Private Key ใหม่ขึ้นมา Authenticator จะ Sign Public Key Certificate ด้วย Attestation Ceritificate เพื่อส่งกลับไปยัง Relying Server เพื่อใช้ในการยืนยัน Intigrity
    3. ระบบจะทำการ Save Private Key และสร้าง Credential ID ที่อ้างอิงถึง Public Key Pair คู่นั้นขึ้นมา
  5. Authenticator จะดำเนินการดังนี้
    1. Sign Challenge โดยใช้ Private Key ที่สร้างขึ้นมา
    2. ส่ง Signed Challenge, Credential ID , Atteststation Object และ Public Key กลับไปยัง Browser
  6. เมื่อ Relying Server ได้รับ Message กลับไป จะดำเนินการดังนี้
    1. แกะ Signed Challenge เพื่อตรวจสอบโดยใช้ Public Key ใน Message ว่าตรงกับบน Server หรือไม่
    2. ตรวจสอบ Atteststation Object ว่าส่งมาจาก Authenticator ตัวจริงหรือไม่
    3. เก็บ Public Key และ Credential ID ของผู้ใช้งาน บน Server เป็นการสิ้นสุดกระบวนการ

 

หลังจากผู้ใช้งานทำการ Register Authenticator เข้ากับ Web ที่ต้องการแล้ว จะเป็นการเข้าใช้งานจริงผ่านโฟลในการ Authentication ซึ่งมีลักษณะดังนี้

จากภาพ WebAuthn มีโฟลการทำงานตอน Authentication เป็นดังนี้

  1. เมื่อผู้ใช้งานต้องการ Login เข้า www.tamacorp.co (Relying Party Application) ผู้ใช้งานส่งเพียง UserName เข้าไปในระบบเพื่อขอ Authenticate ตัวเองเข้ากับ www.tamacorp.co (Relying Party Application)
  2. เมื่อ www.tamacorp.co (Relying Party Application หรือ RP) ได้รับ Authentication Request แล้ว RP จะสร้าง Challenge message (Random messages ที่ยาวและมั่วมากพอที่ จะไม่มีใครปลอมได้) และตรวจสอบพบว่า User ดังกล่าว ได้มีการลงทะเบียนในระบบเรียบร้อยแล้ว Server จะดึง Credential ID ของผู้ใช้งานส่งกลับไปยัง WebAuthn API ของ Browser
  3. เมื่อ WebAuthn API ได้รับข้อมูลจาก Server (Challenge + Credential ID) จากนั้นจะรวมกับ RP ID ที่มี และส่งข้อมูลไปยัง Authenticator
  4. เมื่อ Authenticator ได้รับข้อมูลจาก WebAuthn แล้ว Authenticator จะตรวจสอบ Credential ID ว่าอ้างอิงถึง Public Key Pair ใด  และเมื่อผู้ใช้งานมีการทำ User Verification ที่ Authenticator เรียบร้อยแล้ว  Authenticator จะสร้าง “Assertion” โดยการรวมข้อมูลของ Authenticator และที่ Server ส่งมาเข้าด้วยกัน และ Sign โดยใช้ Private Key ของ Authenticator ที่เลือกขึ้นมา ตามภาพด้านล่าง และส่งกลับไปยัง WebAuthn API
  5. Authenticator จะส่งค่า clientDataHash (Challenge + RP ID), User Handle (เป็น Optional ที่อ้างอิงถึง UserName ที่ใช้ตอน Register), Authenticator Data (เป็น Array ของข้อมูลที่มีรายละเอียดค่อนข้างมาก ทำขึ้นมาเพื่อยืนยัน Operation ของ Authenticator และยังมี Flag เพื่อป้องกันเรื่องของ Replay Attack ที่มาจากการ Clone Authenticator) (ลองดูรายละเอียดเพิ่มเติมและ Format ของ Assertion จาก WebAuthn Client Authentication) กลับไปยัง WebAuthn API และ WebAuthn API จะ Forward ต่อไปยัง Server
  6. เมื่อ Server ได้รับข้อมูล จะทำการแกะข้อมูลออก และทำการตรวจสอบ Challange, Authenticator Data, ตรวจสอบ User Handle , และ Validate Signature โดยใช้ Public Key ที่มีอยุ่ของ Authenticator นั้น หากทุกอย่างสมบูณ์ Server จะส่ง Status Login สำเร็จ (HTTP 200) กลับไปยัง WebAuthen API และเริ่มกระบวนการเข้าใช้งานระบบต่อไป

จากข้อมูลทั้งหมด จะพบว่าทั้ง Flow ไม่ว่าจะ “Registration” หรือ “Authentication” จะไม่มีการเปิดเผย Sensitive information ออกมาจาก Authenticator เลย ไม่ว่าจะเป็น Private Key, Biometric information, PIN etc. และ Server จะไม่เก็บ Sensitive Information อะไรของผู้ใช้งานเลย แต่จะเป็นการแลกเปลี่ยนข้อมูลบางอย่างที่ Pre-Define และใช้ Public Key Cryptography ในการ Validate การแก้ไขข้อมูล รวมถึง Authenticator จะช่วยในการตรวจสอบ URL ของ RP Server เพื่อป้องกันการถูก Phishing อีกด้วย ทั้งหมดนี้ผู้ใช้งานแทบจะไม่ต้องทำอะไรนอกจาก “Touch, มองกล้องหรือกรอก PIN เอาตามที่สะดวก” ที่เหลือจะทำและตรวจสอบจากระบบหลังบ้านทั้งหมด ซึ่งวิธีการนี้ช่วยยกระดับความปลอดภัยของการ Authentication ขึ้นอย่างมาก และป้องกันปัญหาเรื่อง “Password” แบบหายขาดไปเลย แต่ถ้า Authenticator หาย ใช้งานไม่ได้นี่อีกเรื่องนะครับ 🙂

จริงๆแล้วมีรายละเอียดอีกหลายส่วนที่ไม่ได้ลงรายละเอียด ไม่ว่าจะเป็น authenticatorData, Assertion ว่ามาอย่างไร เพราะเห็นว่าจะทำให้บทความโดยรวมยาวและซับซ้อนเกินไป แต่อยากให้เห็นถึงการทำงานโดยรวมของโฟล และการไม่ส่ง Sensitive information ข้ามไปมาระหว่างกันมากกว่า หากสนใจข้อมูลเชิงลึกกว่านี้สามารถหาข้อมูลเพิ่มเติมต่อกันนะครับ แต่ถ้าให้เข้าใจจริงๆแนะนำให้ “ทดสอบ” ตาม Link ด้านล่างด้วยตนเองจะเข้าใจและเห็นตัวอย่าง Messages ครับ โดย Link ที่สามารถทดสอบ WebAuthn ได้ผ่าน URL นี้นะครับ https://webauthndemo.appspot.com/ และ https://webauthndemo.com/

เร็วๆนี้เราน่าจะได้เริ่มเห็น Implementation ของมาตรฐานนี้กับพวก Consumer Application เจ้าดังๆ รอใช้งานกันดูนะครับ 🙂

Reference:

https://fidoalliance.org/what-is-fido/

https://fidoalliance.org/fido2/

https://webauthn.guide/

https://developers.google.com/web/updates/2018/05/webauthn

https://developers.yubico.com/FIDO2/FIDO2_WebAuthn_Developer_Guide/WebAuthn_Client_Authentication.html


Leave a Reply