ทำไมพาสคีย์จึงปลอดภัย — แผนภาพกลไก «การยืนยันตัวตนที่ไม่ส่งความลับ»

ข่าว «บริการใหญ่รั่วรหัสผ่านอีกแล้ว» ไม่มีใครแปลกใจอีก ฝึกฟิชชิงทุกปี คนที่ติดก็ไม่เป็นศูนย์ «อย่านำรหัสผ่านกลับมาใช้ ทำให้ยาว การเปลี่ยนเป็นระยะ… ไม่ต้องทำแล้ว» ── สิ่งที่พูดก็พลิกไปพลิกมา

พาสคีย์ (passkey) ที่แพร่เร็วในช่วงไม่กี่ปีนี้ คือวิธียืนยันตัวตนที่ Apple, Google และ Microsoft ผลักดันพร้อมกันเป็นคำตอบต่อสถานการณ์นี้¹ มักถูกแนะนำว่า «ลงชื่อเข้าใช้ด้วยลายนิ้วมือหรือใบหน้าได้ สะดวก» แต่แก่นไม่ได้อยู่ตรงนั้น คุณค่าจริงของพาสคีย์คือ ย้ายฐานของความปลอดภัยจาก «ความระวังของมนุษย์» ไป «โครงสร้างของโปรโตคอล»

• รหัสผ่านรั่วเพราะผู้ใช้ไม่ระวัง งั้นให้ความรู้ → มนุษย์พลาดเสมอ
• ฝึกให้แยกไซต์ปลอมได้ → สร้างไซต์ปลอมที่แยกไม่ได้ได้
• ถ้าเป็นพาสคีย์ → ไม่มีความลับที่จะส่งตั้งแต่ต้น และบนไซต์ปลอมลายเซ็นตั้งไม่ได้

บทความนี้จับด้วยแผนภาพว่าทำไมพาสคีย์จึงปลอดภัย เริ่มจากว่ารหัสผ่านพังตรงไหน จากนั้นตอบคำถามที่เป็นธรรมดาอย่าง «พาสคีย์ที่ซิงค์แล้วยังปลอดภัยจริงหรือ» «มีจุดอ่อนหรือไม่» ตรง ๆ แล้วปิดด้วยจุดสำคัญในงานจริงเมื่อนำเข้าสู่เว็บแอปและสภาพแวดล้อม Windows

1. สรุปก่อนเลย

เหตุที่พาสคีย์ปลอดภัยรวมได้สามข้อ

1. บนเซิร์ฟเวอร์ไม่มีความลับ สิ่งที่เซิร์ฟเวอร์เก็บคือแค่คีย์สาธารณะ ซึ่งเป็นข้อมูลที่รั่วแล้วก็ใช้ในทางที่ผิดไม่ได้ แม้ฐานข้อมูลรั่วทั้งก้อน ผู้โจมตีไม่มี «วัตถุดิบการปลอมตัว» ที่จะนำกลับไป²
2. ความลับไม่ไหลบนเครือข่าย สิ่งที่ส่งตอนลงชื่อเข้าใช้คือแค่ลายเซ็นต่อเลขสุ่มเฉพาะครั้ง (ชาเลนจ์) คีย์ลับไม่ออกจากตัวพิสูจน์ตัวตนของอุปกรณ์เลย ดังนั้นดักฟังหรือส่งต่อที่จุดใดบนเส้นทางก็ได้ความลับไม่ได้²
3. บนไซต์ปลอมลายเซ็นตั้งไม่ได้ พาสคีย์ถูกผูกกับโดเมนของไซต์ และเบราว์เซอร์บังคับการจับคู่โดเมน แม้ผู้ใช้ถูกไซต์ปลอมหลอก พาสคีย์ของไซต์จริงก็ไม่ขึ้นเป็นตัวเลือกตั้งแต่ต้น และแม้ส่งต่อลายเซ็น การตรวจก็ตก³

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

ความสัมพันธ์ของคำ — พาสคีย์・WebAuthn・FIDO2・CTAP

สาขานี้มีคำมาก และขอบที่บทความชี้ต่างกัน จึงจับความสัมพันธ์ก่อน พาสคีย์ไม่ใช่โปรโตคอลใหม่ แต่เป็น «ชื่อเรียก» ที่ติดบนการรวมมาตรฐานที่มีอยู่²¹

ตาราง 1: พาสคีย์คือชื่อเรียกบนฐาน FIDO2 ไม่ใช่ชื่อมาตรฐาน

กล่าวคือ «รองรับพาสคีย์» เมื่อแปลเป็นคำของงานอิมพลีเมนต์ คือ «อิมพลีเมนต์ WebAuthn» CTAP คือชั้นที่เบราว์เซอร์กับ OS ดูแลเมื่อใช้ตัวพิสูจน์ตัวตนภายนอก ฝั่งที่ทำเว็บแอปไม่ต้องแตะโดยตรง

แผนที่ความรู้ของบทความนี้

พาสคีย์คือข้อมูลรับรองบนฐานการเข้ารหัสคีย์สาธารณะที่ตั้งอยู่บนมาตรฐาน WebAuthn กับ CTAP (รวมกันเป็น FIDO2) คีย์ลับไม่ออกจากตัวพิสูจน์ตัวตน และสิ่งที่ฝากไว้ที่เซิร์ฟเวอร์คือแค่คีย์สาธารณะซึ่งรั่วแล้วก็ใช้ในทางที่ผิดไม่ได้ พาสคีย์ถูกสร้างผูกกับโดเมนของไซต์ (RP ID) ดังนั้นบนไซต์ปลอมลายเซ็นตั้งไม่ได้ตั้งแต่ต้น และฟิชชิงถูกกันได้ในระดับโครงสร้าง พาสคีย์แบบซิงค์ได้ความทนต่อการสูญหายแลกกับการพึ่งบัญชีคลาวด์ ส่วนแบบผูกกับอุปกรณ์ขังกุญแจไว้ในฮาร์ดแวร์ หลังนำพาสคีย์เข้า แกนของงานจริงคือการลดทางสำรองที่ยังอยู่คู่กัน และการทำให้กระแสกู้บัญชีแข็งขึ้น

