ปัญหาความปลอดภัยพื้นฐานที่สุดที่เราพบกันได้เสมอในทุกวันนี้ไม่ใช่ช่องโหว่ซอฟต์แวร์ที่ต้องอาศัยความรู้ทางเทคนิค แต่ยังคงเป็นการขโมยรหัสผ่านด้วยวิธีการต่างๆ ไม่ว่าจะเป็นผู้ใช้บอกให้ผู้อื่นรับรู้ หรือแม้แต่เก็บรหัสผ่านไว้อย่างไม่ปลอดภัย ไม่ว่าจะเป็นการจดไว้ตามที่ต่างๆ หรือเก็บไว้ในไฟล์ หรือกระทั่งการตั้งรหัสผ่านี่ง่ายมากๆ เช่น "1234" หรือ "password"

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

การยืนยันตัวตนสองขั้นตอนใช้งานมานานในหมู่ผู้ดูแลระบบที่ต้องการความปลอดภัยสูง หรือบัญชีธนาคารที่ทุกวันนี้ธนาคารมักส่งรหัสผ่านที่สองมาให้ผู้ใช้ผ่าน SMS เพื่อยืนยันตัวตนซ้ำ กระบวนการยืนยันตัวตนด้วยขั้นตอนที่สองนี้เป็นมาตรฐาน IETF สองแบบ คือ HOTP และ TOTP

แม้ว่าการส่ง SMS จะใช้งานได้โดยทั่วไป เพราะการเข้าถึงโทรศัพท์มือถือที่ครอบคลุมคนแทบทั้งโลก แต่ SMS มีข้อจำกัดทางค่าใช้จ่ายที่มีค่าส่งต่อครั้งทำให้บริการฟรีให้บริการยืนยันตัวตนด้วย SMS ได้ยาก ทางเลือกของเว็บทั่วไปคือการเปิดใช้งาน TOTP หรือการยืนยันด้วยรหัสผ่านที่เปลี่ยนไปตามเวลา

กระบวนการ TOTP อาศัยหลักการว่าเซิร์ฟเวอร์และผู้ใช้มีข้อมูลลับแชร์ร่วมกันอยู่ เมื่อนำข้อมูลนี้มาต่อเชื่อมเข้ากับข้อมูลเวลาแล้วแฮชจะทำให้ได้ค่าที่ตรงกันทั้งเซิร์ฟเวอร์และเครื่องของผู้ใช้ ซึ่งอาจจะเป็นคอมพิวเตอร์ขนาดเล็กเท่าพวงกุญแจหรืออาจจะเป็นซอฟต์แวร์ในโทรศัพท์มือถือ ข้อจำกัดของการทำงานเช่นนี้คือทั้งสองฝั่งต้องรักษาค่าเวลาให้ตรงกันตลอดเวลา (อ่านเพิ่มเติม - การสร้าง Google Authenticator ด้วย Arduino) ซึ่งเป็นข้อจำกัดว่าอุปกรณ์ต้องมีแบตเตอรี่เพื่อรักษาค่าเวลาตลอดเวลา

แม้ว่า TOTP จะแก้ปัญหาการที่ผู้ใช้ถูกปลอมตัวได้เกือบทั้งหมด แต่ปัญหาสำคัญที่เหลืออยู่คือผู้ใช้กลับถูกหลอกให้เข้าเว็บที่ปลอมตัวเป็นเว็บอื่น (phishing) การโจมตีเช่นนี้ยังคงได้ผลจนทุกวันนี้โดยเฉพาะบริการธนาคารออนไลน์ที่มีมูลค่าสูงและเป็นเป้าหมายการโจมตี ความปลอดภัยของกระบวนการยืนยันตัวตนสองขั้นตอนสามารถถูกข้ามไปได้ทั้งหมดเพราะผู้ใช้เป็นผู้กรอกข้อมูลด้วยตัวเอง แม้เบราว์เซอร์จะแสดงยูอาร์แอลของเว็บได้ แต่ผู้ใช้ก็ถูกหลอกจากยูอาร์แอลที่คล้ายกันได้โดยง่าย

