กระแส Passkeys ที่ร้อนแรงเกินไปทำให้ Security Key ไร้ประโยชน์ได้อย่างไร

• หากแนวทางที่นิยามและบังคับใช้ Passkeys เป็น resident key แพร่หลายขึ้น Security Key อย่าง Yubikey, Feitian และ Nitrokey จะชนข้อจำกัดอย่างรวดเร็วเพราะพื้นที่จัดเก็บมีจำกัด
• non-resident credential มีโครงสร้างที่ Security Key ถอดรหัส credential ID ที่ Relying Party ให้มาเพื่อให้ได้ private key เฉพาะของแต่ละ RP ดังนั้นภายในอุปกรณ์จึงเก็บไว้แค่ master key
• ในทางกลับกัน resident/discoverable credential จะเก็บ private key ไว้ใน Security Key เอง จึงใช้สล็อตต่อหนึ่งบัญชี โดย Nitrokey รองรับ 8 รายการ ส่วน Yubikey โดยทั่วไปอยู่ที่ราว 20–32 รายการเท่านั้น
• Security Key ที่ใช้ CTAP2.0 ไม่สามารถลบ resident key ทีละรายการได้ ต้องรีเซ็ตทั้งหมด และในตอนนั้น master key ก็จะเปลี่ยนไปด้วย ทำให้ non-resident key เดิมใช้งานไม่ได้ไปด้วย
• หากบริการและไลบรารีบังคับใช้ resident key เป็นค่าเริ่มต้น ผู้ใช้ที่มีบัญชีมากกว่า 150 บัญชีจะต้องจัดการ Security Key หลายอันพร้อมคีย์สำรอง ทำให้เลือก authenticator ที่ต้องการได้อย่างอิสระยากขึ้น

---

เหตุผลที่ resident key เป็นแกนของปัญหา

• แก่นของความกังวลว่าความคาดหวังต่อ Passkeys ที่ร้อนแรงเกินไปอาจทำให้ Security Key กลายเป็นเหมือน อุปกรณ์ล้าสมัย อยู่ที่ resident key
• ความเข้าใจว่า Security Key รองรับจำนวนบัญชีได้เหมือน “ไม่จำกัด” ในหลายกรณีอาศัยวิธีแบบ non-resident credential
• resident key ใช้พื้นที่จัดเก็บภายใน Security Key จริง ๆ ดังนั้นเมื่อจำนวนบัญชีเพิ่มขึ้น ข้อจำกัดของอุปกรณ์ก็จะปรากฏทันที

วิธีทำงานของ non-resident credential

• ใน non-resident credential ขณะยืนยันตัวตน Relying Party จะส่ง credential ID ผ่านเบราว์เซอร์ไปยัง Security Key
• credential ID คือ blob ที่เข้ารหัสไว้ซึ่งมีเพียง Security Key เท่านั้นที่ถอดรหัสได้ และผลลัพธ์หลังถอดรหัสคือ private key เฉพาะสำหรับ Relying Party นั้น
• Security Key ใช้ private key ที่ถอดรหัสได้ลงนาม challenge แล้วส่งลายเซ็นกลับไปยังเบราว์เซอร์และ Relying Party
• ในโครงสร้างนี้ private key ไม่ได้พำนักอยู่ใน secure enclave และภายใน Security Key มีเพียง master key
• credential ID ถูกเข้ารหัสด้วย AES-128 และใช้ HMAC ทำให้ถูกประเมินว่ายากต่อการแก้ไขหรือถอดรหัสจากภายนอก
  • มีการเปรียบเทียบว่า หาก AES-128 ถูกเจาะจนสามารถถอดรหัส private key ได้โดยไม่ต้องมี Security Key การเข้ารหัส TLS หรือ SSH ก็จะถูกโจมตีได้ในระดับเดียวกัน

ความแตกต่างของ resident/discoverable credential

• resident key หรือ discoverable credential คือวิธีที่ private key ถูก เก็บไว้ภายใน Security Key
• เมื่อ Relying Party ส่งรายการ credential ID ว่างมา Security Key จะค้นหาและเลือกคีย์ที่ใช้กับ RP นั้นได้ แล้วจึงลงนาม
• โครงสร้างนี้ไม่พึ่งพาวิธีรับ credential ID จากภายนอกแล้วถอดรหัสด้วย master key
• แต่ credential แต่ละรายการจะกินพื้นที่ภายใน Security Key ทำให้จำนวนสล็อต resident key กลายเป็นข้อจำกัดจำนวนบัญชีที่แท้จริง

userVerification แยกจาก resident key

• มีความสับสนว่า credential ต้องเป็น resident เสมอจึงจะบังคับ userVerification ได้ แต่สองแนวคิดนี้แยกจากกัน
• Security Key ไม่เพียงตรวจ presence ด้วยการแตะเท่านั้น แต่ยังสามารถตรวจสอบ PIN หรือไบโอเมตริกภายในเพื่อยืนยันว่าเป็นผู้ใช้จริงได้
• พฤติกรรมนี้ถูกควบคุมด้วย userVerification flag และทำงานแยกจาก key residency
• ดังนั้นแม้ไม่ใช่ resident key อุปกรณ์ก็ยังใช้เหมือน authenticator หลายปัจจัยด้วยตัวเองได้

พื้นที่จัดเก็บของ Security Key และข้อจำกัด CTAP

• เพราะ resident key ถูกเก็บไว้ภายในอุปกรณ์ จำนวนสล็อตของ Security Key จึงสำคัญ
  • Nitrokey รองรับ resident key 8 รายการ
  • Yubikey โดยทั่วไปรองรับ 20–32 รายการ
  • คีย์บางรุ่นไม่รองรับ resident key เลย
• มาตรฐาน CTAP ที่ Security Key นำไปใช้ก็มีผลอย่างมากต่อความสามารถในการจัดการ
  • CTAP2.1 และ CTAP2.1PRE สามารถจัดการ อัปเดต และลบ resident key ทีละรายการได้
  • CTAP2.0 ต้องรีเซ็ตอุปกรณ์ทั้งหมดหากต้องการลบ resident key
• การรีเซ็ตอุปกรณ์ CTAP2.0 จะรีเซ็ต master key ไปด้วย ทำให้ non-resident key เดิมไม่ทำงานอีกต่อไป
• Security Key จำนวนมากมีความเป็นไปได้สูงว่าจะเป็น CTAP2.0 และในกรณีของ Yubico เวอร์ชัน CTAP จะขึ้นอยู่กับเวอร์ชันเฟิร์มแวร์

ชื่อ passkeys และการแพร่หลายของนิยาม resident key

• ในปี 2022 Apple ประกาศฟีเจอร์ passkeys บน macOS/iOS ที่ใช้ Touch ID และ Face ID เหมือน WebAuthn authenticator
• ชื่อ passkeys ถูกมองว่าเป็นชื่อที่เป็นมิตรกับผู้ใช้มากกว่า “webauthn authenticator” หรือ “security key”
• หลังจากนั้น มีการตีความหลายแบบเกิดขึ้นในขณะที่ความหมายของ passkeys ยังไม่ได้ถูกตรึงไว้อย่างชัดเจน
  • ไลบรารี Rust WebAuthn และผู้พัฒนา Relying Party นิยาม passkeys ว่าเป็นชื่อของ authenticator ทุกชนิดที่ผู้ใช้เลือกได้
  • สมาชิกบางส่วนในชุมชนเรียก passkeys ว่า credential ที่ซิงก์ระหว่างหลายอุปกรณ์
  • ในงานประชุม FIDO Authenticate มีนิยามว่า “passkey คือ resident key” ปรากฏขึ้น และต่อมา FIDO ก็ใช้คำจำกัดความนี้ใน FAQ
• เหตุผลหนึ่งที่นิยาม resident key ได้รับความสนใจคือมันเชื่อมโยงกับ conditional UI ซึ่งเป็นฟีเจอร์ที่เบราว์เซอร์วางแผนไว้
  • หาก credential เป็น resident key จะสามารถเติมชื่อผู้ใช้และ WebAuthn credential แบบอัตโนมัติได้
  • มอบประสบการณ์ที่ผู้ใช้ไม่ต้องกรอกชื่อผู้ใช้เอง

ปัญหาผู้ใช้ที่เกิดจากการบังคับใช้ resident key