flowchart LR
    accTitle: แผนที่ความรู้ว่าทำไมพาสคีย์จึงปลอดภัย
    accDescr: แผนภาพที่แสดงว่าพาสคีย์ตั้งอยู่บน WebAuthn, FIDO2, CTAP และการเข้ารหัสคีย์สาธารณะ การผูกโดเมนด้วย RP ID กันฟิชชิงได้ในระดับโครงสร้าง ความต่างระหว่างแบบซิงค์กับแบบผูกกับอุปกรณ์และจุดล้มเหลวจุดเดียวของแต่ละแบบ ตำแหน่งในฐานะ MFA ที่ต้านฟิชชิง และความสัมพันธ์ของความเสี่ยงที่เหลือ (ทางสำรอง・การกู้บัญชี・การขโมยเซสชัน)
    passkey["พาสคีย์"]
    webauthn["WebAuthn"]
    fido2["FIDO2"]
    public_key_cryptography["การเข้ารหัสคีย์สาธารณะ"]
    ctap["CTAP"]
    authenticator["ตัวพิสูจน์ตัวตน"]
    tpm["TPM"]
    windows_hello["Windows Hello"]
    fido2_security_key["คีย์ความปลอดภัย"]
    device_bound_passkey["พาสคีย์แบบผูกกับอุปกรณ์"]
    webauthn_secure_context["ข้อกำหนดบริบทปลอดภัย (HTTPS)"]
    webauthn_challenge["ชาเลนจ์ (เลขสุ่มใช้ครั้งเดียว)"]
    rp_id["RP ID (ตัวระบุ Relying Party)"]
    phishing["ฟิชชิง"]
    aitm_phishing["ฟิชชิงแบบ AiTM (ตัวกลาง)"]
    credential_database_breach["การรั่วของฐานข้อมูลรับรอง"]
    password_authentication["การยืนยันตัวตนด้วยรหัสผ่าน"]
    password_reuse["การนำรหัสผ่านกลับมาใช้ (การโจมตีจากรายการ)"]
    account_takeover["การยึดบัญชี"]
    session_cookie_theft["การขโมยคุกกี้เซสชัน"]
    totp["รหัสใช้ครั้งเดียว (TOTP)"]
    phishing_resistant_mfa["MFA ที่ต้านฟิชชิง"]
    entra_id["Microsoft Entra ID"]
    synced_passkey["พาสคีย์แบบซิงค์"]
    platform_credential_vault["คลังข้อมูลรับรองของแพลตฟอร์ม"]
    nist_aal3["NIST AAL3 (ระดับประกันตัวพิสูจน์ตัวตน 3)"]
    platform_account_hardening["การทำให้บัญชีแพลตฟอร์มแข็งขึ้น"]
    account_recovery_abuse["การใช้กระแสกู้บัญชีในทางที่ผิด"]
    account_recovery_hardening["การเสริมการยืนยันตัวตนในกระแสกู้"]
    fallback_credential["วิธียืนยันตัวตนสำรองที่ยังอยู่คู่กัน"]
    fallback_retirement["การลดทางสำรองอย่างมีแผน"]
    passkey -->|"ใช้"| webauthn
    passkey -->|"ใช้"| fido2
    passkey -->|"ใช้"| public_key_cryptography
    fido2 -->|"ใช้"| webauthn
    fido2 -->|"ใช้"| ctap
    passkey -->|"ใช้"| authenticator
    authenticator -.->|"ใช้"| tpm
    windows_hello -.->|"ใช้"| tpm
    passkey -.->|"ใช้"| windows_hello
    passkey -.->|"ใช้"| fido2_security_key
    device_bound_passkey -->|"ใช้"| authenticator
    webauthn -->|"ต้องมี"| webauthn_secure_context
    webauthn -->|"ใช้"| webauthn_challenge
    passkey -->|"ต้องมี"| rp_id
    rp_id -->|"ป้องกัน"| phishing
    passkey -->|"ป้องกัน"| phishing
    passkey -->|"ป้องกัน"| aitm_phishing
    public_key_cryptography -->|"บรรเทา"| credential_database_breach
    password_authentication -.->|"อาจก่อให้เกิด"| credential_database_breach
    password_authentication -.->|"อาจก่อให้เกิด"| phishing
    password_authentication -.->|"อาจก่อให้เกิด"| password_reuse
    password_reuse -.->|"อาจก่อให้เกิด"| account_takeover
    aitm_phishing -.->|"อาจก่อให้เกิด"| session_cookie_theft
    totp -->|"ไม่แนะนำให้ใช้กับ"| phishing_resistant_mfa
    passkey -->|"แนวทางที่แนะนำสำหรับ"| phishing_resistant_mfa
    entra_id -.->|"ใช้"| passkey
    passkey -.->|"กำหนดค่าด้วย"| entra_id
    synced_passkey -->|"ถูกเก็บใน"| platform_credential_vault
    synced_passkey -->|"ใช้ร่วมไม่ได้"| nist_aal3
    device_bound_passkey -.->|"แนวทางที่แนะนำสำหรับ"| nist_aal3
    platform_credential_vault -.->|"อาจก่อให้เกิด"| account_takeover
    platform_account_hardening -->|"แนวทางที่แนะนำสำหรับ"| account_takeover
    account_recovery_abuse -.->|"อาจก่อให้เกิด"| account_takeover
    account_recovery_hardening -->|"แนวทางที่แนะนำสำหรับ"| account_recovery_abuse
    fallback_credential -.->|"อาจก่อให้เกิด"| account_takeover
    fallback_retirement -->|"แนวทางที่แนะนำสำหรับ"| fallback_credential
    session_cookie_theft -->|"อาจก่อให้เกิด"| account_takeover
    passkey -->|"ไม่แนะนำให้ใช้กับ"| session_cookie_theft

ในแผนภาพ เส้นทึบหมายถึงความสัมพันธ์ที่ถือเสมอ และเส้นประหมายถึงความสัมพันธ์ที่มีเงื่อนไข (เงื่อนไขอยู่ในการอธิบายของแต่ละความสัมพันธ์ในหน้าละเอียด) รายการความสัมพันธ์ทั้งหมด (รวม 38 รายการ พร้อมหลักฐานและระดับความเชื่อมั่น) และนิยามของแนวคิดหลักรวบรวมไว้ที่ หน้าละเอียดของแผนที่ความรู้ (เป็นภาษาญี่ปุ่น) ข้อมูล: JSON-LD / Turtle

2. การยืนยันตัวตนด้วยรหัสผ่านพังตรงไหน

ทางลัดที่จะเข้าใจความปลอดภัยของพาสคีย์ คือจับจุดอ่อนของรหัสผ่านด้วย «ที่ตั้ง» ในการยืนยันตัวตนด้วยรหัสผ่าน ความลับเองเดินทางทั้งช่วงทุกครั้งที่ยืนยันตัวตน

sequenceDiagram
    participant U as ผู้ใช้
    participant B as เบราว์เซอร์
    participant S as เซิร์ฟเวอร์
    Note over U: มีความลับ (รหัสผ่าน) ในหัว<br/>【จุดอ่อน①】เดาได้・ถูกนำกลับมาใช้
    U->>B: ใส่รหัสผ่าน
    Note over B: 【จุดอ่อน②】ใส่บนไซต์ปลอมได้เช่นกัน<br/> (แยกจากหน้าตาไม่ได้)
    B->>S: ส่งรหัสผ่านเอง
    Note over B,S: 【จุดอ่อน③】ความลับไหลบนเส้นทาง<br/>TLS คุ้มครอง แต่ที่ปลายกลับเป็นข้อความธรรมดา
    S->>S: จับคู่กับแฮชที่เก็บไว้
    Note over S: 【จุดอ่อน④】ความลับ (แฮช) ของผู้ใช้ทั้งหมดกองรวม<br/>ถ้ารั่วจะเป็นเป้าเดาแบบออฟไลน์

ภาพ 1: ในการยืนยันตัวตนด้วยรหัสผ่าน ความลับเองมีอยู่ทั้งช่วง

จากมุมผู้โจมตี นี่คือโครงที่มีเป้าเยอะ ยิงง่าย

• จุดอ่อน① (ผู้ใช้): ความแข็งแค่ระดับที่จำได้ และถูกนำกลับมาใช้หลายไซต์ การรั่วที่หนึ่งที่กระจายไปทุกบัญชี (การโจมตีแบบรายการรหัสผ่าน)
• จุดอ่อน② (วินาทีที่ใส่): ถ้าเตรียมไซต์ปลอมที่แยกจากของจริงไม่ได้ ผู้ใช้ยื่นความลับให้เอง (ฟิชชิง)
• จุดอ่อน③ (เส้นทาง): มี TLS จึงดักฟังเส้นทางเองยาก แต่ถ้าถูกแทรก «จุดส่งต่อที่หน้าตาถูกต้อง» ก็ไร้ความหมาย (AiTM ที่กล่าวต่อไป)
• จุดอ่อน④ (เซิร์ฟเวอร์): แม้เก็บแบบแฮช ถ้าฐานข้อมูลรั่ว ก็ถูกเดาแบบออฟไลน์ รหัสผ่านอ่อนแตกก่อน

