เว็บออเทนทิเคชัน

เว็บออเทนทิเคชัน  หรือ เว็บออเทน  เป็นมาตรฐานเว็บที่เผยแพร่โดยเวิลด์ไวด์เว็บคอนซอร์เทียม (W3C)
เป็นส่วนประกอบหลักของโปรเจ็กต์ไฟโด 2 (FIDO2 Project) ซึ่งสมาคมไฟโดอัลไลแอนซ์ (FIDO Alliance) เป็นผู้ดูแล
เป้าหมายของโปรเจ็กต์ก็คือสร้างมาตรฐานส่วนประสาน (interface) ที่ใช้พิสูจน์ตัวผู้ใช้แอปหรือผู้ใช้บริการเว็บด้วยการเข้ารหัสแบบกุญแจอสมมาตร (public-key cryptography)
ในระบบรับบริการ (client) มาตรฐานสามารถทำให้เกิดผลได้ด้วยวิธีหลายอย่าง
ซึ่งการเข้ารหัสจะทำโดยหน่วย ออเทนทิเคเทอร์  อันเป็นโมเดลปฏิการแบบนามธรรมที่โดยมากไม่#เปลี่ยนทาง ว่าตัวกุญแจรหัสจะต้องจัดการอย่างไร
จึงทำให้สามารถสนับสนุนเว็บออเทนได้ด้วยซอฟต์แวร์ล้วน ๆ โดยยังสามารถใช้หน่วย trusted execution environment (TEE) และ Trusted Platform Module (TPM) ของหน่วยประมวลผลกลางช่วยได้
ปฏิบัตการเข้ารหัสลับและถอดรหัสลับที่ต้องเก็บความลับไว้ให้ได้ อาจใช้#เปลี่ยนทาง แบบฮาร์ดแวร์และเคลื่อนที่ได้ (roaming hardware authenticator) ต่างหาก ๆ โดยต่อกับระบบผ่านยูเอสบี บลูทูธ หรือการสื่อสารสนามใกล้ (NFC)
ออเทนทิเคเทอร์แบบฮาร์ดแวร์จะต้องสนับสนุน#เปลี่ยนทาง CTAP (Client to Authenticator Protocol) ที่เป็นส่วนของมาตรฐานไฟโด
จึงทำให้#เปลี่ยนทาง ใช้กับมาตรฐาน U2F (Universal 2nd Factor) ดั้งเดิมของไฟโดได้
เหมือนกับมาตรฐาน U2F ดั้งเดิม เว็บออเทนสามารถป้องกันการหลอกว่าเป็นผู้ใช้ได้ นั่นก็คือ สามารถป้องกันฟิชชิงได้
แต่ไม่เหมือนกับ U2F เว็บออเทนไม่ต้องใช้รหัสผ่าน
อนึ่ง ออเทนทิเคเทอร์แบบฮาร์ดแวร์และเคลื่อนที่ได้ยังป้องกันมัลแวร์ได้ เพราะคอมหรือสมาร์ทโฟนจะไม่สามารถเข้าถึงกุญแจส่วนตัว (private key)
W3C ได้เผยแพร่เว็บออเทนรุ่นที่#เปลี่ยนทาง 1 และ 2 (level 1 and 2) ในวันที่#เปลี่ยนทาง 4 มีนาคม 2019 และ 8 เมษายน 2021 ตามลำดับ
ส่วนรุ่นที่#เปลี่ยนทาง 3 ยังอยู่ในสถานะ "First Public Working Draft" (FPWD)
พื้นเพ.
FIDO2 เป็นมาตรฐานรุ่นสืบทอดจาก U2F ซึ่งก็เป็นของสมาคมไฟโดเช่นกัน โดยต่างกับ U2F ซึ่งสนับสนุนการพิสูจน์ตัวผู้ใช้ด้วยปัจจัยหลายอย่าง (MFA) เท่านั้น เพราะ U2F ได้ออกแบบเพื่อเพิ่มความปลอดภัยของการลงชื่อเข้าบัญชีแบบใช้ชื่อผู้ใช้บวกกับรหัสผ่าน ต่างกับ FIDO2 ที่สามารถพิสูจน์ตัวผู้ใช้ด้วยปัจจัยเดียวเท่านั้น ในโหมดปัจจัยเดียว ออเทนทิเคเทอร์จะเริ่มปฏิบัติการโดยตรวจสอบว่าผู้ใช้อยู่ตรงนั้น ซึ่งปกติเป็นการให้กดปุ่ม โดยไม่ต้องลงบันทึกรหัสผ่าน ส่วนในโหมด#เปลี่ยนทาง หลายอย่าง ออเทนทิเคเทอร์เอง (เป็นสิ่งที่ผู้ใช้มี) จะเป็นตัวตรวจสอบผู้ใช้ (verification) โดยวิธีตรวจสอบจะขึ้นอยู่กับลูกเล่นที่ออเทนทิเคเทอร์สนับสนุน นี่อาจจะเป็น
ไม่ว่าจะเป็นโหมดไหน ออเทนทิเคเทอร์จะไม่เปิดเผยความลับหรือลักษณะทางชีวมิติที่มีแก่เว็บไซต์
อนึ่ง ความลับของผู้ใช้อันเดียวกันหรือลักษณะทางชีวมิติอันเดียวกันก็สามารถใช้กับเว็บไซต์ได้ทั้งหมด เพราะตัวออเทนทิเคเทอร์เองจะเป็นตัวเลือกกุญแจลับที่ใช้เซ็นการพิสูจน์ผู้ใช้สำหรับเว็บไซต์นั้น ๆ โดยทำหลังจากที่ผู้ใช้พิสูจน์ตนแล้ว (ด้วยความลับหรือลักษณะทางชีวมิติ) 
อนึ่ง ความลับกับลักษณะทางชีวมิติก็ยังสามารถใช้ร่วมกันได้ คล้ายกับที่พบในสมาร์ทโฟน
เช่น ผู้ใช้สามารถเปิดใช้สมาร์ทโฟนได้ด้วยลายนิ้วมือเป็นปกติอย่างสะดวก แต่บางครั้งที่ลายนิ้วมือใช้ไม่ได้ ก็จะต้องใช้รหัส PIN แทน
คำอธิบายทั่วไป.
เหมือนกับมาตรฐานไฟโดดั้งเดิมคือ U2F การยืนยันผู้ใช้ด้วยระบบเว็บออเทนทิเคชัน (เว็บออเทน) จะมีฝ่ายต่าง ๆ คือ เว็บไซต์, เว็บเบราว์เซอร์/ระบบรับบริการ (client) และออเทนทิเคเทอร์
มาตรฐานเว็บออเทนระบุว่า ผู้อ้างว่าคือผู้ใช้ควรยืนยันแก่ผู้ตรวจสอบผู้ใช้คือ WebAuthn Relying Party อย่างไรว่าตนมีออเทนทิเคเทอร์แบบ FIDO2 ในการควบคุม
ส่วนผู้อำนวยกระบวนการพิสูจน์ผู้ใช้ก็คือ WebAuthn Client ซึ่งปกติก็คือเว็บเบราว์เซอร์
การพิสูจน์ตัวจริง (authentication).
เพื่อแสดงเป็นตัวอย่าง ออเทนทิเคเทอร์จะสมมุติว่าเป็นแบบฮาร์ดแวร์และเคลื่อนที่ได้ (เช่น ยูบิคีย์)
เป็น#เปลี่ยนทาง แบบหลายปัจจัยที่ใช้การเข้ารหัสแบบกุญแจอสมมาตรเพื่อเซ็นการยืนยันว่าได้พิสูจน์บุคคล (authentication assertion) แล้วสำหรับ WebAuthn Relying Party
ถ้าออเทนทิเคเทอร์ใช้รหัส PIN เพื่อพิสูจน์ผู้ใช้ ตัวออเทนทิเคเทอร์เองจะเป็น "สิ่งที่ผู้ใช้มี" และรหัส PIN จะเป็น "สิ่งที่ผู้ใช้รู้"
เพื่อเริ่มกระบวนการพิสูจน์ผู้ใช้ของเว็บออเทน
WebAuthn Relying Party จะระบุความต้องการกับระบบรับบริการเว็บออเทน (คือ เว็บบราวเซอร์) ผ่านจาวาสคริปต์ แล้วระบบรับบริการเว็บออเทนก็จะสื่อสารกับออเทนทิเคเทอร์ด้วยเอพีไอจาวาสคริปต์ที่เว็บบราวเซอร์ทำให้เกิดผล โดยตัวออเทนทิเคเทอร์จะใช้โพรโทคอล Client to Authenticator Protocol ของไฟโด
อย่างไรก็ดี มาตรฐานเว็บออเทนไม่ได้กำหนดให้ต้องใช้ออเทนทิเคเทอร์แบบฮาร์ดแวร์และเคลื่อนที่ได้
เพราะสามารถใช้ออเทนทิเคเทอร์แบบซอฟต์แวร์ (เช่น ที่ทำให้เกิดผลในสมาร์ทโฟน) หรือออเทนทิเคเทอร์แบบแพลต์ฟอร์ม (คือ ที่ทำให้เกิดผลโดยตรงบนอุปกรณ์ที่มีระบบรับบริการเว็บออเทน เช่น ระบบปฏิบัติการที่มีเว็บบราวเซอร์)
ตัวอย่างออเทนทิเคเทอร์แบบแพลต์ฟอร์มก็เช่น วินโดวส์ฮัลโหล
และระบบปฏิบัติการแอนดรอยด์
กระบวนการที่เป็นตัวอย่างนั้นพิสูจน์ผู้ใช้ด้วยรหัส PIN ซึ่งในมุมมองของการใช้ง่าย ก็ดีกว่าการพิสูจน์ด้วยรหัสผ่านไม่มากนัก เพราะการพิสูจน์ทางชีวมิติ (biometric) จะทำให้ผู้ใช้พิสูจน์ตัวตนด้วยเว็บออเทนได้ง่ายกว่า แม้ผู้ใช้ปกติจะไม่เข้าใจการพิสูจน์ทางชีวมิติ เพราะมักเข้าใจผิดว่า ข้อมูลทางชีวมิติจะส่งไปที่เครือข่ายคล้ายกับที่ส่งรหัสผ่าน ซึ่งจริง ๆ ไม่เป็นอย่างนั้น
การลงทะเบียน.
เมื่อ WebAuthn Relying Party ได้รับการยืนยันพิสูจน์ตัวตนที่ได้เซ็นด้วยรหัสลับ (signed authentication assertion) แล้วจากเว็บบราวเซอร์ ก็จะตรวจสอบการยืนยันนั้นด้วยกุญแจสาธารณะที่เชื่อถือได้ของผู้ใช้ คำถามก็คือ แล้วจะได้กุญแจนั้นมาจากไหนในเบื้องต้น
ในเบื้องต้น เพื่อจะได้กุญแจสาธารณะจากผู้ใช้ WebAuthn Relying Party จะลงทะเบียนผู้ใช้
ซึ่งคล้ายกับกระบวนการพิสูจน์ผู้ใช้ดังที่กล่าวไปแล้ว
แต่แทนที่จะเซ็นรองรับการยืนยันพิสูจน์ตัวตน (assertation) ออเทนทิเคเทอร์จะเซ็นรายงานที่เรียกว่า attestation statement ด้วยกุญแจส่วนตัวของ#เปลี่ยนทาง เองที่ใช้ในกิจนี้ โดยรายงาน attestation ที่เซ็นนี้แล้วส่งไปให้แก่ WebAuthn Relying Party ก็จะแนบเอารหัสสาธารณะของผู้ใช้ที่ WebAuthn Relying Party จะใช้ตรวจสอบการยืนยันพิสูจน์ตัวตนของผู้ใช้ (assertion) ต่อ ๆ ไป
รายงาน attestation จะมีข้อมูลอภิพันธุ์ที่ระบุตัวออเทนทิเคเทอร์เอง
ส่วนลายเซ็นดิจิทัลที่ใช้เซ็นรายงาน attestation จะต้องตรวจสอบด้วยกุญแจสาธารณะสำหรับรายงาน attestation ที่เชื่อถือได้สำหรับตัวออเทนทิเคเทอร์รุ่นนั้น ๆ แต่ WebAuthn Relying Party จะได้คลังกุญแจสาธารณะที่เชื่อถือได้มาได้อย่างไร มาตรฐานเองก็ไม่ได้ระบุไว้ วิธีหนึ่งก็คือให้ใช้บริการข้อมูลอภิพันธุ์ของไฟโดเอง
ชนิดของ attestation ที่ระบุไว้ในจาวาสคริปต์จะเป็นตัวกำหนดโมเดลความเชื่อใจ (trust model)
เช่น สำหรับชนิดที่เรียกว่า self-attestation โมเดลความเชื่อใจก็คือ เชื่อใจเมื่อใช้เป็นครั้งแรก (trust on first use)
การรองรับ.
เวิลด์ไวด์เว็บคอนซอร์เทียมได้แนะนำให้กลุ่ม Web Authentication Working Group ตีพิมพ์เว็บออเทนรุ่นที่#เปลี่ยนทาง 1 เมื่อวันที่#เปลี่ยนทาง 4 มีนาคม 2019
เว็บบราวเซอร์ต่าง ๆ รวมทั้งกูเกิล โครม, มอซิลลา ไฟร์ฟอกซ์, ไมโครซอฟท์ เอดจ์, ซาฟารี และโอเปร่า ล้วนสนับสนุนมาตรฐานนี้
โครมรุ่นบนคอมได้สนับสนุนมาตรฐานนี้ตั้งแต่รุ่นที่#เปลี่ยนทาง 67
ส่วนไฟร์ฟอกซ์ที่ไม่เคยสนับสนุนมาตรฐาน U2F ของไฟโดอย่างเต็มรูปแบบ ก็ได้สนับสนุนมาตรฐานนี้มาตั้งแต่รุ่นที่#เปลี่ยนทาง 60 ซึ่งเผยแพร่เมื่อวันที่#เปลี่ยนทาง 9 พฤษภาคม 2018
ส่วนเอดจ์สนับสนุนมาตรฐานนี้ให้ใช้ได้ทั้งด้วยวินโดวส์ฮัลโหลและกุญแจความปลอดภัยต่างหาก (external security key) ตั้งแต่ Build 17682
กุญแจความปลอดภัยแบบ U2F ของไฟโดที่มีมาก่อนสามารถเข้ากับมาตรฐานนี้ได้ แต่เว็บออเทนจริง ๆ จะสามารถใช้ข้อมูล "user handle" ที่เป็นเอกลักษณ์สำหรับบัญชีหนึ่ง ๆ ที่ออเทนทิเคเทอร์แบบ U2F จะไม่เก็บ
ออเทนทิเคเทอร์อันแรกๆ ที่สนับสนุนไฟโด 2 ก็คือ ยูบิคีย์ของยูบิโกะ ซึ่งประกาศขายในวันที่#เปลี่ยนทาง 10 เมษายน 2518
ส่วนออเทนทิเคเทอร์ไฟโด 2 ที่มีหน้าจออันแรกก็คือ Trezor Model T ของซาโตชิแหล็บส์ ซึ่งประกาศขายในวันที่#เปลี่ยนทาง 6 พฤศจิกายน 2019
โดยยังเป็นออเทนทิเคเทอร์รุ่นแรกที่ให้ผู้ใช้เลือก resident credential ที่อุปกรณ์ควรจะใช้โดยตรง
บริการเก็บไฟล์ในกลุ่มเมฆ (cloud) คือ Dropbox ได้ประกาศให้ใช้เว็บออเทนเป็นปัจจัยที่#เปลี่ยนทาง 2 เพื่อลงชื่อเข้าบัญชีตั้งแต่วันที่#เปลี่ยนทาง 8 พฤษภาคม 2018
ส่วนแอปเปิลได้ประกาศว่า Face ID และ Touch ID จะใช้เป็นออเทนทิเคเทอร์ของเว็บออเทนได้เริ่มตั้งแต่ซาฟารีรุ่น 14 ในวันที่#เปลี่ยนทาง 24 มิถุนายน 2020
เอพีไอ.
มาตรฐานนี้เป็นการขยายเอพีไอ Credential Management ของ W3C ซึ่งเป็นเอพีไอที่ระบุปฏิสัมพันธ์ระหว่างเว็บไซต์กับเว็บบราวเซอร์เมื่อแลกเปลี่ยนข้อมูลยืนยันผู้ใช้
คือ เอพีไอของเว็บออเทนทิเคชัน
จะขยายเมทอดจาวาสคริปต์ คือ #เปลี่ยนทาง และ #เปลี่ยนทาง ให้รับพารามิเตอร์เพิ่มคือ <code>publicKey</code>
โดยเมทอด <code>create</code> จะเอาไว้ลงบันทึกออเทนทิเคเทอร์ให้สัมพันธ์กับบัญชีผู้ใช้ โดยอาจทำเมื่อสร้างบัญชีใหม่ก็ได้ แต่มักทำเมื่อเพิ่มอุปกรณ์ความปลอดภัยใหม่ในบัญชี 
และเมทอด <code>get</code> เอาไว้ยืนยันการพิสูจน์ผู้ใช้ (เช่นเมื่อลงชื่อเข้าบัญชี)
สามารถตรวจสอบว่าเว็บบราวเซอร์รับรองเว็บออเทนได้หรือไม่โดยตรวจดูว่าส่วนประสาน <code>window.PublicKeyCredential</code> นั้นมีกำหนดไว้หรือไม่
มาตรฐานยังกำหนดส่วนประสานอื่นๆ อีกรวมทั้ง <code>AuthenticatorResponse</code>, <code>AuthenticatorAttestationResponse</code> และ <code>AuthenticatorAssertionResponse</code>
เอพีไอไม่อนุญาตให้เข้าถึงหรือจัดการกุญแจส่วนตัวได้โดยตรงนอกเหนือไปจากการสร้างกุญแจขึ้นใหม่ในเบื้องต้น
การตอบรับ.
ในเดือนสิงหาคม 2018 บริษัทที่ชำนาญด้านความปลอดภัยของเว็บ คือ Paragon Initiative Enterprises ได้ตรวจสอบความปลอดภัย (security audit) ของมาตรฐานนี้
แม้จะไม่พบวิธีการแฮ็กระบบอย่างใดอย่างหนึ่งโดยเฉพาะ แต่ก็พบความบกพร่องของวิธีการเข้ารหัสที่มาตรฐานระบุ
ปัญหาหลักมีอยู่ 2#เปลี่ยนทาง อย่างซึ่งเคยเป็นปัญหากับระบบการเข้ารหัสที่ใช้มาแล้วในอดีต ดังนั้น จริง ๆ จึงไม่ควรใช้เพื่อไม่ให้ตกเป็นเหยื่อของวิธีการแฮ็กเช่นเดียวกันอีก
บริษัทยังได้วิจารณ์ถึงกระบวนการที่มาตรฐานนี้ได้พัฒนาขึ้นในเบื้องต้น เพราะมาตรฐานที่เสนอไม่ได้เปิดเผยอย่างเป็นสาธารณะโดยล่วงหน้า และก็ไม่ได้ปรึกษานักวิทยาการรหัสลับที่ชำนาญ ดังนั้น มาตรฐานจึงไม่ได้ผ่านการวิจัยทางวิทยาการรหัสลับอย่างถี่ถ้วน
แม้จะมีปัญหาเช่นนี้ บริษัทก็ยังสนับสนุนให้ผู้ใช้ใช้มาตรฐานนี้ต่อไป บริษัทมีข้อแนะนำสำหรับผู้ทำให้เกิดผลและนักพัฒนามาตรฐานโดยหวังว่าข้อแนะนำจะทำให้เกิดผลก่อนที่มาตรฐานจะได้ออกอย่างเป็นทางการ
การหลีกเลี่ยงปัญหาเช่นนี้ตั้งแต่ต้น ๆ จะทำให้ไม่ต้องประสบปัญหากับมาตรฐานที่บกพร่องและปัญหาในด้านพัฒนาการที่ต้องทำให้เข้ากับมาตรฐานก่อน ๆ ได้
เชิงอรรถและอ้างอิง.
<templatestyles src="Reflist/styles.css" />