เป้าหมายสำคัญของการพัฒนากระบวนการยืนยันตัวตนสองขั้นตอนต่อมา คือการช่วยผู้ใช้ยืนยันว่าเว็บที่กำลังเข้านั้นเป็นเว็บที่ควรได้รับค่าสำหรับการยืนยันตัวตนจริง โดยที่ผู้ใช้ไม่ต้องยืนยันด้วยสายตาเช่นการมองโดเมน

กูเกิลร่วมกับผู้ผลิตกุญแจยืนยันตัวตนขั้นตอนที่สองอย่าง Yubico วางมาตรฐานใหม่ เพื่อให้มีกระบวนการยืนยันตัวตนที่ผู้ใช้เพียงแค่เก็บรักษากุญแจนั้นให้ปลอดภัย ตัวกุญแจมีความสามารถในการยืนยันได้ว่าผู้ที่ขอยืนยันตัวตนนั้นเป็นบริการเดิมกับที่ลงทะเบียนไว้หรือไม่ แล้วออกมาเป็นมาตรฐานกลาง U2F พร้อมกับสร้างองค์กร FIDO Alliance ขึ้นมาดูแลมาตรฐาน

กระบวนการตรวจสอบนี้ทำให้ U2F ต้องมีองค์ประกอบ 3 อย่าง ได้แก่ FIDO Relying Party เป็นเซิร์ฟเวอร์ที่รองรับการยืนยันตัวตนด้วย U2F, FIDO Client ที่ในกรณีเว็บก็คือเบราว์เซอร์ที่รองรับ U2F, และ Token ที่เป็นตัวกุญแจสำหรับการยืนยันตัวตนโดยตรง

เมื่อเว็บต้องการให้ผู้ใช้ยืนยันตัวตนด้วย Token จะมีขั้นตอนดังนี้

1. เว็บจะส่งข้อมูลร้องขอให้เบราว์เซอร์ลงทะเบียน (register) ตัวเว็บเข้ากับกุญแจ เว็บจะขึ้นข้อความแจ้งผู้ใช้ขอให้เสียบ Token ใน USB (U2F รองรับช่องทางอื่นๆ ด้วย เช่น NFC และ Bluetooth) เว็บจะแจ้งชื่อของตัวเอง (App ID) พร้อมกับข้อมูลทดสอบการลงทะเบียน (challenge) ไปยังเบราว์เซอร์
2. ตัวเบราว์เซอร์เองจะตรวจสอบความถูกต้องของข้อมูลและสร้างเป็นข้อมูลแสดงตัวตนเว็บ (Client Data) จากนั้นแฮชทั้งค่า Client Data และ challenge แล้วส่งไปให้ Token
3. Token สร้างกุญแจสาธารณะสำหรับการลงทะเบียนครั้งนี้คืนให้กับเบราว์เซอร์ โดยสร้างกุญแจสาธารณะสำหรับการลงทะเบียน (public key) พร้อมกับแสดงใบรับรองดิจิตอลของผู้ผลิต (attestation certificate) ที่ติดมากับตัว Token และข้อมูลการลงทะเบียน (key handle) จากนั้น เซ็นข้อมูลทั้งหมดด้วยกุญแจลับของผู้ผลิต (attestation private key) ที่ฝังอยู่ใน Token
4. เบราว์เซอร์รับค่าจาก Token แล้วคืนค่าไปยังเว็บ โดยเพิ่มค่า client data กลับไปยังเว็บ
5. เว็บจะสามารถตรวจสอบผู้ผลิตได้จากใบรับรองดิจิตอลของผู้ผลิต หากยอมรับข้อมูลทั้งหมด ถือว่ากระบวนการลงทะเบียนเสร็จสิ้น

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

เมื่อลงทะเบียนเรียบร้อยแล้ว การยืนยันตัวตนครั้งต่อๆ ไปจะเรียกว่าการลงชื่อ (sign) เพื่อเข้าใช้งานระบบ