«งั้นเติมรหัสใช้ครั้งเดียว (SMS หรือ TOTP) ก็ได้ไหม» คือการยืนยันหลายปัจจัยแบบเดิม แต่โครง ส่งความลับที่แชร์ ก็ไม่เปลี่ยน TOTP คือเซิร์ฟเวอร์กับแอปยืนยันตัวตนแชร์ซีด (ความลับ) เดียวกัน และรหัส 6 หลักที่ถูกสร้าง ผู้ใช้ก็ใส่บนไซต์ปลอมได้ จริง ๆ แล้ว ฟิชชิงแบบ AiTM (Adversary-in-the-Middle) ที่ไซต์ปลอมส่งต่อไปเซิร์ฟเวอร์จริงแบบเรียลไทม์ ทะลุชุดรหัสผ่าน+รหัสใช้ครั้งเดียวด้วยการส่งต่อทั้งก้อน CISA (หน่วยงานความมั่นคงไซเบอร์ของสหรัฐ) ยกเป็น «MFA ที่ต้านฟิชชิง» มีแค่สองอย่าง คือวิธี FIDO/WebAuthn และการยืนยันตัวตนฐาน PKI อย่างสมาร์ตการ์ด (PIV/CAC) และจัด FIDO เป็นมาตรฐานทอง ก็ด้วยเหตุนี้⁴

กล่าวคือปัญหาไม่ใช่ «ความแข็ง» ของรหัสผ่าน แต่เป็น โครง «แชร์ความลับ แล้วส่งทุกครั้งที่ยืนยันตัวตน» เอง

3. ตัวจริงของพาสคีย์ — ไม่ส่งความลับ พิสูจน์ว่ามี

พาสคีย์คือข้อมูลรับรองฐานการเข้ารหัสคีย์สาธารณะ ที่ตั้งบนสองมาตรฐานคือ WebAuthn ของ W3C และ CTAP ของ FIDO Alliance (รวมเป็น FIDO2)²¹ ฟังดูยาก แต่โครงเรียบง่าย

flowchart LR
    subgraph DEV["อุปกรณ์ของผู้ใช้"]
        AUTH["ตัวพิสูจน์ตัวตน (ตู้นิรภัย)<br/>Windows Hello / Face ID /<br/>ล็อกหน้าจอ Android / คีย์ความปลอดภัย"]
        SK["คีย์ลับ<br/>ไม่ออกจากที่นี่เลย"]
        BIO["ลายนิ้วมือ・ใบหน้า・PIN<br/>= แค่เปิดประตูตู้นิรภัย<br/>อันนี้ก็ไม่ออก"]
        AUTH --- SK
        BIO -->|"จับคู่ในเครื่อง"| AUTH
    end
    subgraph SRV["เซิร์ฟเวอร์"]
        PK["คีย์สาธารณะ<br/>รั่วแล้วก็ใช้ในทางที่ผิดไม่ได้<br/>ข้อมูล «เฉพาะตรวจ»"]
    end
    SK -.->|"คู่ทางคณิตศาสตร์<br/>(ฝั่งทำลายเซ็น)"| PK

ภาพ 2: ตัวจริงของพาสคีย์คือคู่คีย์ต่อไซต์ ฝั่งลับไม่ออกจากอุปกรณ์ เซิร์ฟเวอร์มีแค่คีย์สาธารณะสำหรับตรวจ

• คีย์ลับ คือคีย์ฝั่งทำลายเซ็นได้ ถูกเก็บในตัวพิสูจน์ตัวตนในอุปกรณ์ (Windows Hello, Face ID/Touch ID ของ iPhone, ล็อกหน้าจอ Android หรือคีย์ความปลอดภัยอย่าง YubiKey) และไม่ออก
• คีย์สาธารณะ คือคีย์ฝั่งที่ทำได้แค่ตรวจลายเซ็น ฝากอันนี้ให้เซิร์ฟเวอร์ คำนวณย้อนจากคีย์สาธารณะไปคีย์ลับทำไม่ได้ในเชิงปริมาณคำนวณ จึงเป็นข้อมูลที่รั่วก็ได้
• ข้อมูลชีวภาพ อย่างลายนิ้วมือหรือใบหน้าถูกใช้ แค่เปิดประตูตู้นิรภัยในเครื่อง และไม่ออกจากอุปกรณ์เช่นกัน ไม่มีการส่งข้อมูลชีวภาพไปเซิร์ฟเวอร์¹

การลงทะเบียน: ส่ง «แค่» คีย์สาธารณะ

กระแสตอนลงทะเบียนพาสคีย์กับไซต์

sequenceDiagram
    participant S as เซิร์ฟเวอร์ (example.com)
    participant B as เบราว์เซอร์
    participant A as ตัวพิสูจน์ตัวตน
    S->>B: คำขอลงทะเบียน (ชาเลนจ์สุ่ม + ข้อมูลไซต์)
    B->>A: สร้างคีย์สำหรับไซต์นี้ (example.com)
    A->>A: ยืนยันตัวตนด้วยลายนิ้วมือ・ใบหน้า・PIN (ในเครื่อง)
    A->>A: สร้างคู่คีย์ใหม่<br/>คีย์ลับเก็บภายใน
    A->>B: คีย์สาธารณะ + credential ID (ป้ายชื่อคีย์)
    B->>S: ส่งคีย์สาธารณะ + credential ID
    S->>S: เก็บเป็นคีย์สาธารณะของบัญชีนี้
    Note over S: สิ่งที่เซิร์ฟเวอร์รับ<br/>คือแค่ «ข้อมูลที่รั่วแล้วก็ใช้ในทางที่ผิดไม่ได้»

ภาพ 3: ตอนลงทะเบียน สิ่งที่ไหลบนเครือข่ายและถูกเก็บบนเซิร์ฟเวอร์คือแค่คีย์สาธารณะ

สำคัญคือ ตอนนี้คู่คีย์ถูกสร้าง ผูกกับโดเมนของไซต์ (RP ID) พาสคีย์ที่สร้างสำหรับ example.com ใช้ได้แค่บนไซต์ example.com (RP ID เป็นหน่วยโดเมน ดังนั้นจากหน้าซับโดเมนใต้โดเมนเดียวกันอย่าง login.example.com ใช้ได้ แต่จากโดเมนที่ไม่เกี่ยวใช้ไม่ได้) การผูกนี้คือฐานของการต้านฟิชชิงที่กล่าวต่อไป³

นอกจากนี้ คู่คีย์ถูกสร้าง ใหม่ทุกครั้งต่อไซต์ พาสคีย์ของไซต์ A กับไซต์ B ไม่เกี่ยวทางคณิตศาสตร์ จึงไม่มีแนวคิด «การนำกลับมาใช้» และไม่เป็นวัตถุดิบจับคู่ผู้ใช้ข้ามไซต์

การยืนยันตัวตน: คืนลายเซ็นเฉพาะครั้ง

