รหัสผ่านเป็นหนึ่งในสิ่งที่เราทำให้เป็นมาตรฐานเพียงเพราะเราใช้ชีวิตร่วมกับมันมานานหลายปี ผู้ใช้จะลืม ใช้ซ้ำ เขียนในที่ที่ไม่ควร ทีมจะต้องจัดการการรีเซ็ต นโยบาย แฮช การรั่วไหล ฟิชชิ่ง และการสนับสนุน
passkey ไม่ได้ทำให้การรับรองความถูกต้องสมบูรณ์แบบ แต่ช่วยขจัดปัญหาใหญ่ได้: เซิร์ฟเวอร์ไม่จำเป็นต้องเก็บความลับที่แชร์กับผู้ใช้อีกต่อไป
เกิดอะไรขึ้นจริงๆ
A passkey เป็นข้อมูลรับรองตาม WebAuthn เมื่อผู้ใช้สร้างขึ้น อุปกรณ์จะสร้างคู่คีย์:
- รหัสส่วนตัวซึ่งยังคงอยู่ในอุปกรณ์หรือในตัวจัดการรหัสผ่าน
- รหัสสาธารณะซึ่งเซิร์ฟเวอร์สามารถบันทึกได้
เมื่อเข้าสู่ระบบเซิร์ฟเวอร์ไม่ถาม "บอกรหัสผ่าน" ส่งความท้าทายแบบสุ่ม อุปกรณ์ลงนามด้วยรหัสส่วนตัว เซิร์ฟเวอร์ตรวจสอบลายเซ็นด้วยรหัสสาธารณะ
นั่นเป็นส่วนที่ดี: หากฐานข้อมูลถูกขโมย จะไม่มีรหัสผ่านภายในให้ถอดรหัส และหากผู้ใช้ลงเอยด้วยโดเมนปลอม passkey จะไม่ถูกต้องสำหรับโดเมนนั้น ไม่ใช่แค่ความสะดวกสบายเท่านั้น แต่ยังเป็นการป้องกันฟิชชิ่งอย่างเป็นรูปธรรมอีกด้วย
เบราว์เซอร์ทำหน้าที่เป็นสะพานเชื่อม
ในเบราว์เซอร์ API หลักสองตัวคือ:
navigator.credentials.create()เพื่อสร้าง passkey;navigator.credentials.get()เพื่อใช้ระหว่างเข้าสู่ระบบ
แต่ตรรกะที่สำคัญอยู่ที่เซิร์ฟเวอร์ เซิร์ฟเวอร์จะต้องสร้างความท้าทาย บันทึกชั่วคราว ตรวจสอบการตอบสนอง ตรวจสอบแหล่งที่มาและ Relying Party ID จากนั้นจึงสร้างเซสชัน
ส่วนของไคลเอนต์ควรจะน่าเบื่อเกือบ:
const options = await fetch('/api/passkeys/login/options').then((r) => r.json()); const credential = await navigator.credentials.get({ publicKey: PublicKeyCredential.parseRequestOptionsFromJSON(options), }); await fetch('/api/passkeys/login/verify', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(credential?.toJSON()), });
หากคุณพบว่าตัวเองใช้การเข้ารหัส WebAuthn ด้วยตนเอง ให้หยุด ใช้ไลบรารีฝั่งเซิร์ฟเวอร์ที่มีประสิทธิภาพ ข้อผิดพลาดที่นี่ไม่ใช่ "ข้อบกพร่องที่น่ารัก" แต่เป็นช่องโหว่ในการตรวจสอบสิทธิ์
สิ่งที่ต้องบันทึกในฐานข้อมูล
ไม่จำเป็นต้องกอบกู้โลกครึ่งโลก มักจะเพียงพอ:
- ID ของหนังสือรับรอง;
- กุญแจสาธารณะ
- ผู้ใช้ที่เชื่อมต่อ;
- ตัวนับการยืนยันหรือข้อมูลเมตาใด ๆ
- การขนส่ง หากมีประโยชน์สำหรับ UX
- ชื่อที่ผู้ใช้เลือก;
- วันที่สร้างและการใช้งานครั้งล่าสุด
ตารางขั้นต่ำอาจมีลักษณะดังนี้:
create table passkey_credentials ( id uuid primary key default gen_random_uuid(), user_id uuid not null references users(id), credential_id text not null unique, public_key text not null, name text, created_at timestamptz not null default now(), last_used_at timestamptz );
จากนั้น ฉันจะเพิ่มบันทึกการตรวจสอบและการแจ้งเตือน หากมีคนสร้าง passkey ใหม่บนบัญชีของฉัน ฉันก็อยากจะทราบเรื่องนี้
UX มีความสำคัญมากกว่าการสาธิต
การสาธิตของ passkey นั้นสวยงามเสมอ: คุณคลิก Face ID คุณก็เข้ามาแล้ว ผลิตภัณฑ์จริงมีความซับซ้อนมากขึ้น
มีคนเปลี่ยนโทรศัพท์ มีคนใช้คอมพิวเตอร์ของบริษัทที่ถูกล็อค บางคนไม่เข้าใจว่าทำไมเบราว์เซอร์ถึงแนะนำ passkey มีคนสูญเสียการเข้าถึงอุปกรณ์ของตน
นี่คือเหตุผลที่ฉันจะไม่เริ่มด้วย "ตั้งแต่วันนี้ ไม่มีรหัสผ่านสำหรับทุกคนอีกต่อไป" ฉันจะเริ่มต้นเช่นนี้:
- passkey ตัวเลือกสำหรับผู้ใช้ภายใน
- คำแนะนำในการสร้างหนึ่งรายการหลังจากเข้าสู่ระบบสำเร็จ
- หน้าบัญชีที่จะเปลี่ยนชื่อและลบ passkey;
- ทางเลือกที่ชัดเจน
- การเปิดตัวแบบค่อยเป็นค่อยไปในการเข้าสู่ระบบหลัก
ข้อความในอินเทอร์เฟซควรเรียบง่าย "ใช้หน้าจอล็อคอุปกรณ์ของคุณ" ดีกว่า "ตรวจสอบสิทธิ์ด้วยข้อมูลประจำตัวผู้อยู่อาศัย FIDO2"
ข้อผิดพลาดที่ฉันจะหลีกเลี่ยง
อย่าสร้างความท้าทายให้กับลูกค้า ความท้าทายถูกสร้างขึ้นบนเซิร์ฟเวอร์และต้องได้รับการตรวจสอบเพียงครั้งเดียว
อย่าเพิ่งเชื่อถือรหัสประจำตัว คุณต้องยืนยันลายเซ็น ความท้าทาย ต้นกำเนิด และ Relying Party ID
อย่าลบทางเลือกก่อนที่คุณจะมีขั้นตอนการกู้คืนที่ดี การใช้รหัสผ่านไม่จำเป็นต้องกลายเป็น "ถ้าคุณทำโทรศัพท์หาย คุณจะออกไปข้างนอกตลอดไป"
อย่าถือว่า passkey เป็นเพียงปุ่มส่วนหน้าเท่านั้น การซ่อนปุ่มไม่ใช่การรักษาความปลอดภัย การตรวจสอบที่แท้จริงคือฝั่งเซิร์ฟเวอร์
Passkey-แรกหรือ passkey-เป็นมิตร?
สำหรับผลิตภัณฑ์ใหม่ ให้คิด passkey-ก่อน สำหรับแอปที่มีอยู่แล้ว ฉันชอบที่เป็นมิตรกับ passkey: เพิ่ม passkey เป็นวิธีการที่แนะนำ วัดความสำเร็จและปัญหา จากนั้นลดน้ำหนักรหัสผ่านอย่างใจเย็น
ไม่รู้สึกถึงการโยกย้ายในอุดมคติ ผู้ใช้ค้นพบว่าการเข้าสู่ระบบนั้นง่ายกว่า ไม่ใช่ว่าบริษัทได้เปลี่ยนโปรโตคอลการตรวจสอบความถูกต้อง
บทสรุป
passkey มีความน่าสนใจเนื่องจากปรับปรุงความปลอดภัยและ UX ในเวลาเดียวกัน ซึ่งหาได้ยาก พวกมันไม่ใช่ไม้กายสิทธิ์: การกู้คืน ความเข้ากันได้ การสนับสนุน และการเปิดตัวยังคงต้องได้รับการออกแบบอย่างดี
แต่การเปลี่ยนแปลงพื้นฐานนั้นแข็งแกร่ง หยุดขอให้ผู้ใช้ประดิษฐ์และปกป้องความลับ คุณอนุญาตให้อุปกรณ์ลงนามหลักฐานการเข้ารหัสที่เชื่อมโยงกับโดเมนของคุณ หน่วยความจำของมนุษย์น้อยลง ฟิชชิ่งน้อยลง การรีเซ็ตรหัสผ่านน้อยลง ฉันว่าพวกเขาก็คุ้มค่าที่จะจริงจัง