Tags:
Node Thumbnail

ปัญหาความปลอดภัยพื้นฐานที่สุดที่เราพบกันได้เสมอในทุกวันนี้ไม่ใช่ช่องโหว่ซอฟต์แวร์ที่ต้องอาศัยความรู้ทางเทคนิค แต่ยังคงเป็นการขโมยรหัสผ่านด้วยวิธีการต่างๆ ไม่ว่าจะเป็นผู้ใช้บอกให้ผู้อื่นรับรู้ หรือแม้แต่เก็บรหัสผ่านไว้อย่างไม่ปลอดภัย ไม่ว่าจะเป็นการจดไว้ตามที่ต่างๆ หรือเก็บไว้ในไฟล์ หรือกระทั่งการตั้งรหัสผ่านี่ง่ายมากๆ เช่น "1234" หรือ "password"

ความพยายามแก้ปัญหาที่ผ่านมาไม่ประสบความสำเร็จนัก เพราะเซิร์ฟเวอร์สามารถบังคับได้เพียงความซับซ้อนของรหัสผ่าน และกำหนดนโยบายการเปลี่ยนรหัสผ่านตามช่วงเวลาเท่านั้น แต่เราไม่สามารถบังคับให้ผู้ใช้รักษาความลับของรหัสผ่านเป็นอย่างดีได้ แนวทางในช่วงหลายปีที่ผ่านมาจึงเปลี่ยนไป คำแนะนำใหม่ๆ ระบุให้ไม่ต้องบีบบังคับผู้ใช้จนเกินไปนัก แต่แนะนำให้เปิดให้ผู้ใช้สามารถเลือกใช้ขั้นตอนที่สองในการยืนยันตัวตน (2-factor authentication)

การยืนยันตัวตนสองขั้นตอนใช้งานมานานในหมู่ผู้ดูแลระบบที่ต้องการความปลอดภัยสูง หรือบัญชีธนาคารที่ทุกวันนี้ธนาคารมักส่งรหัสผ่านที่สองมาให้ผู้ใช้ผ่าน SMS เพื่อยืนยันตัวตนซ้ำ กระบวนการยืนยันตัวตนด้วยขั้นตอนที่สองนี้เป็นมาตรฐาน IETF สองแบบ คือ HOTP และ TOTP

alt="upic.me"

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

alt="upic.me"

กระบวนการ TOTP อาศัยหลักการว่าเซิร์ฟเวอร์และผู้ใช้มีข้อมูลลับแชร์ร่วมกันอยู่ เมื่อนำข้อมูลนี้มาต่อเชื่อมเข้ากับข้อมูลเวลาแล้วแฮชจะทำให้ได้ค่าที่ตรงกันทั้งเซิร์ฟเวอร์และเครื่องของผู้ใช้ ซึ่งอาจจะเป็นคอมพิวเตอร์ขนาดเล็กเท่าพวงกุญแจหรืออาจจะเป็นซอฟต์แวร์ในโทรศัพท์มือถือ ข้อจำกัดของการทำงานเช่นนี้คือทั้งสองฝั่งต้องรักษาค่าเวลาให้ตรงกันตลอดเวลา (อ่านเพิ่มเติม - การสร้าง Google Authenticator ด้วย Arduino) ซึ่งเป็นข้อจำกัดว่าอุปกรณ์ต้องมีแบตเตอรี่เพื่อรักษาค่าเวลาตลอดเวลา

alt="upic.me"

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

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

กูเกิลร่วมกับผู้ผลิตกุญแจยืนยันตัวตนขั้นตอนที่สองอย่าง Yubico วางมาตรฐานใหม่ เพื่อให้มีกระบวนการยืนยันตัวตนที่ผู้ใช้เพียงแค่เก็บรักษากุญแจนั้นให้ปลอดภัย ตัวกุญแจมีความสามารถในการยืนยันได้ว่าผู้ที่ขอยืนยันตัวตนนั้นเป็นบริการเดิมกับที่ลงทะเบียนไว้หรือไม่ แล้วออกมาเป็นมาตรฐานกลาง U2F พร้อมกับสร้างองค์กร FIDO Alliance ขึ้นมาดูแลมาตรฐาน