• หากไลบรารี WebAuthn ชักนำให้ทุกการลงทะเบียนต้องใช้ resident key Security Key ที่มีพื้นที่จัดเก็บจำกัดอาจเต็มอย่างรวดเร็ว
• ตัวอย่างเช่น หากใน password manager มีรหัสผ่านที่บันทึกไว้มากกว่า 150 รายการ การเปลี่ยนทั้งหมดเป็น resident key จะต้องใช้ Yubikey อย่างน้อย 5 อัน
• หากพิจารณาการสำรองด้วย อาจต้องจัดการ Yubikey 10–15 อัน
• สิ่งนี้จะกลายเป็นประสบการณ์ผู้ใช้ที่แย่สำหรับผู้ที่เลือก Security Key และข้อกำหนด resident key ของ passkeys อาจทำให้การใช้ Security Key เองยากขึ้น
• ในการทำการตลาดคีย์ที่ได้รับการรับรอง FIDO มีการใช้ข้อความอย่าง “พื้นที่เก็บ key pair ไม่จำกัด” หรือ “ไม่จำกัดจำนวนบัญชีที่ลงทะเบียน” แต่แม้จะถูกต้องสำหรับ non-resident key ก็ขัดแย้งกับข้อกำหนด resident key
• หนึ่งในเป้าหมายของ WebAuthn Work Group คือให้ผู้ใช้เลือก authenticator ที่ต้องการได้อย่างอิสระโดยไม่เสียเปรียบ แต่การบังคับ resident key ไม่สอดคล้องกับเป้าหมายนี้
• ประเภท authenticator ที่ถูกเสนอว่าน่าจะทำงานได้เหมาะสมในสภาพแวดล้อม passkey ได้แก่ Apple passkeys, Android passkeys, password manager ที่รองรับ WebAuthn, Windows ที่ใช้ TPM 2.0 และเบราว์เซอร์บน Chromium ของ macOS ที่ใช้ Touch ID เหมือน TPM

แนวทางรับมือที่เป็นไปได้

• มีแนวทางหนึ่งคือเปลี่ยนพฤติกรรม rk=preferred เพื่อไม่สร้าง resident key บน Security Key
  • ปัจจุบัน Relying Party สามารถระบุระดับคำขอ resident key ได้เป็นหนึ่งใน discouraged, preferred, required
  • ปัจจุบัน rk=preferred สร้าง resident key แม้กับ Yubikey ซึ่งเป็น roaming authenticator และผลลัพธ์จึงคล้ายกับ rk=required
  • หากผ่อน preferred ให้หมายถึง “สร้าง resident key เฉพาะเมื่อพื้นที่จัดเก็บไม่จำกัด” Android/iOS จะสร้าง resident key ได้ ขณะที่ไม่กินพื้นที่จัดเก็บของ Security Key
  • WebAuthn WG ยังต่อต้านการเปลี่ยนแปลงนี้ และหากเบราว์เซอร์จะทำเอง ในทางปฏิบัติก็ขึ้นอยู่กับการตัดสินใจของทีม Chrome
• อีกวิธีคือกำหนดให้ไลบรารี passkey ใช้ rk=discouraged
  • rk=required อาจกีดกัน Security Key
  • rk=discouraged อาจทำให้ผู้ใช้ Android ไม่ได้ conditional UI
  • แต่เนื่องจากชื่อผู้ใช้มีวิธีเติมอัตโนมัติอยู่แล้ว จึงเป็นการตัดสินว่าดีกว่าการกีดกัน Security Key
• อีกแนวทางคือขอให้ FIDO กำหนดพื้นที่จัดเก็บ resident key เป็นคุณสมบัติที่ต้องมีในการรับรอง
  • ปัจจุบัน FIDO ไม่ได้บังคับปริมาณพื้นที่จัดเก็บสำหรับอุปกรณ์ที่ได้รับการรับรอง
  • หาก FIDO ต้องการ resident key ก็ควรกำหนดให้อุปกรณ์ที่ได้รับการรับรองสามารถเก็บ resident key ได้หลายพันรายการ

สรุป

• กระแสที่ร้อนแรงเกินไปในการมอง passkeys เป็น resident key อาจขัดขวางหรือทำให้ผู้ใช้ Security Key เลือก authenticator ที่ต้องการบนโลกออนไลน์ได้ยากอย่างมาก
• ปัญหาไม่ได้อยู่ที่ passkeys เองเท่าไรนัก แต่อยู่ที่การนำ ข้อกำหนด resident key ไปใช้แบบเหมารวมกับ Security Key ที่มีพื้นที่จัดเก็บและความสามารถในการจัดการจำกัด

[GN⁺]

ความคิดเห็นจาก Hacker News

• แม้จะเป็นคนละประเด็นกับตัวการเข้ารหัสเองเล็กน้อย แต่แม่ของผมโทรมาด้วยอาการตื่นตระหนกเพราะเข้า Gmail ไม่ได้ ปรากฏว่า Google ลงทะเบียน Passkey ให้กับโทรศัพท์ Android เครื่องใหม่โดยอัตโนมัติ และเปลี่ยนมันเป็นวิธีล็อกอินหลัก ซึ่งหน้าตาอินเทอร์เฟซก็ชวนสับสนมาก
  ผมคิดว่ามันมากเกินไปที่จะคาดหวังให้ผู้ใช้ต้องกดตัวเลือกที่สองหากอยากล็อกอินด้วยรหัสผ่าน หรือคาดหวังให้เข้าใจว่า passkey คืออะไร เขาบอกว่า “ส่ง passkey ไปยัง Android แล้ว” แต่บนโทรศัพท์กลับไม่มีการแจ้งเตือน และนั่งดูอยู่ 30 นาทีก็ยังแก้ไม่ได้ อีกทั้งยังลบ passkey ที่ถูกลงทะเบียนอัตโนมัติไม่ได้ และปิดขั้นตอนยืนยันตัวตนหลักนี้ก็ไม่ได้ UX ของ Google แย่มาก และการไปเชื่อถือ Android ที่ถูกดัดแปลงบนโทรศัพท์ Samsung รุ่นล่างให้เป็นฐานของระบบยืนยันตัวตนขนาดใหญ่แบบนี้ก็ดูเป็นการตัดสินใจที่โง่เขลา

  • ปัญหาเดียวกันนี้เกิดกับ การยืนยันตัวตนแบบ 2 ขั้นตอน ของ Google ด้วย มันขึ้นว่า “เราได้ส่งการแจ้งเตือนไปยัง S21 แล้ว” แต่ในความเป็นจริง ต่อให้ถือ S21 ที่ปลดล็อกอยู่ในมือ ก็ยังมีประมาณ 1 ใน 3 ครั้งที่การแจ้งเตือนไม่มาเลย หรือกว่าจะมาก็ 5 นาทีให้หลัง
    นี่เป็นแค่หนึ่งในหลายปัญหาที่เจอกับ Google ช่วงหลัง ๆ แต่ก่อนอาจพยายามเลี่ยงแบบคร่าว ๆ เพราะเรื่องความเป็นส่วนตัว แต่ตอนนี้ผมทุ่มเต็มที่เพื่อลดการใช้ Google ให้มากที่สุดแล้ว ธุรกิจของผมถูกถอดออกจาก Google Maps โดยไม่มีเหตุผล แล้วกว่าจะลงทะเบียนกลับเข้าไปใหม่ได้ก็ใช้เวลา 2 สัปดาห์ และเป็นไปไม่ได้เลยที่จะคุยกับคนจริง ๆ อีเมลซัพพอร์ตแต่ละฉบับให้เบอร์โทรมา แต่เบอร์นั้นเป็นฝ่ายสนับสนุนโฆษณา ซึ่งช่วยอะไรกับบัญชีธุรกิจที่ถูกระงับไม่ได้เลย และยังไม่ยอมเชื่อด้วยซ้ำว่าทีม Google Business เป็นคนให้เบอร์นั้นมาในฐานะช่องทางซัพพอร์ต ผมต้องถามซ้ำอยู่ 30 นาที กว่าพนักงานฝ่ายสนับสนุน Google Ads จะยอมรับว่าไม่มีทางคุยกับคนจากฝั่ง Google Business ได้ ตอนนี้ผมเลยกลายเป็น นักเผยแพร่แนวคิดต่อต้าน Google ไปแล้ว
  • ผมกำลังคิดจริงจังว่าจะย้ายธุรกิจออกจาก ecosystem ของ Google เพราะเจอคำขอยืนยันตัวตนแบบ “เราได้ส่งการแจ้งเตือนไปยังโทรศัพท์ของคุณแล้ว” ทั้งที่ไม่ต้องการ ถ้าจู่ ๆ มีการล็อกอินจากอีกฟากโลก หรือปกติใช้ Linux แต่เบราว์เซอร์ถูกระบุว่าเป็น Windows ก็ยังพอเข้าใจได้ แต่ถ้าใช้ ungoogled chromium ซึ่งเป็นเบราว์เซอร์สายความเป็นส่วนตัว เรื่องนี้จะเกิดทุกครั้งที่ยืนยันตัวตน แม้อยู่ IP เดิมก็ตาม
    แล้วถ้าแบตโทรศัพท์หมดล่ะ? ถ้าทำโทรศัพท์หายและต้องกู้ข้อมูลรับรองของบริการระบุตำแหน่งโดยการส่งรีเซ็ตรหัสผ่านมาทางอีเมล แต่กลับล็อกอินอีเมลไม่ได้ล่ะ? จากนั้นก็เข้าสู่ขั้นตอน “ตอบคำถาม” ทันที อัลกอริทึมลึกลับที่ไม่มีใครรับผิดชอบตัดสินว่า ungoogled chromium บน Linux น่าสงสัย และถ้าคุณจำคำตอบอย่าง “ตอนนี้ใช้พื้นที่จัดเก็บอยู่กี่เปอร์เซ็นต์?” ผิด ก็เหลือแต่หวังพึ่งโชคในการกู้บัญชี อนึ่ง ผมเป็นผู้ใช้ Google แบบเสียเงิน
  • ขอแก้ไขเล็กน้อย: passkey ไม่ได้ถูก “ส่ง” ไปยัง Android จริง ๆ การล็อกอิน Gmail เป็นการสแกน QR code ที่แสดงในเบราว์เซอร์ เพื่อพิสูจน์ว่า Android ถือครอง passkey อยู่
    ถึงอย่างนั้นก็เข้าใจประเด็นทั้งหมด UX กับศัพท์ที่ใช้ก็ยังชวนงง แม้แต่ละขั้นตอนจะมีคำอธิบาย แต่คนส่วนใหญ่มักถูกฝึกให้ข้ามข้อความตัวเล็ก ๆ โดยเฉพาะตอนรีบ ๆ แล้วไปกดปุ่มที่ใหญ่และเด่นที่สุดแทน จึงแทบไม่ช่วยอะไร นี่เป็นปัญหาที่ยากมากในเชิงการออกแบบ UX
  • หลังเจอเรื่องนี้ ผมก็หมดความอดทนแล้ว มันทำให้ตระหนักว่า Google ไม่ได้ตัดสินใจโดยยึดผู้ใช้เป็นศูนย์กลาง พวกเขาหารายได้จากผู้ลงโฆษณา และให้บริการเพียงเท่าที่จะทำให้ผู้ใช้ยังไม่หนีไป พร้อมรักษาระดับไว้แค่พอจะกันคู่แข่งได้
    ตราบใดที่ผู้ใช้ยังไม่ย้ายออก Google ก็ไม่แคร์ และก็ไม่จำเป็นต้องแคร์ด้วย ถ้าต้องการอย่างอื่น คุณก็ต้องมีบริการที่ผู้ลงโฆษณาไม่ได้เป็นคนจ่ายเงินให้ ถ้า Google เอาเปรียบผู้ใช้แบบหนึ่ง Apple ก็แค่เอาเปรียบอีกแบบหนึ่ง การเลือกพิษไม่ใช่ทางเลือกจริง ๆ
  • ถ้ามองอย่างเป็นธรรม นี่ไม่ใช่ปัญหาของ passkey เอง แต่ใกล้เคียงกับการที่ UX ของผลิตภัณฑ์ Google มันแย่เสียมากกว่า ถ้า Google เปลี่ยน UX การล็อกอินอย่างฉับพลันไปเป็นรูปแบบที่ผู้ใช้ไม่คุ้นเคย คนส่วนใหญ่ก็ต้องสับสนเป็นธรรมดา

