ปลอดภัยกว่าการมี Password ก็คือการไม่ใช้ Password มันซะเลย
กลับมาอีกครั้งทุกวันหยุดนขัตฤกษ์ หลังจากที่มีเวลามานั่งไล่ดู Session WWDC 2020 ของปีนี้ไปจำนวนนึง มี Session นึงที่ทำให้คัน!! กระตุกต่อมความอยากรู้อยากเห็นเพิ่มเติมอันนึงเลยคือเรื่อง “Meet Face ID and Touch ID for the web” โดยในหัวข้อนี้ไม่ใช่ Techonology ที่ Apple ทำขึ้นมาใหม่แต่อย่างใด แต่มันคือการผลักดัน Technology ที่เค้าใช้กันอยู่แล้วให้มันน่าสนใจมากขึ้น ซึ่งก็ต้องยอมรับว่าถ้า Apple กระโดดเข้ามาร่วมด้วยแล้ว Ecosystem มันต้องเกิดขึ้นเร็วๆนี้อย่างแน่นอน แต่ว่ามันคืออะไรกัน ตามผมมาเลยครับผมจะเล่าให้ฟังครับ
ในทุกวันนี้เราจะเข้าเว็บไซต์ใดเว็บไซต์หนึ่ง ก็อาจจะมีระบบ Login เพื่อยืนยันตัวตนของผู้ใช้งาน แต่ทุกเว็บไซต์หนีไม่พ้นที่จะต้องให้ผู้ใช้งานสร้าง Username และ Password เพื่อเป็นการยืนยันตัวตนของผู้ใช้งาน ซึ่งก็ถือว่าสามารถใช้ยืนยันตัวตนได้ระดับหนึ่งเลยเพราะว่าเค้ารู้ในสิ่งที่เค้าตั้งขึ้นมาเองและเค้าเท่านั้นที่รู้ (Something you know) แต่ปัญหาของ Password อย่างนึงเลย ไม่สิ!หลายอย่างเลย คือ การลืม Password, การตั้ง Password ที่ง่ายเกินไป, Account lock จากการกรอก Password ผิดๆ, ตั้ง Password เหมือนๆกันในทุกๆที่, โดย Social Engineering จากการตั้ง Password ที่ใครก็เดาได้, หรือท้ายที่สุดแล้วคือโดนขโมย Password (Phishing) ไปเลยก็เป็นได้
ความปลอดภัยของเว็บนั้นๆจะดีขึ้นทันตาเห็น เมื่อเริ่มมีช่องทางอื่นที่สามารถระบุตัวตนของผู้ใช้งานได้เพิ่มเติม เช่น One-Time Password (OTP) จาก SMS หรือ Authenticator Application ต่างๆ ซึ่งสิ่งต่างๆเหล่านี้มีเพียงผู้ใช้งานเท่านั้นที่จะมี (Something you have) ซึ่งอาจจะต้องให้ไว้ตั้งแต่การสมัคร การเพิ่ม Factor ในการยืนยันตัวตนจะช่วยเพิ่มความปลอดภัยให้ผู้ใช้งานได้มากขึ้น และช่วงหลังๆมานี้เราจึงเห็นหลายๆเว็บไซต์พยายามแนะนำให้เราเปิดการยืนยันตัวตนของผู้ใช้งานด้วย Factor อื่นๆเพิ่มมากขึ้น หรือที่เราคุ้นหูกันในชื่อ Two-Factor Authentication หรือ Multi-Factor Authentication
อย่างไรก็ดีทั้งสองอย่าง ทั้ง Something you know และ Something you have ผมจะขอเรียกว่าล้วนแล้วเป็นสิ่งเป็นสิ่งที่ “ถูกขโมยได้” ละกัน เช่น Password โจรอยากได้ก้อ Phishing, OTP หรอ อยากได้ขโมยมือถือสิ หรือโจรที่เจ้าเล่ห์หน่อยก็สามารถที่หลอกล่อด้วยความสลับซับซ้อนจนได้มาจากผู้ใช้งานจนได้ ตามที่เราเห็นเป็นข่าวว่าโจรสามารถถอนเงินจากธนาคารได้หมดแม้กระทั้งมี OTP มาให้เจ้าของบัญชีทำการ Verity แล้วก็ตาม ทำไมโลกนี้ช่างโหดร้ายจัง :(
Digital Authentication ด้วย Something you are จึงดูมีภาษีดีที่สุดเลย เพราะของเหล่านั้นเป็นของที่โจรไม่สามารถที่จะขโมยไปจากคุณได้ ซึ่งมันก็คือการ Identify ด้วย Biometric ไม่ว่าจะเป็น ลายนิ้วมือ ดวงตา หรือใบหน้า ก็ตาม เพราะสิ่งๆเหล่านี้ล้วนแล้วแต่เป็นของๆผู้ใช้งานเท่านั้น ซึ่งอาจจะสามารถปลอมแปลงด้วยเทคโนโลยีขั้นสูง หรือตัว Biometric Hardware ต่างๆอาจจะมี Error Rate บ้างแต่นับว่ายังน้อยมากๆ
ซึ่งต้องบอกว่าแอพพลิเคชั่นมือถือส่วนใหญ่แล้วสามารถเริ่มใช้ Biometric พวกนี้ได้มานานพอสมควรละ ไม่ว่าจะเป็น Android หรือ iOS ก็ล้วนแล้วแต่มี API เพื่อให้เข้าถึงความสามารถนี้ได้อย่างง่ายดาย ทิ้งให้เทคโนโลยีเว็บที่ยังคงต้องใช้แต่การยืนยันแบบเดิมๆ จนเมื่อมีพระเอกขี่ม้าขาวมาเริ่มผลักดันส่ิงใหม่นี้ให้ชาวโลกได้มีความหวังกัน นั้นคือ “Web Authentication” หรือขอเรียกสั้นๆว่า “WebAuthen”
WebAuthen คืออิหยั่งว่ะ
เกริ่นกันมาพอสมควร มาเริ่มเข้าเรื่องกันเลยดีกว่าฮ่ะ เรื่องมันเริ่มด้วย FIDO Alliance (FIDO ย่อมาจาก “Fast IDentity Online”) ได้เริ่มคิดที่จะแก้ปัญหาอันยิ่งใหญ่นี้ด้วยโจทย์ที่ว่า .. ทำไงให้การการยืนยันตัวของของผู้ใช้งานมีความปลอดภัยและไม่ต้องใช้ Username และ Password ให้ปวดหัวกันเล่น จนทาง FIDO ได้ร่วมมือกับทาง W3C (WWW) จนเกิดเป็นมาตราฐานใหม่ คือ Web Authentication ซึ่งพื้นฐานทั้งหมดจะอิงอยู่ในหลักการของ Public Key Cryptography มาทำให้มาตราฐานนี้มีความปลอดภัยแบบสุดขั้วไปเลยจร้า ..
หลักการของ Public Key Cryptography จะเก็บ Private Key ไว้ในสิ่งที่เรียกว่า Authenticator (ถ้าใน iPhone/Macbook ก็คือ “Secure Enclave” ที่อยู่ใน Apple Silicon นั่นเอง) โดยที่ตัว Authenticator จะเป็นผู้ที่จะสร้าง Public Key Pair ของแต่ละเว็บไซต์ออกมาให้ผู้ใช้งานได้ใช้งาน ซึ่งใน Authenticator นี่เราในฐานะ Developer ที่ทำเว็บไซต์ต่างๆแทบจะไม่ต้องไปยุ่งกับมันเลย เรียกว่ามีพร้อมให้ใช้งานแล้วเลยฮ่ะ
สำหรับ WebAuthen นี้รองรับบน Browser ชื่อดังมากมาย อาทิเช่น Chorme, Firefox, MS Edge และแน่นอนล่าสุดคือ Safari ที่พร้อมรองรับตั้งแต่ macOS 11 (Big Sur) และ iOS14 นั้นเอง
แล้วมันทำงานอิหยั่งหนิ อันนี้ผมต้องใช้เวลาอ่านอยู่นานพอสมควรกว่าจะเริ่มเข้าใจขึ้นมาบ้างเล็กน้อย เรียกว่ามาเล่าสู่กันฟังละกันนะครับ จริงๆมีรายละเอียดเยอะมากๆ โดยผมจะขอแยกออกเป็นสองส่วนด้วยกันนะครับ อันแรกคือการ Enrolment เพื่อให้ผู้ใช้งานใช้งานการยืนยันตัวตนในแบบ WebAuthen (พูดง่ายๆคือการ Register หรืออาจจะเป็นการเพิ่ม Option การ Sign-in ให้กับผู้ใช้งานก็ได้นะครับ) กับอันที่สองคือการยืนยันตัวตนเพื่อเข้าสู่ระบบใช้งานจริงๆ (Sign-in) ครับ
เริ่มจากการ Enrolment ในแบบ WebAuthen
เริ่มจากผู้ใช้งานส่ง Username เข้ามาเพื่อสมัครใช้งานกับเว็บไซต์ของเรา เราจะเรียก Server ส่วนของเราว่า Relying Party Application (RP)
- Server ของเราจะเตรียมสิ่งของต่างๆให้พร้อม เพื่อส่งไปยัง Browser ของผู้ใช้งาน ซึ่งประกอบไปด้วย
- Challenge (Generate nonce ขึ้นมามั่วๆยาวๆ แล้วจะนำมา verify ทีหลัง)
- User Info (username)
- Replying Party Info (ข้อมูลของ relying party เช่น domain ของ server เรา) - เมื่อ Browser ได้รับข้อมูลทั้งสามแล้วตัว WebAuth API จะทำการส่งข้อมูลทั้งหมด และมี “Client Data Hash” (ประกอบไปด้วย Challenge และ Replying Party ID) อีกอันนึงเข้าสู่ Authenticator
- Authenticator จะทำการตรวจสอบรายละเอียดต่างๆรวมไปถึง Replying Party Info ว่ามาจาก domain อะไร เพื่อแจ้งผู้ใช้งานทำการยืนยันตัวตน เช่น การใส่ PIN, FaceID หรือ TouchID เป็นต้น ซึ่งเมื่อยืนยันตัวตนผ่านแล้ว Authenticator จะสร้างสิ่งเหล่านี้ขึ้นมา ..
- Public Key Pair (ที่ประกอบไปด้วย Public Key และ Private Key) สำหรับการ Authentication Domain นั้นๆในครั้งต่อๆไป
- Crediential ID เป็น ID เพื่อจับคู่กับ Key Pair และ Save เอาไว้ด้วยเพื่ออ้างอิง
- Attestation คือการรับรองการออก Key Pair นั้นๆ ซึ่งภายในของแต่ละ Authenticator จะมี Attestation Certificate ไว้อยู่แล้วซึ่งจะแตกต่างกันแต่ตามอุปกรณ์แต่ละเจ้าที่ผลิตอุปกรณ์กันมา ซึ่งหน้าที่ของมันเลยคือเอาไว้ Sign Public Key อีกทีเพื่อให้ฝั่ง RP หรือ Server ใช้ในการ Verify อีกที - หลังจากนั้น Authenticator จะส่งข้อมูลข้างต้นให้กับ Browser พร้อมกับ Sign Value ต่างๆให้พร้อมก่อนให้ทางเว็บไซต์นำส่งไปยัง Server ในฐานะของ “Attestation Object”
- เว็บแอพลิเคชั่นของเราทำการส่งข้อมูลทั้งหมดไปยัง RP หรือ Server
- Server ของเว็บไซต์จะทำการ Validate Challenge ที่ Authenticator ได้ทำการ Sign ด้วย Private Key ด้วย Public Key ว่าตรงกับที่ Generate ไว้ตั้งแต่ต้นหรือไม่ และทำการตรวจสอบ Attestation Object ซึ่งเมื่อทุกอย่างถูก Verify แล้ว Server จะเก็บ “Public Key” และ “Credential ID” ของผู้ใช้งานเอาไว้เพื่อใช้ในการ Login ครั้งต่อๆไป
การเข้าสู่ระบบในแบบ WebAuthen
เริ่มจากผู้ใช้งานจะเข้าสู่ระบบด้วยการระบุ Username เข้ามาในระบบของเรา RP หรือ Server ของเราเริ่มต้นทำงานตาม Steps ดังนี้
- Server ของเราทำการค้นหา Username ว่าเคยมีอยู่ในระบบเราหรือเปล่า ซึ่งถ้าเจอก้อจะส่ง Credential ID, Replying Party Info พร้อมกับ Generate Challenge เหมือนเดิมครับ ส่งให้กับ Browser ต่อมา
- ซึ่งเมื่อ Brower เราได้รับข้อมูลแล้ว ตัว WebAuthen จะทำการรวบรวม Information ทั้งสองนี้เป็นพร้อมกับ “Client Data Hash” เหมือนเดิมเข้าสู่ Authenticator ครับ
- เมื่อ Authenticator ได้รับข้อมูลจะไปค้นหา Credential ID ก่อนว่ามีใน Authenticator ไหม ถ้ามี Key Pair คืออันไหนเอ่ยไปเอามาซิ๊ .. ซึ่งถ้าเจอและผู้ใช้งานก็จะได้ทำการยืนยันตัวตนเหมือนเดิมด้วยการใส่ PIN, FaceId หรือ TouchID หลังจากนั้นจะเป็นความต่างกันละครับ ตัว Authenticator จะนำข้อมูลที่ Authenticator เก็บไว้ (Authenticator Data) และข้อมูลของ Client Data Hash ที่ส่งมาเข้ามา Signed ด้วย Private Key (ที่ได้สร้างไว้ตั้งแต่ตอน Register) กลายเป็นสิ่งที่เรียกว่า “Assertion Signature” ขึ้นมา
- Authenticator จะส่งค่า “Authenticator Data” และ “Assertion Signature” กลับไปยัง Browser (ลืมบอกไปนึดนึง Authenticator Data คือข้อมูลที่ได้หลังการยืนยันตัวตนจากผู้ใช้งานผ่านเสร็จเรียบร้อยแล้วซึ่งจะมีรายละเอียดอยู่เยอะพอสมควร รวมไปถึงค่าบางอย่างเพื่อป้องกันการ Attack ต่างๆอีกด้วย)
- เว็บแอพลิเคชั่นของเราทำการส่งข้อมูลทั้งหมดไปยัง RP หรือ Server
- เมื่อ Server ได้รับข้อมูล จะทำการตรวจสอบ “Authenticator Data” และ “Assertion Signature” ด้วย Public Key ที่เก็บเอาไว้ตั้งแต่ตอนที่ Register เข้ามา ซึ่งถ้าทุกอย่างถูกต้องการเข้าสู่ระบบก็จะเป็นอันสมบูรณ์ ปล่อยเข้าสู่ระบบได้
เราจะเห็นว่า Concept ไม่ว่าจะเป็นการ On-boarding การใช้งาน หรือการ Authenticate เพื่อเข้าสู่ระบบในแบบ WebAuthen นั้นตั้งอยู่บนพื้นฐานของ Public Key Cryptography ล้วนๆเลยครับ ซึ่งแต่ละ Account ก็จะมีการแยก Key Pair กันไว้อย่างชัดเจน
การพัฒนา WebAuthen บนเว็บไซต์
เนื่องจากว่าความซันซ้อนทั้งหลายเหล่านี้ที่ผมได้เล่าไปในขั้นต้น ถูกจัดการไว้ให้เรียบร้อยแล้วด้วย Browser ชั้นนำ พวกเราเหล่านักพัฒนาเรียกว่าจะเหลือเพียงแค่ขั้นตอนการจัดการเข้ารูปเข้ารอยตาม Flow ที่เค้าได้วางกันไว้แล้ว ซึ่งแบ่งเป็นสามอย่างดังนี้
- การตรวจสอบการรองรับ WebAuthen บน Browser ของผู้ใช้งาน ซึ่งเราก็สามารถใช้ Javascript ตรวจสอบได้แบบนี้เลย
const isAvailable = await PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable();if (isAvailable) {
// ...
}
2. การ Enrollment เพื่อสมัครใช้งานในระบบ
const options = {
publicKey: {
rp: { name: "example.com" },
user: {
name: "john.appleseed@example.com",
id: userIdBuffer,
displayName: "John Appleseed"
},
pubKeyCredParams: [ { type: "public-key", alg: -7 } ],
challenge: challengeBuffer,
authenticatorSelection: { authenticatorAttachment: "platform" },
attestation: "direct"
}
};const publicKeyCredential = await navigator.credentials.create(options);
3. การ Sign-in เพื่อเข้าสู่ระบบ
const options = {
publicKey: {
challenge: challengeBuffer,
allowCredentials: [{
type: "public-key",
id: credentialIdBuffer,
transports: ["internal"]
}]
}
};const publicKeyCredential = await navigator.credentials.get(options);
ทั้งสามขั้นตอนนี้เป็นเพียงช็อตเด็ดช็อตสำคัญของพวกเราที่จะต้องส่งข้อมูลเข้าไปใน Authenticator เท่านั้นเองครับ หากใครสนใจเพิ่มเติมผมขอแนะนำให้อ่านเพิ่มเติมได้จาก https://webauthn.guide/ เลยครับ
สุดท้ายนี้ถ้าพูดถึง Digital Factors of Authentication ในแต่ละวิธี แต่ละวิธีก็มีข้อดีและข้อเสียต่างกันออกไป แต่เราอาจจะพบปัญหาจากการใช้งาน Password ที่มากหน่อยเพราะ Level ของความปลอดภัยอาจจะไม่ได้เท่าวิธีอื่นๆ ดังนั้นหากเราผสมผสานหลากหลายวิธีเข้าด้วยกัน (Multi-Factor Authentication) นอกจากจะช่วยเพิ่มความปลอดภัยให้กับระบบของเราแล้ว ยังอาจเพิ่มประสบการณ์ที่ดีในการใช้งานเพิ่มขึ้นอีกด้วย และด้วย WebAuthen นี้จะทำให้ผู้ใช้งานพบกับประสบการณ์ที่ดีอย่างไม่น่าเชื่อ :)