กระบวนการตรวจสอบนี้ทำให้ U2F ต้องมีองค์ประกอบ 3 อย่าง ได้แก่ FIDO Relying Party เป็นเซิร์ฟเวอร์ที่รองรับการยืนยันตัวตนด้วย U2F, FIDO Client ที่ในกรณีเว็บก็คือเบราว์เซอร์ที่รองรับ U2F, และ Token ที่เป็นตัวกุญแจสำหรับการยืนยันตัวตนโดยตรง

alt="upic.me"

เมื่อเว็บต้องการให้ผู้ใช้ยืนยันตัวตนด้วย Token จะมีขั้นตอนดังนี้

  1. เว็บจะส่งข้อมูลร้องขอให้เบราว์เซอร์ลงทะเบียน (register) ตัวเว็บเข้ากับกุญแจ เว็บจะขึ้นข้อความแจ้งผู้ใช้ขอให้เสียบ Token ใน USB (U2F รองรับช่องทางอื่นๆ ด้วย เช่น NFC และ Bluetooth) เว็บจะแจ้งชื่อของตัวเอง (App ID) พร้อมกับข้อมูลทดสอบการลงทะเบียน (challenge) ไปยังเบราว์เซอร์
  2. ตัวเบราว์เซอร์เองจะตรวจสอบความถูกต้องของข้อมูลและสร้างเป็นข้อมูลแสดงตัวตนเว็บ (Client Data) จากนั้นแฮชทั้งค่า Client Data และ challenge แล้วส่งไปให้ Token
  3. Token สร้างกุญแจสาธารณะสำหรับการลงทะเบียนครั้งนี้คืนให้กับเบราว์เซอร์ โดยสร้างกุญแจสาธารณะสำหรับการลงทะเบียน (public key) พร้อมกับแสดงใบรับรองดิจิตอลของผู้ผลิต (attestation certificate) ที่ติดมากับตัว Token และข้อมูลการลงทะเบียน (key handle) จากนั้น เซ็นข้อมูลทั้งหมดด้วยกุญแจลับของผู้ผลิต (attestation private key) ที่ฝังอยู่ใน Token
  4. เบราว์เซอร์รับค่าจาก Token แล้วคืนค่าไปยังเว็บ โดยเพิ่มค่า client data กลับไปยังเว็บ
  5. เว็บจะสามารถตรวจสอบผู้ผลิตได้จากใบรับรองดิจิตอลของผู้ผลิต หากยอมรับข้อมูลทั้งหมด ถือว่ากระบวนการลงทะเบียนเสร็จสิ้น

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

alt="upic.me"

เมื่อลงทะเบียนเรียบร้อยแล้ว การยืนยันตัวตนครั้งต่อๆ ไปจะเรียกว่าการลงชื่อ (sign) เพื่อเข้าใช้งานระบบ

  1. เว็บจะส่งข้อมูล key handle, App ID, และข้อมูลทดสอบ (challenge - เป็นข้อมูลคนละชุดกับตอนลงทะเบียนและเปลี่ยนไปทุกครั้งที่ยืนยันตัวตน)
  2. เบราว์เซอร์จะตรวจสอบความถูกต้องของ App ID เช่น URL ที่เว็บอ้างมา ตรงกับ URL จริงที่เบราว์เซอร์เห็นหรือไม่ ขั้นตอนนี้ช่วยป้องกันการ phishing เพราะหากเป็นเว็บปลอมที่กำลังพยายามคั่นกลางการล็อกอินของเว็บอื่น
  3. ตัว Token ตรวจสอบความถูกต้องของ key handle จากนั้นจึงเซ็นลายเซ็นดิจิตอลสำหรับเว็บที่ขอตรวจสอบ
  4. เว็บได้รับข้อมูลกลับมา สามารถตรวจสอบลายเซ็นดิจิตอลที่ได้รับด้วยกุญแจสาธารณะที่ได้รับมาเมื่อลงทะเบียน Token ว่ายังเป็น Token เดิมหรือไม่