• เพราะ Apple ไม่ได้ให้นิยามไว้อย่างชัดเจน ผู้คนสายคิดวิเคราะห์จึงเข้ามาเติมช่องว่างให้กับผู้ใช้ที่อยากรู้ว่า “ตกลงแล้ว passkey คืออะไรกันแน่?”
  เดิมผมเข้าใจว่า Apple นิยาม passkey ว่าเป็นคู่กุญแจที่ซิงก์ผ่าน iCloud Keychain ในงาน WWDC 2021 Apple ก็แยก passkey ออกจาก security key โดยบอกว่า passkey คือสิ่งที่ “คุณมีติดตัวเสมอ” กล่าวคือมีการซิงก์ข้ามอุปกรณ์และ “กู้คืนได้” หลังจากนั้นดูเหมือนนิยามจะขยายไปครอบคลุมวิธีซิงก์ผ่านคลาวด์แบบอื่นด้วย ผมคิดว่าบทความนี้เสนอการประนีประนอมที่ผิดพลาด security key ไม่ใช่ประเด็นสำคัญ[1] เพราะมีแค่ผู้ใช้สายเทคนิคจำนวนน้อยมากกับบริษัทไม่กี่แห่งที่ให้ความสำคัญกับความปลอดภัยจริงจังเท่านั้นที่ใช้มัน ถ้าต้องการยกระดับความปลอดภัยของเว็บ เราต้องพาคนออกจากรหัสผ่านให้ได้ และประชากร 99% จะไม่ใช้ security key ถ้าไม่ถูกบังคับ Passkey มีโอกาสแทนที่รหัสผ่านได้จริง โดยเฉพาะเพราะการผสานเข้ากับระบบปฏิบัติการอย่างลึกซึ้ง เราไม่ควรปรับระบบยืนยันตัวตนให้เหมาะกับผู้ใช้ไม่ถึง 1% เพียงเพราะพวกเขามีช่องเก็บ resident key ไม่พอ [1] ผมมี Yubikey 3 อัน, Yubico security key 3 อัน และ SoloKey 1 อัน

  • เป้าหมายไม่ใช่ผลิตภัณฑ์ Apple Passkey แต่เป็น initiative ระดับอุตสาหกรรม เมื่อถึงช่วงเปิดตัวในปี 2022 นิยามก็ผ่อนคลายลง กลายเป็นสิ่งที่ใกล้เคียงกับ “ประสบการณ์” ที่ยกตัวอย่างได้ว่า ต้องค้นพบได้และมีตัวเลือกการยืนยันผู้ใช้
    ผู้ใช้สามารถเลือกได้ว่าจะใช้ผู้ให้บริการ passkey ที่สำรองและกู้คืนได้หรือไม่ และฝ่ายที่เชื่อถือข้อมูลนี้ก็จะได้รับสัญญาณดังกล่าว พวกเขาอาจใช้สัญญาณนี้เพื่อตัดสินใจว่าจะเสนอให้ลบตัวเลือกล็อกอินด้วยรหัสผ่านหรือไม่
  • จริง ๆ แล้ว passkey ถูกนิยามโดย FIDO Alliance
    ตามมาตรฐานของ FIDO passkey เป็นสิ่งที่มาแทนรหัสผ่าน และช่วยให้ผู้ใช้ล็อกอินเข้าเว็บไซต์และแอปได้เร็วขึ้น ง่ายขึ้น และปลอดภัยขึ้นบนอุปกรณ์หลายเครื่องของตน ต่างจากรหัสผ่าน passkey จะแข็งแกร่งเสมอและต้านทานการฟิชชิงได้ https://fidoalliance.org/passkeys/

• ไม่เข้าใจว่าทำไม rk=required ถึงมีอยู่ตั้งแต่แรก มันไม่ควรเป็นตัวเลือกด้วยซ้ำ
  เรื่องแบบนี้นี่แหละที่ทำให้ผมกังวลและมอง Passkeys กับผู้เกี่ยวข้องอย่างสงสัยมาตลอด คนพวกนี้มีหน้าที่ต้องออกแบบโปรโตคอลไม่ให้กลายเป็นเครื่องมือที่บริษัทยักษ์ใหญ่อย่าง Microsoft ใช้กับ แนวปฏิบัติทางการตลาดที่มุ่งร้าย ซึ่งทำลายทั้งความปลอดภัย ความเข้ากันได้ และการแข่งขันได้ง่าย ๆ แต่ท่าทีที่เห็นซ้ำ ๆ ในบทความและโพสต์ต่าง ๆ กลับใกล้เคียงกับ “ช่างแม่ง เราจะทำให้การนำไปใช้ในทางที่ผิดง่ายขึ้นอีก” ไม่ใช่แค่ปัญหาเรื่อง resident key เท่านั้น เช่น วิธีจัดการ attestation เองก็อาจถูกนำไปใช้ทำลายบริษัทต่าง ๆ ได้ง่ายเช่นกัน

  • เป้าหมายนี่ดูเหมือนจะเป็นการทำให้โทรศัพท์กลายเป็น passkey และ ไม่ให้ใช้อย่างอื่นอีกเลย พอมองจากมุมนั้น ทุกอย่างในบทความก็สมเหตุสมผลขึ้นมา
  • ผมมองว่าอันนี้ยังแย่น้อยกว่าการนำ attestation ไปใช้ในทางที่ผิด
    ถ้าบริการไหนตั้ง rk=required ไว้ แต่แพลตฟอร์มไม่อยากเปิด ใช้ไม่ได้ หรือไม่รองรับ ขั้นตอนทั้งหมดก็น่าจะล้มเหลวเสมอจนลงทะเบียนไม่ได้เลย ถ้าเป้าหมายคือพาผู้ใช้เข้าระบบและขยายธุรกิจ มันก็ดูเหมือนเป็นการยิงเท้าตัวเอง
  • สงสัยว่า “วิธีจัดการ attestation อาจถูกนำไปใช้ทำลายบริษัทต่าง ๆ ได้ง่าย” นี่หมายถึงปัญหาอะไร