กระแสตอนลงชื่อเข้าใช้ ให้เทียบกับการยืนยันตัวตนด้วยรหัสผ่าน (ภาพ 1)

sequenceDiagram
    participant S as เซิร์ฟเวอร์ (example.com)
    participant B as เบราว์เซอร์
    participant A as ตัวพิสูจน์ตัวตน
    S->>B: คำขอลงชื่อเข้าใช้ (ชาเลนจ์สุ่มเฉพาะครั้ง)
    B->>A: ขอลายเซ็นไป example.com
    A->>A: ยืนยันตัวตนด้วยลายนิ้วมือ・ใบหน้า・PIN (ในเครื่อง)
    A->>A: สร้างลายเซ็นด้วยคีย์ลับ<br/>ฝังชาเลนจ์ + ต้นกำเนิด + แฮช RP ID เข้าไป
    A->>B: ลายเซ็น (ไม่ใช่คีย์ลับเอง)
    B->>S: ส่งลายเซ็น
    S->>S: ตรวจลายเซ็นด้วยคีย์สาธารณะที่เก็บไว้<br/>ตรวจชาเลนจ์・ต้นกำเนิด・RP ID ด้วย
    Note over B,S: สิ่งที่ไหลบนเส้นทางคือแค่ลายเซ็นใช้แล้วทิ้ง<br/>ขโมยไปก็ใช้กับชาเลนจ์ครั้งถัดไปไม่ได้

ภาพ 4: ตอนยืนยันตัวตน ความลับก็ไม่ย้าย สิ่งที่ไหลคือแค่ «เอกสารพิสูจน์เฉพาะครั้ง»

เซิร์ฟเวอร์ออกเลขสุ่มใหม่ (ชาเลนจ์) ทุกครั้ง ตัวพิสูจน์ตัวตนลงลายเซ็นต่อ «ชาเลนจ์นั้น + ต้นกำเนิดที่เบราว์เซอร์กำลังดู + แฮชของ RP ID» เซิร์ฟเวอร์ตรวจลายเซ็นด้วยคีย์สาธารณะที่เก็บไว้ ยืนยันว่าชาเลนจ์คือข้อที่ตนออก และต้นกำเนิดกับ RP ID เป็นของไซต์ตน⁵

ผลของออกแบบนี้ สองในสามเหตุต้นบทความตั้งแล้ว

• บนเซิร์ฟเวอร์ไม่มีความลับ: สิ่งที่เก็บคือแค่คีย์สาธารณะ ถ้ารั่ว ผู้โจมตีทำลายเซ็นไม่ได้ จึง «นำกลับไปแล้วทุบ» แบบแฮชรหัสผ่านทำไม่ได้
• ความลับไม่ไหล: ขโมยลายเซ็นบนเส้นทางไป ชาเลนจ์ใช้ครั้งเดียวจึงนำกลับมาใช้ (รีเพลย์) ไม่ได้

ข้อที่เหลือ «บนไซต์ปลอมลายเซ็นตั้งไม่ได้» คือจุดขายใหญ่ที่สุดของพาสคีย์ จะแยกหมวดดู

4. เหตุที่ฟิชชิง «ตั้งโครงสร้างไม่ได้»

ฟิชชิงต่อรหัสผ่านสำเร็จเพราะ ใส่ความลับของจริงลงไซต์ปลอมได้ มนุษย์แยก example.com กับ examp1e.com ไม่ได้ (โดยเฉพาะเมื่อเหนื่อย) แต่ช่องใส่รหัสผ่านทำงานเหมือนกันทั้งสองไซต์

ในพาสคีย์ การจับคู่นี้ทำโดย เบราว์เซอร์อย่างเครื่องกล ไม่ใช่มนุษย์ ตามข้อกำหนด WebAuthn เบราว์เซอร์เรียกตัวพิสูจน์ตัวตนได้เฉพาะเมื่อ «โดเมนของต้นกำเนิดที่กำลังแสดง» กับ «RP ID ของพาสคีย์» ตรงกัน³ แผนภาพว่าเกิดอะไรเมื่อเข้าไซต์ปลอม

sequenceDiagram
    participant U as ผู้ใช้
    participant B as เบราว์เซอร์
    participant P as ไซต์ปลอม (examp1e.com)<br/>พร็อกซี AiTM ที่ส่งต่อไปของจริง
    participant S as เซิร์ฟเวอร์จริง (example.com)
    U->>P: เข้าหน้าลงชื่อเข้าใช้ที่หน้าตาเหมือน
    P->>S: (ลับหลัง) เริ่มกระบวนการลงชื่อเข้าใช้ของจริง
    S->>P: ชาเลนจ์
    P->>B: ส่งต่อชาเลนจ์แล้วขอลายเซ็น
    B->>B: ต้นกำเนิดตอนนี้คือ examp1e.com<br/>พาสคีย์ของ example.com เสนอเป็นตัวเลือกไม่ได้
    B--xP: ลายเซ็นไม่ถูกสร้าง (ผู้ใช้ถูกหลอกไม่ได้)
    Note over B,S: แม้มีทางใดทำลายเซ็นได้<br/>ลายเซ็นถูกฝัง examp1e.com เข้าไป<br/>การตรวจของเซิร์ฟเวอร์จริงจึงตกเสมอ

ภาพ 5: ฟิชชิงแบบ AiTM ทะลุรหัสผ่าน+รหัสใช้ครั้งเดียวได้ แต่พาสคีย์ตั้งไม่ได้ตั้งแต่ขั้นลายเซ็น

โปรดสังเกตว่าการป้องกันเป็นสองชั้น

1. ไม่ขึ้นเป็นตัวเลือก: เบราว์เซอร์แจกเฉพาะพาสคีย์ของ RP ID ที่ตรงต้นกำเนิด บนโดเมนปลอม พาสคีย์ของไซต์จริงไม่ขึ้นเป็นตัวเลือก ผู้ใช้จึง «เผลอใช้» ไม่ได้เลย
2. ลายเซ็นไม่ผ่าน: เป้าลายเซ็นรวมต้นกำเนิดที่เบราว์เซอร์ยืนยันและแฮชของ RP ID เซิร์ฟเวอร์จริงจับคู่นี้ตอนตรวจ ดังนั้นลายเซ็นที่ทำบนต้นกำเนิดอื่นถูกปฏิเสธเสมอ⁵

มาตรการฟิชชิงของรหัสผ่านพึ่งความพยายามของมนุษย์ที่ «ดู URL ให้ดี» ในพาสคีย์ ผู้ใช้ไม่จำเป็นต้องแยกไซต์ปลอมตั้งแต่ต้น นี่คือความหมายที่ถูกของคำ «ต้านฟิชชิง (phishing-resistant)» และเหตุที่ CISA กับ NIST (สถาบันมาตรฐานและเทคโนโลยีแห่งชาติสหรัฐ) จัดวิธี FIDO/WebAuthn เป็นพิเศษ⁴⁶

เนื้อหาถึงตรงนี้ จัดตามวิธีโจมตี

ตาราง 2: เปรียบเทียบความทนต่อวิธีโจมตี «○» ของพาสคีย์ทุกข้อมาจากโครงสร้าง ไม่ใช่การดำเนินงานหรือความระวัง

5. «พาสคีย์ที่ถูกซิงค์» ปลอดภัยหรือ

