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

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 มีคนสูญเสียการเข้าถึงอุปกรณ์ของตน

นี่คือเหตุผลที่ฉันจะไม่เริ่มด้วย "ตั้งแต่วันนี้ ไม่มีรหัสผ่านสำหรับทุกคนอีกต่อไป" ฉันจะเริ่มต้นเช่นนี้:

1. passkey ตัวเลือกสำหรับผู้ใช้ภายใน
2. คำแนะนำในการสร้างหนึ่งรายการหลังจากเข้าสู่ระบบสำเร็จ
3. หน้าบัญชีที่จะเปลี่ยนชื่อและลบ passkey;
4. ทางเลือกที่ชัดเจน
5. การเปิดตัวแบบค่อยเป็นค่อยไปในการเข้าสู่ระบบหลัก

ข้อความในอินเทอร์เฟซควรเรียบง่าย "ใช้หน้าจอล็อคอุปกรณ์ของคุณ" ดีกว่า "ตรวจสอบสิทธิ์ด้วยข้อมูลประจำตัวผู้อยู่อาศัย FIDO2"

ข้อผิดพลาดที่ฉันจะหลีกเลี่ยง

อย่าสร้างความท้าทายให้กับลูกค้า ความท้าทายถูกสร้างขึ้นบนเซิร์ฟเวอร์และต้องได้รับการตรวจสอบเพียงครั้งเดียว

อย่าเพิ่งเชื่อถือรหัสประจำตัว คุณต้องยืนยันลายเซ็น ความท้าทาย ต้นกำเนิด และ Relying Party ID

อย่าลบทางเลือกก่อนที่คุณจะมีขั้นตอนการกู้คืนที่ดี การใช้รหัสผ่านไม่จำเป็นต้องกลายเป็น "ถ้าคุณทำโทรศัพท์หาย คุณจะออกไปข้างนอกตลอดไป"

อย่าถือว่า passkey เป็นเพียงปุ่มส่วนหน้าเท่านั้น การซ่อนปุ่มไม่ใช่การรักษาความปลอดภัย การตรวจสอบที่แท้จริงคือฝั่งเซิร์ฟเวอร์

Passkey-แรกหรือ passkey-เป็นมิตร?

สำหรับผลิตภัณฑ์ใหม่ ให้คิด passkey-ก่อน สำหรับแอปที่มีอยู่แล้ว ฉันชอบที่เป็นมิตรกับ passkey: เพิ่ม passkey เป็นวิธีการที่แนะนำ วัดความสำเร็จและปัญหา จากนั้นลดน้ำหนักรหัสผ่านอย่างใจเย็น

ไม่รู้สึกถึงการโยกย้ายในอุดมคติ ผู้ใช้ค้นพบว่าการเข้าสู่ระบบนั้นง่ายกว่า ไม่ใช่ว่าบริษัทได้เปลี่ยนโปรโตคอลการตรวจสอบความถูกต้อง

บทสรุป

passkey มีความน่าสนใจเนื่องจากปรับปรุงความปลอดภัยและ UX ในเวลาเดียวกัน ซึ่งหาได้ยาก พวกมันไม่ใช่ไม้กายสิทธิ์: การกู้คืน ความเข้ากันได้ การสนับสนุน และการเปิดตัวยังคงต้องได้รับการออกแบบอย่างดี

แต่การเปลี่ยนแปลงพื้นฐานนั้นแข็งแกร่ง หยุดขอให้ผู้ใช้ประดิษฐ์และปกป้องความลับ คุณอนุญาตให้อุปกรณ์ลงนามหลักฐานการเข้ารหัสที่เชื่อมโยงกับโดเมนของคุณ หน่วยความจำของมนุษย์น้อยลง ฟิชชิ่งน้อยลง การรีเซ็ตรหัสผ่านน้อยลง ฉันว่าพวกเขาก็คุ้มค่าที่จะจริงจัง

แหล่งที่มา

• MDN: Passkeys
• MDN: Web Authentication API
• W3C: Web Authentication
• passkeys.dev