• ผมไม่ได้อยู่สาย security หรือ crypto เลย เลยตามบทความนี้ได้ยากมาก และคิดว่าคนอื่นก็น่าจะเป็นเหมือนกัน
  สำหรับคนที่มีพื้นความรู้พอ คำถามพวกนี้อาจดูแปลก แต่ผมติดแทบทุกหนึ่งหรือสองประโยค ไม่เข้าใจว่า “สุดท้ายแล้วทุกอย่างก็ลงเอยที่ resident key” ได้อย่างไร ทำไมถึงเป็นแบบนั้น และมันเชื่อมกับ passkey หรือ HSM ยังไง ประโยคที่ว่า “ต้องเข้าใจก่อนว่า discoverable/resident key คืออะไร” ก็ยังไม่ชัดว่าหมายถึง resident key ทุกอันคือ discoverable key, discoverable key ทุกอันคือ resident key หรือทั้งสองอย่าง ประโยคที่ว่า “คุณคงเคยเห็นแล้วว่าคีย์ส่วนใหญ่รองรับบัญชีได้ ‘ไม่จำกัด’” ก็ไม่รู้ว่าคำว่า key ตรงนี้หมายถึง passkey, คีย์ที่เก็บใน HSM หรือทั้งคู่ ส่วน “ส่งคีย์ที่ถูกห่อไว้ไปยัง security key” ก็ทำให้งงอีก ว่านี่หมายถึง HSM ใช้กับบัญชีได้ไม่จำกัดเพราะมันเก็บคีย์บางตัวโดยห่อด้วยอีกคีย์หนึ่งได้หรือเปล่า

  • ประเด็นหลักดูเหมือนจะเป็นว่า WebAuthn กำลังถูกผลักไปสู่ โมเดล passkey ที่แต่ละเว็บไซต์สร้างข้อมูลรับรองที่กินพื้นที่จัดเก็บ ชื่อเว็บไซต์ที่แสดงได้ ชื่อบัญชีผู้ใช้ user record handle private key และข้อมูลอื่น ๆ ล้วนใช้พื้นที่ทั้งนั้น
    โทรศัพท์เครื่องหนึ่งเก็บ passkey ได้เป็นหมื่นอันก็ไม่มีปัญหา แต่ hardware key รุ่นใหม่อาจมีแฟลชที่เก็บได้รวมเพียง 25 รายการ เหตุผลที่ต้องใช้พื้นที่นี้ก็คือเรื่อง discoverability เช่น ในหน้าเข้าสู่ระบบของ GitHub.com ถ้ากดรองรับ passkey แบบใหม่ คุณอาจล็อกอินได้โดยไม่ต้องกรอกชื่อบัญชีเลย เบราว์เซอร์จะมอบประสบการณ์คล้ายตัวจัดการรหัสผ่าน และ passkey ก็กลายเป็นเรคคอร์ดของบัญชีเว็บไซต์บนเครื่องเหมือนรหัสผ่านใน password manager แต่ใน WebAuthn ยังมีโหมดอื่นที่ไม่ใช่ passkey ด้วย ข้อมูลรับรองแบบ non-discoverable ต้องอาศัยการส่งรายการ handle สำหรับบัญชีผู้ใช้ที่ระบุมาให้ และ handle นี้ก็คือสิ่งที่คีย์ส่งกลับมาตอนลงทะเบียน ตอนยืนยันตัวตนก็จะแสดงเฉพาะข้อมูลรับรองที่ตรงกับ handle เท่านั้น hardware security key อาศัยจุดนี้โดยเก็บเรคคอร์ดที่ต้องใช้ในการคำนวณเข้ารหัสภายหลังไว้ในตัว handle เอง ซึ่งโหมดนี้ไม่ใช้พื้นที่แฟลชเลย เมื่อผู้ใช้กรอกชื่อผู้ใช้ API บางตัวก็จะคืนรายการ handle กลับมา แล้วนำไปใช้กับ security key เพื่อยืนยันตัวตนได้โดยไม่ติดข้อจำกัดด้านพื้นที่เก็บข้อมูล อย่างไรก็ตาม หลายเว็บไซต์มีนโยบายไม่เปิดเผยว่าบัญชีมีอยู่หรือไม่ คุณคงเคยเห็นขั้นตอนกู้คืนแบบ “ถ้าบัญชีนี้มีอยู่ คุณจะได้รับอีเมลในไม่ช้า” การที่ขั้นตอนล็อกอินเปิด API ให้ตรวจจับได้ว่ามีบัญชีที่ผูกกับชื่อผู้ใช้หรืออีเมลนั้นอยู่หรือไม่ และมีข้อมูลรับรองถูกบันทึกไว้กี่รายการ อาจเป็นสิ่งที่เว็บไซต์ยอมรับได้ยาก ดังนั้นแทนที่จะให้เว็บไซต์ต่าง ๆ รับเอาวิธีนี้ไปใช้กันอย่างแพร่หลายจนกระทบข้อจำกัดฮาร์ดแวร์ในปัจจุบัน ดูมีแนวโน้มมากกว่าว่าเราจะได้เห็น security key ที่มีพื้นที่เก็บข้อมูลมากขึ้น 10 เท่า
  • เห็นด้วยว่าข้อโต้แย้งในบทความไม่ค่อยดีนัก ประเด็นหลักคือการอ้างว่าความสามารถที่ฝ่าย relying party ระบุ rk=required ได้ในโปรโตคอล WebAuthN นั้นเป็นอันตราย เพราะมันทำให้ ฮาร์ดแวร์ TPM จำนวนมากทำงานเป็นกระเป๋าเก็บ passkey หรือฐานข้อมูลไม่ได้
    ผมคิดว่าคนส่วนใหญ่ในคอมเมนต์น่าจะเห็นด้วยกับจุดนี้ แต่ก็ไม่ได้แปลว่าความสับสนที่ผู้เขียนสร้างขึ้นจากการใช้บทความไปครึ่งหนึ่งถกเรื่องนิยามของ passkey จะเป็นเรื่องที่สมเหตุสมผล
  • บทความนี้ตั้งอยู่บนสมมติฐานว่าผู้อ่านมีความรู้เรื่อง FIDO2 พอสมควร เลยไม่แปลกที่จะสับสน
    passkey ถูกนำไปใช้งานบน FIDO2 และโดยเฉพาะอย่างยิ่งใช้ความสามารถ resident key ในสเปก FIDO2 อุปกรณ์ยืนยันตัวตนแบบฮาร์ดแวร์ของ FIDO2 ไม่ได้เป็น HSM แบบตรงตัว แต่ก็ใกล้เคียงกัน และก็มีอุปกรณ์อย่าง Yubikey ที่เป็นทั้ง HSM และอุปกรณ์ยืนยันตัวตน FIDO2 ใน FIDO2 คำว่า “resident key” กับ “discoverable key” หมายถึงสิ่งเดียวกัน สเปกใช้คำว่า “resident key” แต่ “discoverable key” ก็เป็นคำที่ใช้กันบ่อย และเป็นหนึ่งในชุดคำศัพท์ชวนสับสนที่ FIDO สร้างไว้ คำว่า “key” ตรงนี้ไม่ได้หมายถึง passkey หรือคีย์ที่เก็บใน HSM แต่หมายถึงอุปกรณ์ยืนยันตัวตนแบบฮาร์ดแวร์ FIDO2 อย่าง Yubikey ซึ่งมักเรียกรวม ๆ ว่า “security key” อุปกรณ์ยืนยันตัวตนฮาร์ดแวร์ FIDO2 สามารถลงทะเบียนกับบัญชีได้ไม่จำกัดแทบจะจริง เพราะถ้าไม่ใช้ resident key มันก็แทบไม่มีสถานะและไม่ต้องเก็บอะไรไว้เลย ตอนลงทะเบียนกับบัญชี อุปกรณ์จะสร้างคู่กุญแจอย่าง EdDSA ขึ้นมา แต่จะไม่เก็บไว้ โดยจะเข้ารหัส private key ด้วย master key ที่ฝังอยู่ในอุปกรณ์ เช่นคีย์ AES256 จากนั้นก็ส่ง public key แบบ plaintext พร้อม private key ที่เข้ารหัสแล้วไปให้ relying party อย่าง google.com เก็บไว้ ตอนยืนยันตัวตน private key ที่เข้ารหัสแล้ว หรือก็คือคีย์ที่ “ถูกห่อไว้” จะถูกส่งกลับมายังอุปกรณ์ยืนยันตัวตน แล้วถอดรหัสภายในอุปกรณ์เพื่อใช้สร้างลายเซ็นดิจิทัล อย่างไรก็ตาม FIDO2 ไม่ได้กำหนดจริง ๆ ว่าต้องทำ non-resident key อย่างไร และ wrapped key ก็เป็นเพียงวิธีหนึ่งเท่านั้น FIDO2 เพียงกำหนดว่า private key ต้องสามารถอนุมานอย่างปลอดภัยได้จาก credential ID โดย credential ID อาจเป็น wrapped key หรือจะเป็นข้อมูลสุ่มอย่างอื่นก็ได้