อ่านคำอธิบายถึงตรงนี้ คำถามนี้ย่อมเกิด «บอกว่าคีย์ลับไม่ออกจากอุปกรณ์ แล้วทำไมพาสคีย์ที่สร้างบน iPhone ใช้บน iPad ได้» ── คำถามดี และคำตอบคือ «พาสคีย์มีสองชนิด»

สรุปเป็นตารางด่วนก่อน หมวดนี้กับหมวดถัดไป อธิบายว่าทำไมแต่ละแถวของตารางจึงเป็นเช่นนั้น

*ตาราง 3: ตารางด่วนแบบซิงค์กับแบบผูกกับอุปกรณ์ การเลือกขึ้นกับว่าจะเอา «ความแข็งต่อของหาย» หรือ «จัดการที่อยู่ของกุญแจได้» *

flowchart TB
    subgraph SYNC["พาสคีย์แบบซิงค์ (ค่าเริ่มต้นฝั่งผู้บริโภค)"]
        S1["iCloud Keychain /<br/>Google Password Manager /<br/>ตัวจัดการรหัสผ่านอย่าง 1Password"]
        S2["ซิงค์ระหว่างอุปกรณ์ของบัญชีเดียวกัน<br/>แบบเข้ารหัสปลายทางถึงปลายทาง<br/>ผู้ให้บริการก็อ่านเนื้อในไม่ได้"]
        S3["ข้อดี: แข็งต่อเปลี่ยนเครื่อง・ของหาย<br/>ข้อควรระวัง: ต้องป้องกันบัญชีคลาวด์เอง"]
        S1 --> S2 --> S3
    end
    subgraph BOUND["พาสคีย์แบบผูกกับอุปกรณ์"]
        B1["คีย์ความปลอดภัย (YubiKey ฯลฯ) /<br/>Windows Hello /<br/>Microsoft Authenticator (Entra ID)"]
        B2["คีย์ลับไม่ออกจากฮาร์ดแวร์นั้น<br/>ทางกายภาพ (ถูกป้องกันด้วย TPM ฯลฯ)"]
        B3["ข้อดี: ที่อยู่ของกุญแจชัดที่เดียว<br/>ข้อควรระวัง: ต้องลงทะเบียนหลายอันกันของหาย"]
        B1 --> B2 --> B3
    end
    SYNC ~~~ BOUND

ภาพ 6: แบบซิงค์กับแบบผูกกับอุปกรณ์ ทั้งคู่เหมือนกันที่ «ไม่ส่งคีย์ลับไปเซิร์ฟเวอร์» จุดถ่วงของการป้องกันต่าง

พาสคีย์แบบซิงค์ คือแบบที่ iCloud Keychain หรือ Google Password Manager ซิงค์คีย์ลับระหว่างอุปกรณ์ของบัญชีเดียวกัน จุดสำคัญคือการซิงค์ถูก เข้ารหัสปลายทางถึงปลายทาง ทั้ง Apple และ Google ระบุชัดว่าพาสคีย์ถูกเข้ารหัสบนอุปกรณ์ก่อนซิงค์ และตัวผู้ให้บริการเองก็อ่านเนื้อในไม่ได้⁷⁸ กล่าวคือหลัก «คีย์ลับไม่ออกจากอุปกรณ์» ถูกผ่อนเป็น «คีย์ลับไม่ออกจากอุปกรณ์ในรูปข้อความธรรมดา» แลกกับความทนต่อการเปลี่ยนเครื่องและของหาย

การผ่อนนี้เปลี่ยนโมเดลภัยอย่างไร ควรพูดให้ชัด ที่ต้องป้องกันถูกรวมจาก «เซิร์ฟเวอร์ของแต่ละไซต์» ไป «บัญชีคลาวด์อันเดียว» ยังแข็งต่อการรั่วฐานข้อมูลและฟิชชิงของแต่ละไซต์เหมือนเดิม แต่คราวนี้การยึดบัญชี Apple ID/Google เองกลายเป็นจุดล้มเหลวจุดเดียว ดังนั้นบัญชีแพลตฟอร์มที่ฝากพาสคีย์ต้องได้รับการป้องกันที่แข็งที่สุด (ล็อกหน้าจอแข็ง การจัดวิธีกู้ ถ้าได้ให้ใช้คีย์ความปลอดภัยกายภาพ) เป็นข้อสมมติใหญ่ NIST ในเมษายน 2024 ก็ออก ภาคผนวกของ NIST SP 800-63B (Supplement 1: Incorporating Syncable Authenticators Into NIST SP 800-63B) และจัดอย่างเป็นทางการว่าพาสคีย์แบบซิงค์นี้ (syncable authenticator) ถ้าตรงข้อกำหนด อาจถึง AAL2 (Authenticator Assurance Level 2, ระดับการรับประกันตัวพิสูจน์ตัวตน 2) ของเกณฑ์รัฐได้ แต่เพราะคีย์ลับอาจถูกส่งออกได้ จึงระบุว่าอย่าใช้แบบซิงค์กับ AAL3 ที่ต้องการสภาพแวดล้อมที่แยกด้วยฮาร์ดแวร์⁶

พาสคีย์แบบผูกกับอุปกรณ์ คือชนิดที่คีย์ลับไม่ออกจากฮาร์ดแวร์ คีย์ความปลอดภัยอย่าง YubiKey เป็นตัวอย่างฉบับ และฝั่งนิติบุคคล พาสคีย์ของ Microsoft Entra ID (ที่สร้างใน Microsoft Authenticator) ก็เป็นแบบผูกกับอุปกรณ์⁹ Windows Hello ของ Windows ถ้ามี TPM ก็ป้องกันคีย์ลับใต้ TPM กลไก «ตู้นิรภัยฮาร์ดแวร์ที่ไม่ปล่อยกุญแจออก» นี้เอง เป็นฐานเดียวกับที่อธิบายละเอียดใน บทความ TPM

อนึ่ง ตอน «ลงชื่อเข้าใช้เบราว์เซอร์พีซีด้วยพาสคีย์มือถือ» อาจเคยสงสัยว่าทำไมต้องสแกน QR นั่นไม่ใช่แค่การย้ายหน้าจอ แต่เป็นวิธีไฮบริด (การยืนยันตัวตนข้ามอุปกรณ์ของ FIDO) ที่ ยืนยันความใกล้กายภาพระหว่างมือถือกับพีซีด้วย Bluetooth การโจมตีที่ผู้โจมตีระยะไกลให้คนอื่นอนุมัติการลงชื่อเข้าใช้พีซีตนผ่าน QR ถูกตัดด้วยการยืนยันความใกล้¹

6. ไม่ใช่กระสุนเงิน — จุดอ่อนไม่ «หาย» แต่ «ย้าย»

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

flowchart LR
    A["ผู้โจมตี"]
    G["การยืนยันตัวตนเอง<br/>ลายเซ็นชาเลนจ์<br/>【แน่น】"]
    R["กระแสกู้บัญชี<br/>แจ้งว่า «พาสคีย์หาย»<br/>ให้ตั้งใหม่ด้วย SMS หรืออีเมล<br/>แล้วลงทะเบียนพาสคีย์ของผู้โจมตี"]
    F["ทางสำรองที่อยู่คู่กัน<br/>ถ้ารหัสผ่าน・ลงชื่อเข้าใช้ SMS<br/>ยังอยู่ จุดอ่อนที่สุดอยู่ที่นั่น"]
    C["บัญชีคลาวด์<br/>แบบซิงค์แล้ว Apple ID /<br/>บัญชี Google เป็นจุดล้มเหลวจุดเดียว"]
    SS["เซสชัน<br/>ถ้าขโมยคุกกี้หลังลงชื่อเข้าใช้ได้<br/>วิธียืนยันตัวตนไม่เกี่ยว"]
    A --x G
    A --> R
    A --> F
    A --> C
    A --> SS