1. เว็บจะส่งข้อมูล key handle, App ID, และข้อมูลทดสอบ (challenge - เป็นข้อมูลคนละชุดกับตอนลงทะเบียนและเปลี่ยนไปทุกครั้งที่ยืนยันตัวตน)
2. เบราว์เซอร์จะตรวจสอบความถูกต้องของ App ID เช่น URL ที่เว็บอ้างมา ตรงกับ URL จริงที่เบราว์เซอร์เห็นหรือไม่ ขั้นตอนนี้ช่วยป้องกันการ phishing เพราะหากเป็นเว็บปลอมที่กำลังพยายามคั่นกลางการล็อกอินของเว็บอื่น
3. ตัว Token ตรวจสอบความถูกต้องของ key handle จากนั้นจึงเซ็นลายเซ็นดิจิตอลสำหรับเว็บที่ขอตรวจสอบ
4. เว็บได้รับข้อมูลกลับมา สามารถตรวจสอบลายเซ็นดิจิตอลที่ได้รับด้วยกุญแจสาธารณะที่ได้รับมาเมื่อลงทะเบียน Token ว่ายังเป็น Token เดิมหรือไม่

แนวทางการออกแบบของ U2F นั้นคำนึงถึงการอิมพลีเมนต์ในฮาร์ดแวร์ราคาถูกที่อาจจะมีหน่วยความจำแบบถาวรในตัวเพียงเล็กน้อย การที่มาตรฐานบังคับให้เซิร์ฟเวอร์ต้องส่งค่า key handle กลับมาทุกครั้ง ทำให้ตัว Token สามารถใช้ค่า key handle ในการสร้างกุญแจลับ ที่คู่กับกุญแจสาธารณะที่เว็บได้รับครั้งแรกเอง

กรณีของ Yubico ก็ใช้กระบวนการนี้ โดยจะใช้ค่าสุ่มประจำครั้งของการลงทะเบียน (nonce) มาสร้างกุญแจลับและกุญแจสาธารณะ แล้วส่งค่า nonce เป็นค่า key handle ให้เซิร์ฟเวอร์ส่งกลับมาทุกครั้ง เมื่อตัว Token ได้รับค่า nonce ในการลงยืนยันตัวตนครั้งต่อๆ ไปจึงสามารถสร้างกุญแจลับกลับมาได้โดยไม่ต้องจำไว้ว่าเว็บใดสร้างกุญแจไว้แบบใด

บทความนี้พูดถึงการออกแบบของโปรโตคอล U2F ที่ออกแบบได้อย่างน่าสนใจ แต่ที่จริงแล้วการออกแบบกระบวนการเพื่อแก้ปัญหการยืนยันตัวตนที่แข็งแกร่งและมีการป้องกัน phishing ที่ดีมีการเสนอไว้มากมาย ปัญหาสำคัญไม่ใช่การออกแบบ แต่เป็นการใช้งานที่กว้างขวาง กระบวนการยืนยันตัวตนสองขั้นตอน เช่น HOTP และ TOTP เองก็ยังไม่ได้รับความนิยมเป็นการทั่วไปเท่าที่หวังกันไว้

U2F จึงไม่ใช่เรื่องของการออกแบบเพียงอย่างเดียว แต่เป็นเรื่องของการเผยแพร่แนวทางเพื่อให้เป็นที่ยอมรับในวงกว้าง การเสนอมาตรฐานใหม่ๆ แต่กลับไม่มีผู้ให้บริการรายใหญ่เข้าร่วมทำให้ข้อเสนอจำนวนมากไม่ประสบความสำเร็จ การที่ U2F ได้รับการสนับสนุนจากกูเกิลตั้งแต่แรกทำให้ผู้ใช้ที่เป็นไปได้ (potential user) ของโปรโตคอลนี้มีจำนวนมาก ขณะที่ผู้ใช้เองก็มีเหตุผลที่จะซื้อ Token มาใช้งานกันมากขึ้นเพราะอย่างน้อยที่สุดก็สามารถใช้งานกับบริการของกูเกิลได้เป็นอย่างแรก แม้ว่าการใช้งานยังอยู่เพียงระดับเริ่มต้น บริการสำคัญๆ ที่รองรับ U2F ยังมีเพียงกูเกิลและ GitHub เราก็คงต้องเอาใจช่วยว่ามาตรฐานเช่นนี้จะได้รับความนิยมในวงกว้างกันต่อไป