• ดูเหมือนจะมองสถานการณ์ในแง่ลบเกินไป ถ้าอยากได้ประโยชน์จากมาตรฐานการยืนยันตัวตนแบบใหม่ที่ช่วยกำจัดรหัสผ่านอ่อนแอและการใช้รหัสผ่านซ้ำ จนป้องกันการถูกยึดบัญชีในชีวิตประจำวันได้ 99% ก็อาจมองได้ว่าแค่ต้องจ่าย 30 ดอลลาร์เพื่ออัปเกรดจาก Yubikey รุ่นเก่า ที่ใช้งานมาตั้งแต่ปี 2013

  • ไม่เข้าใจว่าทำไมต้องถูกบังคับให้อัปเกรดด้วย resident key ก็ช่วยกำจัดรหัสผ่านอ่อนแอและการใช้รหัสผ่านซ้ำได้อยู่แล้ว ส่วน resident key เพิ่มขึ้นมาแค่ข้อปรับปรุงเล็กน้อยคือเมื่อเสียบกุญแจแล้วบริการจะรู้ว่าเป็นของบัญชีไหน ซึ่งดูไม่ใช่เหตุผลที่ดีพอจะให้ทิ้งอุปกรณ์ยืนยันตัวตนเดิมที่ใช้อยู่ทั้งหมด
  • ดูจากคู่มือเทคนิคของซีรีส์ 5 แล้ว รองรับได้แค่ 25 รายการ ตอนนี้ผมมีแค่ 2 แต่ TOTP มีมากกว่า 25 มาก
    ไม่แน่ใจว่าโมเดล Bio FIDO เป็นอย่างไร แต่ถ้าคล้ายกัน YubiCo อาจไม่มีผลิตภัณฑ์ที่เหมาะกับ resident key จำนวนมาก แก้ไข: Bio ก็จำกัดที่ 25 เหมือนกัน
  • ผมว่าจริง ๆ แล้วนี่ยังเป็นการตีความแบบใจดีเกินไปด้วยซ้ำ
    resident key แบบที่แชร์กันไม่ควรมีอยู่เลย ยกเว้นการใช้งานชั่วคราวระยะสั้น เพราะมันสร้างภาระด้านความรับผิด เพิ่มความเสี่ยงด้านความปลอดภัย และส่งเสริมแนวปฏิบัติด้านความปลอดภัยที่ไม่ดี ตัวอย่างที่ชัดที่สุดคือ TOTP ซึ่งมีข้อบกพร่องมากในมุมมองความปลอดภัย คุณไม่ควรอยากแชร์หรือสำรอง shared secret ข้ามหลายอุปกรณ์ แต่เพราะมันทำได้ และเพราะการทำ 2FA แบบหละหลวมกลายเป็นมาตรฐานแทนที่จะเป็นข้อยกเว้น จึงเหมือนถูกบังคับให้ทำแบบนั้น จากแนวโน้มตอนนี้ passkey ก็ดูเหมือนจะมุ่งไปในทิศทางเดียวกันที่มีข้อบกพร่องและไม่เป็นมิตรกับผู้ใช้
  • ถึงอย่างนั้นก็ไม่ได้ต่างมากนัก กุญแจของผมเก็บ resident key ได้แค่ 25 รายการ แต่รหัสผ่านที่เก็บในตัวจัดการรหัสผ่านมีมากกว่า 25
  • ผมกังวลว่าในอนาคตเราอาจไม่มีทางเลือกนอกจากต้องรับ "ข้อดี" นี้ ถ้าเว็บไซต์นำมาตรฐานการยืนยันตัวตนแบบใหม่นี้ไปใช้ จะยังคงมีชื่อผู้ใช้/รหัสผ่าน/2FA แบบปัจจุบันเป็นทางเลือกต่อไปหรือไม่?

• การยืนยันตัวตนที่อิงกับ "สิ่งที่คุณมีอยู่แต่ก็อาจทำหายได้" นั้นพังตั้งแต่รากฐาน ถ้าทำอุปกรณ์หายก็เสียสิทธิ์การเข้าถึง หรือไม่ก็ต้องมีจุดอ่อนที่สุดอยู่ที่อื่นอยู่ดี ทำให้ความปลอดภัยอันยอดเยี่ยมนั้นหมดความหมาย

  • ก็พิมพ์ backup code เก็บไว้ หรือเพิ่ม กุญแจสำรองในลิ้นชัก อีกดอกก็ได้ แนวคิดนี้ยอดเยี่ยมอยู่แล้ว แต่การตลาดแย่มาก ขั้นตอนการตั้งค่าสำหรับผู้ใช้ทั่วไปก็ดูประหลาด และการผลักดันกุญแจที่ AirDrop ได้หรือซิงก์ผ่านคลาวด์ได้ก็เป็นความคิดที่ไม่ดี ปัญหาสำคัญที่สุดคือราคาของกุญแจ
  • รหัสผ่านก็เข้าข่ายนี้เหมือนกันไม่ใช่หรือ? คนเราก็ลืมรหัสผ่านกันบ่อย
    เดี๋ยวผลลัพธ์ก็คงพิสูจน์เอง แต่ถ้า passkey ถูกนำไปใช้อย่างแพร่หลาย ผมคิดว่าสำหรับคนส่วนใหญ่การถูกล็อกบัญชีจะเกิดน้อยลง ไม่ใช่มากขึ้น