ภาพ 7: เมื่อประตูหน้า (การยืนยันตัวตน) แน่น การโจมตีย้ายไปกระแสกู้ ทางที่อยู่คู่กัน บัญชีคลาวด์ และเซสชัน

ความเสี่ยงที่เหลือซึ่งต้องกดในงานจริงมีสี่ข้อ

1. ทางสำรองที่อยู่คู่กันกลายเป็นจุดอ่อนที่สุด แค่ทำให้พาสคีย์ «ก็» ใช้ได้ ถ้ายังมีรหัสผ่านหรือลงชื่อเข้าใช้ SMS ผู้โจมตีใช้ทางนั้น ความต้านฟิชชิงในมุมบัญชีทั้งก้อนถูกจำกัดที่ ระดับของวิธีลงชื่อเข้าใช้ที่อ่อนที่สุด แกนของการนำเข้าไม่ใช่การเติมพาสคีย์ แต่เป็นการลดและยกเลิกทางสำรองอย่างมีแผน
2. กระแสกู้กลายเป็นหน้าโจมตีใหม่ วิธีที่แสร้งว่า «อุปกรณ์หาย» แล้วนำไปตั้งใหม่ผ่านช่องสนับสนุนหรืออีเมล ให้ลงทะเบียนพาสคีย์ของผู้โจมตีเอง จริง ๆ แล้ววิศวกรรมสังคมที่หลอกเฮลป์เดสก์เพื่อเลี่ยงการยืนยันตัวตนที่แน่น เป็นวิธีประจำของการบุกรุกขนาดใหญ่ เมื่อการยืนยันตัวตนแน่นแล้ว จึงถูกถามว่าจะออกแบบการยืนยันตัวตนในกระแสกู้อย่างไร
3. แบบซิงค์ บัญชีคลาวด์เป็นจุดล้มเหลวจุดเดียว ตามหมวดก่อน ต้องมีการป้องกันบัญชีที่ฝากพาสคีย์ และการตัดสินนโยบายว่า «อนุญาตซิงค์ไปแพลตฟอร์มใด» เมื่อใช้ในองค์กร
4. การขโมยเซสชันกันไม่ได้ พาสคีย์ป้องกันแค่วินาทีลงชื่อเข้าใช้ ถ้าคุกกี้เซสชันหลังลงชื่อเข้าใช้ถูกขโมยด้วยมัลแวร์หรือ XSS วิธียืนยันตัวตนไม่เกี่ยว งานอีกชั้นอย่างอายุโทเค็น การผูก และสุขภาพของอุปกรณ์ ยังเหลือ

เหล่านี้ไม่ใช่เรื่อง «อย่าใช้พาสคีย์» เป็นเรื่องธรรมดาที่แม้เปลี่ยนกุญแจประตูหน้าเป็นรุ่นใหม่ การล็อกหน้าต่างก็เป็นงานอีกอย่าง ตรงกันข้าม เมื่อที่ตั้งของจุดอ่อนชัด จะทุ่มทรัพยากรป้องกันไปที่กระแสกู้และการจัดการเซสชันได้

7. การนำเข้าในงานจริง — WebAuthn API กับสภาพแวดล้อม Windows

ท้ายนี้ จับจุดสำคัญจากมุมผู้นำเข้า

ติดการลงชื่อเข้าใช้พาสคีย์บนเว็บบริการของตน

ฝั่งเบราว์เซอร์มีแค่สองฟังก์ชันของ WebAuthn API การลงทะเบียนเรียก navigator.credentials.create() การยืนยันตัวตนเรียก navigator.credentials.get()

// การลงทะเบียน (ฝั่งเบราว์เซอร์)
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: challengeFromServer,   // เลขสุ่มใช้ครั้งเดียวที่เซิร์ฟเวอร์สร้าง
    rp: { id: "example.com", name: "Example" },
    user: { id: userIdBytes, name: "taro@example.com", displayName: "Taro" },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],  // ES256
    authenticatorSelection: {
      residentKey: "required",        // ทำให้เป็นข้อมูลรับรองแบบค้นพบได้ (= พาสคีย์)
      userVerification: "required",   // ทำให้ต้องยืนยันตัวตนด้วยชีวภาพหรือ PIN
    },
  },
});
// คีย์สาธารณะดึงจาก credential.response ส่วน credential ID ดึงจาก
// credential.id / credential.rawId ระดับบน คำตอบการลงทะเบียนก็ต้อง
// ตรวจฝั่งเซิร์ฟเวอร์เช่นกัน (ชาเลนจ์・ต้นกำเนิด・RP ID) ก่อนเก็บ
// เหมือนตอนยืนยันตัวตน

ความหมายของพารามิเตอร์หลักเป็นดังนี้

ตาราง 4: พารามิเตอร์หลักของ navigator.credentials.create()

ข้อควรระวังของสภาพแวดล้อมตรวจ: WebAuthn API ถูกเปิดเฉพาะในบริบทปลอดภัย ดังนั้นหน้าที่ส่งด้วย http:// เปล่า การเรียก navigator.credentials จะล้ม ข้อยกเว้นคือ http://localhost (และ 127.0.0.1) เหล่านี้ถูกจัดเป็นต้นกำเนิดที่เชื่อถือได้ จึงทดลองบนเครื่องพัฒนาโดยไม่ทำ HTTPS ได้ แต่ RP ID ต้องเป็นโดเมนที่มีผลของต้นกำเนิด (หรือโดเมนแม่) ดังนั้นพาสคีย์ที่สร้างบน localhost ใช้บนโดเมนงานจริงไม่ได้ แม้ไม่มีตัวพิสูจน์ตัวตนในมือ เปิดตัวพิสูจน์ตัวตนเสมือนในแท็บ «WebAuthn» ของเครื่องมือนักพัฒนา Chrome ก็เดินตั้งแต่ลงทะเบียนถึงยืนยันตัวตนได้ครบ

// การยืนยันตัวตน (ฝั่งเบราว์เซอร์)
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: challengeFromServer,
    rpId: "example.com",
    userVerification: "required",
  },
  // เสนอพาสคีย์เป็นตัวเลือกกรอกอัตโนมัติในช่องลงชื่อเข้าใช้
  // ตรวจว่ารองรับก่อนด้วย
  // PublicKeyCredential.isConditionalMediationAvailable() และบนเบราว์เซอร์
  // ที่ไม่รองรับ ให้ถอยกลับไปเรียกแบบปกติโดยไม่ใส่ mediation
  mediation: "conditional",
  // (ต้องระบุ autocomplete="username webauthn" ที่ <input> เป้าหมาย)
});
// ตรวจลายเซ็นใน assertion.response ฝั่งเซิร์ฟเวอร์

ตัวจริงคือการตรวจฝั่งเซิร์ฟเวอร์ อย่างน้อยต้องทำต่อไปนี้เสมอ⁵