แนวทางการออกแบบของ U2F นั้นคำนึงถึงการอิมพลีเมนต์ในฮาร์ดแวร์ราคาถูกที่อาจจะมีหน่วยความจำแบบถาวรในตัวเพียงเล็กน้อย การที่มาตรฐานบังคับให้เซิร์ฟเวอร์ต้องส่งค่า key handle กลับมาทุกครั้ง ทำให้ตัว Token สามารถใช้ค่า key handle ในการสร้างกุญแจลับ ที่คู่กับกุญแจสาธารณะที่เว็บได้รับครั้งแรกเอง

alt="upic.me"

กรณีของ Yubico ก็ใช้กระบวนการนี้ โดยจะใช้ค่าสุ่มประจำครั้งของการลงทะเบียน (nonce) มาสร้างกุญแจลับและกุญแจสาธารณะ แล้วส่งค่า nonce เป็นค่า key handle ให้เซิร์ฟเวอร์ส่งกลับมาทุกครั้ง เมื่อตัว Token ได้รับค่า nonce ในการลงยืนยันตัวตนครั้งต่อๆ ไปจึงสามารถสร้างกุญแจลับกลับมาได้โดยไม่ต้องจำไว้ว่าเว็บใดสร้างกุญแจไว้แบบใด

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

U2F จึงไม่ใช่เรื่องของการออกแบบเพียงอย่างเดียว แต่เป็นเรื่องของการเผยแพร่แนวทางเพื่อให้เป็นที่ยอมรับในวงกว้าง การเสนอมาตรฐานใหม่ๆ แต่กลับไม่มีผู้ให้บริการรายใหญ่เข้าร่วมทำให้ข้อเสนอจำนวนมากไม่ประสบความสำเร็จ การที่ U2F ได้รับการสนับสนุนจากกูเกิลตั้งแต่แรกทำให้ผู้ใช้ที่เป็นไปได้ (potential user) ของโปรโตคอลนี้มีจำนวนมาก ขณะที่ผู้ใช้เองก็มีเหตุผลที่จะซื้อ Token มาใช้งานกันมากขึ้นเพราะอย่างน้อยที่สุดก็สามารถใช้งานกับบริการของกูเกิลได้เป็นอย่างแรก แม้ว่าการใช้งานยังอยู่เพียงระดับเริ่มต้น บริการสำคัญๆ ที่รองรับ U2F ยังมีเพียงกูเกิลและ GitHub เราก็คงต้องเอาใจช่วยว่ามาตรฐานเช่นนี้จะได้รับความนิยมในวงกว้างกันต่อไป

Get latest news from Blognone

Comments

By: osmiumwo1f
ContributorWindows PhoneWindows
on 5 December 2015 - 14:19 #866266
osmiumwo1f's picture

แต่การใช้เว็บ

ตรงย่อหน้าที่ 6 เหมือนว่าโดนดัดจบครับ

By: panurat2000
ContributorSymbianUbuntuIn Love
on 5 December 2015 - 22:09 #866345 Reply to:866266
panurat2000's picture

หรือกระทั่งการตั้งรหัสผ่านี่ง่ายมากๆ

รหัสผ่านี่ => รหัสผ่านที่

เพื่อแก้ปัญหการยืนยันตัวตนที่แข็งแกร่ง

ปัญหการ => ปัญหาการ

By: LazarusSP1
ContributoriPhone
on 5 December 2015 - 21:17 #866335

เผื่อใครไม่ได้ฟัง Session นี้ใน #bcbk ผมอัดวิดีโอไว้ให้นะครับ

By: hisoft
ContributorWindows PhoneWindows
on 5 December 2015 - 21:51 #866340 Reply to:866335
hisoft's picture

ขอบคุณครับ จองเลย