• สงสัยว่าทำไมพื้นที่เก็บข้อมูลของ hardware key ถึงจำกัดขนาดนี้ ถ้าจะใส่ สตอเรจความจุสูง ที่ secure processor เข้าถึงได้เข้าไปด้วย ต้นทุนจะเพิ่มอีกสักเท่าไร
  แน่นอนว่าสตอเรจความจุสูงนี้ต้องถูกเข้ารหัสอย่างแน่นหนาโดย secure processor และเมื่อทุกอย่างถูกลบ กุญแจนั้นก็ควรถูกลบไปพร้อมกัน

  • เพราะ tamper-resistant storage ที่ปลอดภัยมีราคาแพง
    ในมุมมองด้านความปลอดภัย ถึงขั้นพูดได้ว่ากุญแจความปลอดภัยที่ดีที่สุดคือกุญแจที่ไม่มีพื้นที่เก็บข้อมูลเลย โปรโตคอลที่ไม่อนุมาน security token จาก shared secret ฯลฯ แต่ฉีดและเก็บมันไว้ในกุญแจความปลอดภัยหรือ secure enclave โดยตรง มักมีข้อบกพร่องร้ายแรง บางครั้งเป็นข้อบกพร่องเชิงความปลอดภัยพื้นฐานแบบ TOTP บางครั้งเป็นข้อบกพร่องจากความซับซ้อน เช่นเดียวกัน คุณไม่ควรอยากแชร์ HSK/กุญแจความปลอดภัยสำหรับ 2FA ข้ามหลายอุปกรณ์เด็ดขาด เพราะถ้าอุปกรณ์เครื่องเดียวรั่ว ทุกอย่างก็พังหมด ทางที่ดีกว่าคือมีคนละกุญแจในแต่ละอุปกรณ์ และสำหรับผู้ให้บริการล็อกอินหรือฝั่งเซิร์ฟเวอร์ ภาระส่วนเพิ่มนี้แทบไม่มีนัยสำคัญเมื่อมองภาพรวม
  • ดูเหมือนเป็นการเลือกออกแบบโดยตั้งใจเพื่อให้อุปกรณ์แบบนี้ "ทื่อ" ไว้ให้มากที่สุด พอเพิ่มพื้นที่เก็บข้อมูลเข้าไป ก็จะเปิดผิวโจมตีแบบเดียวกับสื่อเก็บข้อมูลอื่น ๆ แล้วต่อไปก็จะมีความสามารถในการประมวลผลเพิ่มเข้ามา สุดท้ายมันก็จะไม่ใช่ Yubikey ทื่อ ๆ อีกต่อไป แต่กลายเป็นคอมพิวเตอร์เต็มรูปแบบ
  • น่าจะเพิ่มพื้นที่เก็บข้อมูลได้ แต่ยิ่งใส่มาก โอกาสเสียก็ยิ่งมาก กุญแจปัจจุบันทนการใช้งานสมบุกสมบันได้มากพอสมควรก่อนจะพังใช้ไม่ได้
    ข้อดีอีกอย่างของพื้นที่เก็บข้อมูลขนาดเล็กคือมันตรวจสอบได้ง่ายขึ้นเล็กน้อย แน่นอนว่าในมาตรฐานปัจจุบัน แม้แต่ขนาดเล็กแค่นั้นก็อาจกำลังดันขอบเขตของสิ่งที่ตรวจสอบได้จริงอยู่แล้ว
  • ไม่ได้เป็นเรื่องที่หน่วยความจำมีจำกัดเท่านั้น แต่ใกล้เคียงกับการถูกออกแบบมาให้ ไม่มีข้อจำกัดด้านหน่วยความจำ ตั้งแต่แรก
    ดูจาก TPM เวลาจะเซ็นอะไรสักอย่าง อินพุตในแต่ละครั้งคือข้อมูลที่จะเซ็นและ private key ที่ถูก seal ไว้ โดยกุญแจที่ถูก seal นี้คือ private key ที่ TPM สร้างขึ้นซึ่งถูกเข้ารหัสแบบสมมาตรด้วยกุญแจที่ฝังอยู่ใน TPM เอง จากนั้นจึงเก็บ sealed key นี้ไว้ในสตอเรจความจุสูง และส่งให้ TPM ทุกครั้งที่มีการเซ็น ด้วยการออกแบบนี้จึงมีกุญแจได้มากเท่าที่สตอเรจความจุสูงอนุญาต
  • น่าจะทำเป็นแบบโมดูลาร์ได้ด้วย เช่นขายอุปกรณ์ที่ดูเหมือน USB flash drive แต่ด้านหลังมีช่องสำหรับเสียบ security key ฟอร์มแฟกเตอร์เล็กอย่าง YubiKey Nano
    เมื่อเสียบ security key เข้าไป USB flash drive จะให้พื้นที่เก็บข้อมูลกับกุญแจความปลอดภัย และคอมพิวเตอร์จะมองเห็นเป็น security key เมื่อไม่ได้เสียบกุญแจ มันก็ทำงานเป็น USB flash drive ปกติ ตามปกติก็เสียบกุญแจคาไว้ พอต้องการพื้นที่เพิ่มก็ซื้อโมดูลสตอเรจที่ใหญ่ขึ้น ถอดกุญแจความปลอดภัยออกจากโมดูลเดิม เสียบเข้าคอมพิวเตอร์เพื่อคัดลอกไฟล์ที่เข้ารหัส แล้วค่อยย้ายไปยังโมดูลใหม่และเสียบกุญแจกลับเข้าไป