• จับคู่ชาเลนจ์: เป็นชาเลนจ์ที่ตนออกแล้วยังไม่ใช้หรือไม่ ทำให้ใช้ครั้งเดียวหรือไม่ (กันรีเพลย์) ยิ่งไปกว่านั้น เก็บผูกกับเซสชันเบราว์เซอร์ตอนออก (ความพยายามลงชื่อเข้าใช้) และอนุญาตการบริโภคเฉพาะคำตอบจากเซสชันเดียวกัน ถ้าหลวมตรงนี้ จะมีช่องที่ผู้โจมตีส่งลายเซ็นต่อชาเลนจ์ที่ออกให้ตนผ่านเบราว์เซอร์ของผู้เสียหาย ให้ผู้เสียหายลงชื่อเข้าใช้บัญชีของผู้โจมตี (login CSRF)
• จับคู่ต้นกำเนิด: origin ใน clientDataJSON เป็นต้นกำเนิดที่ถูกของไซต์ตนหรือไม่ (แกนกันฟิชชิง)
• จับคู่แฮช RP ID: rpIdHash ใน authenticatorData ตรงกับ SHA-256 ของ RP ID ของไซต์ตนหรือไม่
• ตรวจชนิดพิธีและแฟลก: type ของ clientDataJSON เป็น webauthn.get ถ้าเป็นการยืนยันตัวตน และ webauthn.create ถ้าเป็นการลงทะเบียนหรือไม่ แฟลก UP (ผู้ใช้อยู่) ของ authenticatorData ตั้งหรือไม่ ถ้าขอการยืนยันผู้ใช้ (UV) แฟลก UV ก็ตั้งหรือไม่
• ตรวจลายเซ็น: ลายเซ็นตรวจถูกด้วยคีย์สาธารณะที่เก็บตอนลงทะเบียนหรือไม่
• การผูกกับบัญชี: ดึง credential ID (และ userHandle) ที่ถูกเสนอในฐานข้อมูลตน แล้วออกเซสชันให้เจ้าของข้อมูลรับรองนั้นหรือไม่ ถ้าเชื่อชื่อผู้ใช้ที่ใส่แยกโดยไม่มีเงื่อนไข จะเป็นรูที่ลงชื่อเข้าใช้เป็นคนอื่นด้วยลายเซ็นที่ถูก
• เก็บและเปรียบตัวนับลายเซ็น: เก็บ signCount ของ authenticatorData ต่อข้อมูลรับรอง แล้วยืนยันว่าค่าครั้งถัดไปมากกว่าครั้งก่อน ถ้าต่ำกว่าหรือเท่ากับค่าก่อน (รวมค่าเท่า) ให้ถือเป็นสัญญาณของการทำสำเนาตัวพิสูจน์ตัวตน (โคลน) แต่พาสคีย์แบบซิงค์มักคืน 0 เสมอ จึงยอมเป็นข้อยกเว้นเฉพาะคู่ 0 กับ 0

การเขียนการตรวจนี้ด้วยมือเป็นต้นเหตุอุบัติเหตุ จึงใช้ไลบรารีที่มีผลงาน (.NET ใช้ fido2-net-lib, Node.js ใช้ SimpleWebAuthn ฯลฯ) รายละเอียดข้อกำหนด (พาร์ส CBOR ข้อตกลงอัลกอริทึม การจัดการชาเลนจ์) ปล่อยให้ไลบรารี เราโฟกัสที่การเก็บและเพิกถอนชาเลนจ์ UI จัดการพาสคีย์หลายอัน และการออกแบบกระแสกู้ คือการแบ่งแรงที่ถูก

กรณีสภาพแวดล้อม Windows・ระบบในองค์กร

จากชั้นผู้อ่านไซต์นี้ คือ «ตำแหน่งที่รับผิดชอบระบบงาน Windows» กดสามข้อต่อไปนี้ก็พอ

• ไคลเอนต์ Windows รองรับแล้ว Windows 11 รองรับการสร้าง ใช้ และจัดการพาสคีย์ด้วย Windows Hello เป็นตัวพิสูจน์ตัวตน (การตั้งค่า > บัญชี > พาสคีย์) และคีย์ลับถ้ามี TPM จะถูกป้องกันด้วยฮาร์ดแวร์¹⁰ WebAuthn ผ่านเบราว์เซอร์ (Edge/Chrome) ทำงานบน Windows 10 ด้วย
• ในสภาพแวดล้อม Entra ID ให้เปิด «พาสคีย์ = วิธียืนยันตัวตน FIDO2» Microsoft Entra ID รองรับคีย์ความปลอดภัยและพาสคีย์ในแอป Microsoft Authenticator (แบบผูกกับอุปกรณ์) และถ้าขอ «MFA ที่ต้านฟิชชิง» ด้วยความเข้มของการยืนยันตัวตนใน Conditional Access จะจำกัดการเข้าถึงทรัพยากรเป้าหมายให้เหลือพาสคีย์ ฯลฯ ได้⁹ การย้ายจากโลกของ NTLM และนโยบายอายุรหัสผ่านไม่ได้ก้าวเดียว ดังนั้นคู่กับการตรวจนับฐานยืนยันตัวตนใน บทความ NTLM กับ Kerberos หลักคือบังคับ MFA ที่ต้านฟิชชิงจากบัญชีผู้ดูแลก่อน
• เว็บแอปในองค์กรก็ได้คุณเดียวกัน แต่ HTTPS เป็นข้อสมมติ WebAuthn API ทำงานได้แค่ในบริบทปลอดภัย ดังนั้นแม้แอปอินทราเน็ต (ยกเว้น localhost ตอนพัฒนา) ต้องทำ HTTPS และการจัดชื่อโดเมนภายในที่ใช้เป็น RP ID ก่อน แค่เสร็จ RP ID ก็ทำงานต่อโดเมนภายในได้ ในความหมายของการเลิกโน้ตรหัสผ่าน ผลออกเร็วกว่าบริการภายนอกก็ไม่แปลก

8. สรุป

• จุดอ่อนของรหัสผ่านไม่ใช่ความแข็ง แต่เป็น โครง «แชร์ความลับ แล้วส่งทุกครั้งที่ยืนยันตัวตน» ความลับมีอยู่ทั้งผู้ใช้ ช่องใส่ เส้นทาง และเซิร์ฟเวอร์ เป้าโจมตีจึงเยอะ แม้เติมรหัสใช้ครั้งเดียว ฟิชชิงแบบ AiTM ก็ส่งต่อแล้วชนะ
• พาสคีย์คือ คู่คีย์ของการเข้ารหัสคีย์สาธารณะต่อไซต์ ส่งให้เซิร์ฟเวอร์แค่คีย์สาธารณะที่รั่วแล้วก็ใช้ในทางที่ผิดไม่ได้ และตอนลงชื่อเข้าใช้ส่งแค่ลายเซ็นต่อชาเลนจ์ใช้ครั้งเดียว บนเซิร์ฟเวอร์ไม่มีความลับ และบนเส้นทางก็ไม่มีความลับไหล
• ลายเซ็นถูก อบต้นกำเนิดและ RP ID ที่เบราว์เซอร์ยืนยัน ดังนั้นบนไซต์ปลอม พาสคีย์ของของจริงไม่ขึ้นเป็นตัวเลือก และส่งต่อก็ตกตอนตรวจ ผู้ใช้ไม่จำเป็นต้องแยกไซต์ปลอม คือตัวจริงของ «ความต้านฟิชชิง» และฐานของการป้องกันย้ายจากความระวังของมนุษย์ไปโครงสร้างของโปรโตคอล
• พาสคีย์แบบซิงค์ถูกซิงค์ด้วย การเข้ารหัสปลายทางถึงปลายทาง แข็งต่อการเปลี่ยนเครื่องและของหาย แลกกับที่ต้องป้องกันถูกรวมที่บัญชีคลาวด์ ดังนั้นการป้องกันบัญชี Apple ID/บัญชี Google เองเป็นข้อสมมติใหญ่ นิติบุคคลเลือกแบบผูกกับอุปกรณ์ (คีย์ความปลอดภัย พาสคีย์ Authenticator ของ Entra ID) ได้ด้วย
• พาสคีย์ไม่ทำให้การโจมตีหาย แต่ ผลักไปที่ที่อ่อน รหัสผ่านที่อยู่คู่กัน กระแสกู้บัญชี และการขโมยเซสชัน คือหน้าโจมตีที่เหลือ และแกนของการนำเข้าอยู่ที่การลดทางสำรองอย่างมีแผนกับการทำให้กระแสกู้แข็ง
• การอิมพลีเมนต์คือสองฟังก์ชัน create / get ของ WebAuthn API + การตรวจเซิร์ฟเวอร์ อย่าเขียนการตรวจเอง ให้ไลบรารีที่มีผลงาน แล้วทุ่มแรงที่การจัดการชาเลนจ์ UI พาสคีย์หลายอัน และการออกแบบการกู้