• ผมไม่แน่ใจแต่แรกเลยว่าการใช้คีย์ความปลอดภัยแบบกายภาพเป็น passkey เป็นความคิดที่ดีหรือไม่ passkey ถูกออกแบบมาให้เป็น ตัวแทนรหัสผ่าน และถ้าเป็นเช่นนั้นก็ดูเหมือนว่าปกติควรมีคุณสมบัติแบบ 2 ปัจจัยจากโทรศัพท์หรือเดสก์ท็อป ที่นอกจากจะเป็น “สิ่งที่คุณมี” แล้ว ยังต้องใช้ “สิ่งที่คุณรู้” หรือ “ตัวตนของคุณ” เพื่อปลดล็อกด้วย
  ผมคิดว่าคีย์ความปลอดภัยแบบกายภาพควรถูกเก็บไว้เป็นการยืนยันตัวตนแบบ 2 ขั้นที่ใช้เพิ่มจาก passkey ในบริบทที่ต้องการความปลอดภัยสูงโดยเฉพาะ โดยเฉพาะเมื่อความสามารถในการต้านการโคลนเป็นฟังก์ชันหลัก สำหรับการใช้งานแบบนั้น เมื่อไปถึงขั้นที่สองแล้ว เราก็รู้อยู่แล้วว่ากำลังจะล็อกอินเข้าบัญชีไหน จึงไม่จำเป็นต้องมี resident key อีกทั้งผมคิดว่าฟีเจอร์กรอกอัตโนมัติที่ resident key มอบให้นั้นสำคัญต่อ UX ของ passkey มาก ไม่มีเหตุผลที่จะต้องเสียสิ่งนั้นไปเพื่อรักษาความเข้ากันได้ย้อนหลังกับคีย์ส่วนน้อยที่มีแต่สายคลั่งความปลอดภัยใช้ แน่นอนว่าถ้ามีวิธีรักษา UX นั้นไว้ได้โดยไม่ต้องมี resident key ก็โอเค

  • คิดคล้ายกันโดยรวม แนวคิดที่ทุกคนดูจะเห็นพ้องกันตอนนี้คือการมี ตู้นิรภัยความปลอดภัย แบบเข้ารหัสในเครื่องที่เชื่อถือได้ และต้องยืนยันตัวตนกับระบบนั้น จะเป็นรหัสผ่านหรือคีย์ก็ได้
    มันง่ายกว่าที่จะเชื่อว่าตัวจัดการรหัสผ่านที่เราเลือกปลอดภัยกว่า แทนที่จะสมมติว่าทุกบริการในโลกที่เราสร้างบัญชีไว้นั้นปลอดภัยหรือกันฟิชชิงได้ ดังนั้นเวลาที่จะใช้ passkey เรามักอยู่ในบริบทที่ปลอดภัยกว่าอยู่แล้ว โดยได้ยืนยันตัวตนกับระบบปฏิบัติการหรือกับตัวจัดการรหัสผ่านที่ถือ passkey ไว้ นอกจากนี้ สถานที่ที่ตอนนี้หรือจนกระทั่งไม่นานมานี้ยังไม่รองรับฮาร์ดแวร์คีย์ ก็น่าจะยังไม่รองรับในอนาคตอันใกล้เช่นกัน ในทางกลับกัน โซลูชัน passkey ต้นทุนการนำไปใช้มีแค่ระดับการรองรับซอฟต์แวร์ จึงง่ายกว่ามากและมีโอกาสให้ผลตอบแทนต่อการลงทุนที่ดีกว่า แน่นอนว่านี่พูดถึงเว็บไซต์เป็นหลัก และ passkey ก็คล้าย “SSH key แบบมาตรฐาน” สำหรับเว็บไซต์มากกว่า ฮาร์ดแวร์คีย์ดูจะมีประโยชน์กว่าในฐานะปัจจัยขั้นที่สองที่ใช้เปิดตู้นิรภัยซึ่งเก็บ passkey จริง ๆ และในกรณีนี้อาจต้องใช้รหัสผ่านร่วมด้วยด้วย ดูเหมือนว่าฮาร์ดแวร์คีย์ยังมีอายุการใช้งานเหลืออยู่อีกพอสมควร พอลองใช้เป็นวิธีหลักกับ GitHub, Gmail และที่อื่น ๆ แล้ว ขั้นตอนการล็อกอินด้วย passkey นั้นดีมากจริง ๆ
  • ตัวจัดการรหัสผ่านทำให้รหัสผ่านไร้ประโยชน์ไปแล้ว ผมไม่รู้รหัสผ่านของตัวเองเลยสักอัน ยกเว้น master password อันเดียว passkey เป็น ทางแก้ที่ซับซ้อนเกินจำเป็น สำหรับสิ่งที่เราไม่ได้ต้องการจริง ๆ
    สิ่งที่เบราว์เซอร์ควรมีคือ HATEOAS API แบบเรียบง่ายที่ตัวจัดการรหัสผ่านเชื่อมต่อได้ และเว็บแอปก็แค่เผย HTML ที่ไปกระตุ้นเบราว์เซอร์ จากนั้นตัวจัดการรหัสผ่านจะเป็นผู้ตัดสินว่าจะแสดงการยืนยันตัวตนของผู้ใช้อย่างไร หรือก็คือให้ผู้ใช้เลือกวิธีที่ต้องการ แล้วฉีดค่า secret ของเว็บไซต์นั้นให้อัตโนมัติ ผู้ใช้ก็ล็อกอินอัตโนมัติได้ ถ้ามีปัญหาก็ใช้การรีเซ็ตทางอีเมลได้ ผมเข้าใจว่าเว็บไซต์ที่ต้องการ “ความปลอดภัยสุดอลังการ” อาจอยากได้อะไรที่ซับซ้อนกว่านั้น แต่ผู้ใช้ควรสามารถเปิดระดับความปลอดภัยที่สูงขึ้นได้ตามต้องการ เช่น เว็บไซต์ส่วนใหญ่ถ้าสมมติว่าตัวจัดการรหัสผ่านใช้รหัสผ่านแบบสุ่ม ก็แค่แฮชรหัสผ่านธรรมดาก็พอ เว็บไซต์ไหนก็ทำได้ ตัวจัดการรหัสผ่านไหนก็ทำได้ และมันก็ดีกว่าการใช้รหัสผ่านของผู้ใช้ทั่วไป 99% ในตอนนี้ ควรให้สิ่งนี้เป็นวิธีการยืนยันตัวตนพื้นฐาน จากนั้นถ้าต้องการ TOTP, OIDC, การเข้ารหัสแบบกุญแจสาธารณะ ฯลฯ เซิร์ฟเวอร์ก็ค่อยประกาศรองรับ แล้วไคลเอนต์ค่อยเข้าร่วมแบบเลือกได้เพื่อดำเนินการยืนยันตัวตนต่อ ไม่จำเป็นที่ทุกเว็บไซต์และทุกผู้ใช้ต้องใช้วิธีที่ปลอดภัยที่สุดเสมอไป ควรทำให้การยกระดับเส้นฐานด้านความปลอดภัยเป็นเรื่องง่ายก่อน แล้วค่อยให้คนเลือกความปลอดภัยที่แข็งแกร่งกว่าทีละน้อย
  • เวลาทำการยืนยันตัวตนแบบไม่ใช้รหัสผ่าน (FIDO2) ด้วย Yubikey ระบบจะขอ PIN ก่อนที่จะให้แตะอุปกรณ์ ถ้าใส่ PIN ผิดหลายครั้งเกินไป Yubikey จะถูกล็อกและต้องรีเซ็ตอุปกรณ์ ซึ่งจะทำให้การลงทะเบียนเดิมทั้งหมดที่ใช้คีย์นั้นสำหรับการยืนยันตัวตนใช้ไม่ได้อีก
    ต่อให้มีใครขโมยฮาร์ดแวร์โทเคนของผมไป ก็ไม่ได้ดูเป็นปัญหาใหญ่อะไร https://support.yubico.com/hc/en-us/articles/4402836718866-U...
  • ถ้าคิดดูให้ดี ปัญหาหลักอาจอธิบายได้ว่าเป็น “การยืนยันตัวตนของสิ่งมีชีวิตทางชีวภาพกับระบบอิเล็กทรอนิกส์”
    ถ้าใช้รหัสผ่าน อินเทอร์เฟซการยืนยันตัวตนก็คือคีย์บอร์ด และไม่ได้มีหลักประกันจริง ๆ ว่าคนที่พิมพ์รหัสผ่านคือคนที่อ้างว่าเป็นคนนั้น รหัสผ่านพึ่งพาความรู้ที่ส่งต่อกันได้ง่าย จึงสามารถถูกดึงออกไปได้หลายวิธี การย้ายอินเทอร์เฟซการยืนยันตัวตนไปเป็นแบบอุปกรณ์ต่ออุปกรณ์นั้นดีกว่ามาก แทนที่จะสมมติว่าความรู้ที่ถ่ายทอดกันได้ง่ายไม่ได้ถูกถ่ายทอดออกไป ก็เปลี่ยนมาสมมติว่าสิ่งมีชีวิตทางชีวภาพสามารถดูแลอุปกรณ์ยืนยันตัวตนได้ ซึ่งมนุษย์จริง ๆ ก็ทำเรื่องแบบนั้นได้ค่อนข้างเก่งอยู่แล้ว เราอาจเพิ่มจำนวนช่องทางการยืนยันตัวตนเพื่อให้แข็งแรงขึ้นได้ และยังอาจจำกัดการยืนยันตัวตนระหว่างอุปกรณ์กับสิ่งมีชีวิตที่จะใช้กับระบบระยะไกลด้วยสิ่งอย่าง FaceID ได้ด้วย แก่นสำคัญคือการสมมติว่า อุปกรณ์ อย่างโทรศัพท์หรือกุญแจนั้นก็คือตัวบุคคล ฟังดูเป็นธรรมชาติดี ที่บ้านเราไม่ได้แชร์แค่รหัสผ่าน Netflix แต่แชร์บัตรเครดิตใบหนึ่งด้วย ด้วยเหตุผลเชิงปฏิบัติ เราวางบัตรเครดิตใบหนึ่งไว้เป็นกุญแจสำรอง และถ้าใครต้องซื้อของใช้จำเป็นเข้าบ้านก็หยิบไปใช้ได้เลย เราเชื่อใจกันว่าจะใช้บัตรอย่างเหมาะสม และทุกคนก็รู้ PIN แต่แทบไม่จำเป็นต้องใช้เพราะการจ่ายแบบไร้สัมผัสเป็นเรื่องปกติ มันเป็นธรรมชาติกว่ามากเมื่อเทียบกับการคอยติดตามค่าใช้จ่ายแล้วมาคิดบัญชีกันทีหลัง มันคงผิดกฎหมาย และถ้าธนาคารรู้ก็คงยกเลิกบัตร แต่ระบบ IT จำเป็นอย่างยิ่งที่จะต้องเข้าใกล้พฤติกรรมมนุษย์ โดยทำงานในแบบที่คล้ายโลกจริง คนส่วนใหญ่ทนกับมันได้เพราะเกี่ยวข้องกับระบบ IT อยู่แล้ว แต่คนที่ไม่คุ้นกับเทคโนโลยีแม้แต่ปัญหาในชีวิตประจำวันอย่าง รหัสผ่าน iPhone คืออะไร รหัสผ่าน iCloud คืออะไร รหัสผ่าน Gmail คืออะไร และทำไมต้องกรอกโค้ดใน WhatsApp ก็ยังลำบาก อันที่จริงผมเองก็ไม่เข้าใจ Mastadon ผมน่าจะโดนฟิชชิงของ Mastadon ได้ง่าย และน่าจะกรอกทุกอย่างที่หน้าจอบอกให้กรอก
  • การบอกว่า passkey เป็นตัวแทนรหัสผ่านนั้นไม่ถูกต้อง

Passkey อย่างที่ชื่อบอก คือการอาศัยมาตรฐาน FIDO2 U2F ที่พัฒนามาเพื่อเป็นปัจจัยที่สองโดยตรง คีย์แบบ resident เป็นสำหรับการยืนยันตัวตนสองขั้นตอนบนอุปกรณ์ร่วมกับ PIN และเป็นตัวแทนเชิงหน้าที่ของสมาร์ทการ์ด ดูเหมือนว่าจะมีใครสักคน น่าจะเป็น Apple คิดว่า WebAuthn เพียงอย่างเดียวก็เพียงพอที่จะเป็นปัจจัยยืนยันตัวตนเพียงปัจจัยเดียวได้ ไม่มีทั้ง resident key ไม่มีการผูกกับฮาร์ดแวร์ และคีย์ย้ายผ่าน iCloud แต่บนอุปกรณ์ก็ได้รับการปกป้องด้วย TouchID/FaceID อะไรทำนองนั้น แล้วก็นำสิ่งนี้ไปทำแบรนด์เป็น passkey เป้าหมายไม่ใช่การยืนยันตัวตนสองขั้นตอนในตัวมันเอง เป้าหมายคือการยืนยันตัวตนผู้ใช้ที่ปลอดภัยต่อฟิชชิง การเดารหัสแบบ brute force และการโจมตีแบบ credential stuffing โดยไม่ทำให้ใช้งานยากเท่าสมาร์ทการ์ด และ FIDO2 ก็ทำสิ่งนั้นได้ ปัญหาของการใช้งานโดย Apple, Google และ Microsoft ไม่ใช่ว่าความปลอดภัยระดับโปรโตคอลระหว่างเว็บไซต์ที่ยืนยันตัวตนกับอุปกรณ์ของผู้ใช้ต่ำลง เพราะโปรโตคอลนั้นเหมือนเดิม ปัญหาคือ ตอนนี้เว็บไซต์ต้องเชื่อถือบัญชีแพลตฟอร์มส่วนตัวของผู้ใช้ เชื่อว่าผู้ใช้ตั้งค่าไว้อย่างถูกต้อง และเชื่อว่าแพลตฟอร์มจะยังคงทำงานได้อย่างถูกต้องเสมอในอนาคตและจัดการการโจมตีต่อบัญชีส่วนตัวของผู้ใช้ได้อย่างเหมาะสม

• เพื่อเสริมบริบท ผมทำบริษัทด้านการยืนยันตัวตนแบบไร้รหัสผ่านที่ได้รับเงินสนับสนุนจาก YC และได้ปรับใช้สิ่งนี้ในองค์กรขนาดใหญ่มาแล้ว ดูชัดเจนว่า passkey จะเป็นคำตอบสำหรับการยืนยันตัวตนแบบไร้รหัสผ่านฝั่งผู้บริโภค แต่ดูเหมือนว่ายังไม่สะท้อนแบบนั้นในสภาพแวดล้อมองค์กร
  passkey ยอดเยี่ยมสำหรับผู้บริโภค เพราะมีเป้าหมายเพื่อให้ข้อมูลรับรองถูกสำรองไปยังอุปกรณ์อื่นด้วยวิธีอย่างการสำรองข้อมูลค่าเริ่มต้นของ iCloud หรือ AirDrop เพื่อให้ผู้ใช้กู้การเข้าถึงฉุกเฉินได้ด้วยตัวเอง ในทางเทคนิค อุปกรณ์ที่ได้รับการแชร์ข้อมูลรับรองนี้ ไม่สามารถ ให้ attestation ได้ attestation คือ “หลักฐาน” ว่าคู่กุญแจถูกสร้างขึ้นบนอุปกรณ์เฉพาะอย่าง Yubikey หรืออุปกรณ์ของ Apple ผู้ผลิตอย่าง Yubico จะฝังคู่กุญแจและใบรับรองที่ดึงออกไม่ได้ไว้ในตัวกุญแจตั้งแต่โรงงาน และเพราะไม่มีอินเทอร์เฟซภายนอกสำหรับเข้าถึงคู่กุญแจนี้ ผู้ดูแลระบบจึงมั่นใจได้ค่อนข้างสูงว่านี่คือ Yubikey ของจริง เมื่อไม่มี attestation และสามารถแชร์กุญแจได้ ก็จะเห็นทันทีว่าปัญหาเริ่มต้นตรงไหน องค์กรไม่อยากรับความเสี่ยงที่ข้อมูลรับรองซึ่ง AirDrop ได้จะเปิดช่องให้เข้าถึงบัญชีพนักงานที่มีสิทธิพิเศษ Yubikey แทบไม่มีความเสี่ยงจากการขโมยในรูปแบบดิจิทัลเลย ท้ายที่สุดแล้ว passkey ก็ยังใช้ปลดล็อกอุปกรณ์หรือเซิร์ฟเวอร์ไม่ได้ด้วย FIDO2 และที่สำคัญกว่านั้นคือผู้พัฒนาระบบปฏิบัติการยังต้องไปอีกไกลหากจะยุติรหัสผ่านอย่างสมบูรณ์ ในตลาดองค์กรปัจจุบัน Yubikey กำลังอุดช่องว่างนี้อยู่ และบางแห่งก็ใช้เงินไปกับฮาร์ดแวร์หลายล้านดอลลาร์แล้ว passkey ในสภาพปัจจุบันน่าจะขายได้ยาก

  • passkey ไม่ใช่คำศัพท์เชิงเทคนิค แต่เป็น คำเชิงประสบการณ์ผู้ใช้ ดังนั้นเมื่อเอาไปใช้ในการถกเถียงทางเทคนิค มันจึงพังลงพอสมควร
    Apple รองรับ passkey, Android และ Chrome ก็รองรับ, Microsoft ก็รองรับ, Yubikey ก็รองรับ passkey เช่นกัน แต่คุณสมบัติและข้อจำกัดอย่างขั้นตอนการยืนยันผู้ใช้และความสามารถในการทำสำเนาอาจแตกต่างกันมาก หน่วยงานรัฐอาจรองรับ passkey แต่อนุญาตเฉพาะเมื่อมาจากอุปกรณ์ยืนยันตัวตนที่ผ่านการรับรอง FIPS และตรงตามข้อกำหนด AAL2 ซึ่งอย่างน้อยตอนนี้คงไม่ใช่สิ่งที่มาจาก Apple หรือ Google องค์กรอาจเลือกสนับสนุน passkey ที่สร้างจากซอฟต์แวร์และการตั้งค่าซึ่งผลิตภัณฑ์ที่จัดการผ่าน MDM มอบให้ และ Apple ก็ประกาศการรองรับแบบเบตาสำหรับเรื่องนี้แล้ว อย่างไรก็ตาม หากบริการภาครัฐสำหรับประชาชนพยายามบังคับใช้อุปกรณ์ยืนยันตัวตนฮาร์ดแวร์เฉพาะ ก็อาจต้องเจอกับความยุ่งยากอย่างมาก เพราะทั้งยากจะโน้มน้าวให้ประชาชนซื้อฮาร์ดแวร์ราคา 80 ดอลลาร์ขึ้นไป และเทคโนโลยีเว็บก็ถูกออกแบบมาโดยยึดการเลือกของผู้ใช้เป็นศูนย์กลาง จึงไม่น่าเป็นไปได้ที่ WebAuthn API และประสบการณ์ผู้ใช้จะถูกปรับให้เหมาะกับการจำกัดทางเลือกของผู้ใช้
  • ถ้า Google หรือ Apple เผลอบล็อกบัญชีเพราะเหตุผลเหลวไหลอย่างการป้องกันบอตหรือการตรวจจับการฉ้อโกง จะเกิดอะไรขึ้น?
  • yubikeys 5 ใช้เป็น passkey ได้

• จากมุมมองด้านความปลอดภัย ผมมองว่านี่เป็นวิธีแก้ปัญหาที่แย่มากจริง ๆ
  มันเป็นโครงสร้างในฝันสำหรับรัฐบาลและบริษัทอย่าง Apple, Google ในการ ควบคุมชีวิตดิจิทัล ของผู้คน ถ้าใช้รหัสผ่าน สภาพจะใกล้เคียงกับความไร้สถานะบางอย่าง กล่าวคือ ต่อให้คุณข้ามพรมแดนพร้อมบัญชีอีเมลส่วนตัวหรือบัญชีใดก็ตาม ก็ไม่มีใครรู้ได้ว่าคุณมีบัญชีนั้นอยู่ และยากที่จะบังคับให้คุณมอบสิทธิ์เข้าถึง ดึงองค์ประกอบที่ใช้เข้าถึงออกจากฮาร์ดแวร์ หรือสั่งล็อกเพราะคุณสูญเสียการเข้าถึงอุปกรณ์ไป แม้ว่ามาสเตอร์คีย์หรือสิ่งที่คล้ายกันจะถูกเก็บไว้ใน TPM หรือ secure element แต่สำหรับบางรัฐบาล นั่นเป็นเพียงปัญหาเรื่องเวลาไม่กี่ปีกับกำลังประมวลผลเท่านั้น ในหลายกรณี ตัวมันเองก็อาจกลายเป็นหลักฐานว่าคุณมีข้อมูลรับรองของบัญชีใดบัญชีหนึ่งอยู่ ผู้ผลิตอุปกรณ์หรือระบบปฏิบัติการสามารถถูกบังคับได้ไม่ยากจากทางการให้เปิดการเข้าถึงพื้นที่ปลอดภัย และไม่ว่าจะสมัครใจหรือไม่ก็ตาม มันก็อาจเกิดขึ้นได้