บทความที่เกี่ยวข้อง

• TPM ของ Windows คืออะไร — แผนภาพ «ตู้นิรภัยที่ไม่ปล่อยกุญแจออก» กับการบูตแบบวัด
• แผนภาพ NTLM กับ Kerberos — ทำไมการยืนยันตัวตนจึง «ตก» ไป NTLM
• ฝังการยืนยันตัวตน Entra ID ในแอป WinForms/WPF — โครงปฏิบัติของ MSAL.NET กับโบรกเกอร์ WAM
• การจัดการข้อมูลรับรองอย่างปลอดภัยใน PowerShell — ไล่รหัสผ่านข้อความธรรมดาออกจากสคริปต์
• รายการตรวจความปลอดภัยขั้นต่ำของการพัฒนาแอป Windows
• มาตรการความปลอดภัยของธุรกิจขนาดกลางและเล็ก เริ่มจากตรงไหน — เดินตามแนวทางความปลอดภัยข้อมูลของ IPA สำหรับ SME ฉบับที่ 4.0

ด้านให้คำปรึกษาที่เกี่ยวข้อง

KomuraSoft LLC รับ Custom Software Development รวมการสนับสนุนการอิมพลีเมนต์ WebAuthn สำหรับการลงชื่อเข้าใช้พาสคีย์บนระบบเว็บในองค์กร การออกแบบการนำออก MFA ที่ต้านฟิชชิงในสภาพแวดล้อม Entra ID และการฝังการยืนยันตัวตนในแอปธุรกิจ Windows อย่าง WinForms/WPF

บทความที่เกี่ยวข้อง

บทความล่าสุดที่มีแท็กเดียวกัน เพื่อเจาะลึกหัวข้อใกล้เคียง

หัวข้อที่เกี่ยวข้อง

หน้าเหล่านี้วางหัวข้อไว้ในบริบทที่กว้างขึ้นของบริการและการตัดสินใจ

คำถามที่พบบ่อย

คำถามที่มักพบในการปรึกษาเกี่ยวกับหัวข้อของบทความนี้

ความต่างพื้นฐานระหว่างพาสคีย์กับรหัสผ่านคืออะไร?

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

ข้อมูลชีวภาพ (ลายนิ้วมือ・ใบหน้า) ถูกส่งไปเซิร์ฟเวอร์หรือไม่?

ไม่ส่ง ข้อมูลลายนิ้วมือหรือใบหน้าถูกใช้แค่ในเครื่องเพื่อ «เปิดประตูตู้นิรภัยที่ใส่คีย์ลับ» เป็นการจับคู่ท้องถิ่น และตามออกแบบของ FIDO ข้อมูลชีวภาพไม่ถูกส่งออกนอกอุปกรณ์ สิ่งที่เซิร์ฟเวอร์รับคือแค่ลายเซ็นที่มีแฟลกว่า «มีการยืนยันตัวตนผู้ใช้ (user verification)» ไม่มีทั้งลายนิ้วมือเองและเวกเตอร์ลักษณะใด ๆ ในสถานการณ์ที่ใช้ชีวภาพไม่ได้ แทนด้วย PIN ได้ แต่ PIN นี้ก็เหมือน PIN ของ Windows Hello ที่จับคู่เฉพาะในเครื่อง ไม่ไหลบนเครือข่าย ซึ่งต่างจากรหัสผ่านอย่างขาด

ทำไมพาสคีย์จึงต้านฟิชชิงได้?

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

ถ้ามือถือหาย จะเข้าบัญชีไม่ได้หรือ?

ถ้าเป็นพาสคีย์แบบซิงค์ (ที่เก็บใน iCloud Keychain หรือ Google Password Manager) กู้ไปอุปกรณ์ใหม่ที่ลงชื่อเข้าใช้ Apple ID/บัญชี Google เดียวกันได้ แต่การกู้คลังที่เข้ารหัสปลายทางถึงปลายทางไม่ใช่แค่รหัสผ่านบัญชี ยังต้องยืนยันตัวตนเพิ่มอย่างใส่ล็อกหน้าจอ (รหัสผ่าน) ของเครื่องเดิม ดังนั้นถ้าเสียวิธีกู้เหล่านี้ด้วย อาจกู้ไม่ได้ การไม่ฝากทุกอย่างไว้ที่มือถือเครื่องเดียวสำคัญ พาสคีย์แบบผูกกับอุปกรณ์ (คีย์ความปลอดภัย Windows Hello ฯลฯ) ร่วมชะตากับเครื่อง ดังนั้นบัญชีสำคัญให้ลงทะเบียนพาสคีย์หลายอันเป็นหลัก บริการจำนวนมากลงทะเบียนพาสคีย์หลายอันต่อบัญชีได้ โปรดทราบว่าขั้นตอนเพิกถอนตอนหายต่างตามชนิด แบบซิงค์ สำเนาบนแต่ละเครื่องคือข้อมูลรับรองอันเดียว ดังนั้นให้ลบเครื่องที่หายหรือรีโมตวายป์ฝั่งบัญชีแพลตฟอร์มก่อน เพื่อให้สำเนาบนเครื่องใช้ไม่ได้ (ถ้าลบพาสคีย์นั้นในการตั้งค่าบัญชีฝั่งบริการ สำเนาทุกเครื่องถูกเพิกถอนพร้อมกัน) แบบผูกกับอุปกรณ์ ลบพาสคีย์ของตัวพิสูจน์ตัวตนนั้นฝั่งบริการ ก็เพิกถอนได้แค่กุญแจที่หาย การใช้ในองค์กร ออกแบบทั้ง «การทำสำรองให้ผู้ใช้กู้เองได้» และ «ขั้นตอนที่ผู้ดูแลเพิกถอนตอนหาย» เป็นชุดเดียวกันสำคัญ

พาสคีย์มีจุดอ่อนด้วยหรือ?

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

โปรไฟล์ผู้เขียน

หน้าแนะนำผู้เขียนบทความ

Go Komura

ผู้แทนของ KomuraSoft LLC

เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ Windows ที่ปรึกษาเทคนิค และการตรวจสอบบั๊ก โดยเฉพาะโปรเจกต์ที่มีระบบเดิมและบั๊กที่ทำซ้ำได้ยาก