ที่อยู่อีเมลไม่เหมาะจะเป็นตัวระบุบัญชีแบบ 'ถาวร'

 (utcc.utoronto.ca)
4 คะแนน โดย GN⁺ 2024-01-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ที่อยู่อีเมลไม่เหมาะจะเป็นตัวระบุบัญชีแบบ 'ถาวร'

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

ตัวระบุภายในควรไม่มีความหมาย

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

ความเห็นของ GN⁺

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

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

1 ความคิดเห็น

 
GN⁺ 2024-01-01
ความคิดเห็นบน Hacker News

  • ข้อจำกัดของอีเมลและชื่อผู้ใช้

    • ที่อยู่อีเมลสามารถเปลี่ยนได้ และผู้คนอาจสูญเสียการเข้าถึงอีเมลเก่า
    • มีความไม่พอใจกับชื่อผู้ใช้ และผู้คนต้องการเลือกชื่อที่ไม่จำเป็นต้องไม่ซ้ำกัน เช่น แทนที่จะใช้ชื่ออย่าง user53267
    • บางครั้งก็ทำอุปกรณ์หาย และการพึ่งพาเพียง UUID ลับที่เก็บไว้ในคุกกี้หรือ passkey ของอุปกรณ์อย่างเดียวก็ไม่เพียงพอ
    • แม้จะมีคนที่ใช้อีเมลหรือชื่อผู้ใช้เดิมอย่างคงที่ แต่แทบไม่มีใครใช้อุปกรณ์หลักเครื่องเดิมนานหลายปี
    • มักเกิดปัญหาบ่อยกับบัญชีอีเมลสำหรับงาน (first.last@company.com) และซอฟต์แวร์ของผู้ขายที่ใช้วิธี 'เข้าสู่ระบบด้วย Google'
    • ผู้คนแต่งงาน หย่าร้าง เปลี่ยนเพศ และย้ายวัฒนธรรมจนเลือกชื่อใหม่ได้ ชื่อและที่อยู่อีเมลจึงเปลี่ยนแปลงได้
    • สิ่งอย่าง OIDC อาจต้องการมาตรฐาน API สำหรับการเปลี่ยนชื่อผู้ใช้และที่อยู่อีเมล

  • วิธีรับมือส่วนตัว

    • Gmail อาจถูกล็อกแบบสุ่มโดยอัลกอริทึม AI และเมื่อมีปัญหาก็มักได้รับการเยียวยายาก
    • Yahoo อาจยืนยันตัวตนด้วยอีเมลเก่า ทำให้สูญเสียการเข้าถึงได้
    • Yahoo/AOL/Tutanota/Protonmail เป็นต้น อาจลบบัญชีอัตโนมัติหากไม่ได้ล็อกอินบ่อย
    • การโฮสต์เองก็ยังต้องใช้อีเมลเริ่มต้น และถ้าสูญเสียอีเมลนั้นก็อาจสูญเสียการเข้าถึงบัญชีโฮสติ้ง
    • Duo push อาจเป็นปัญหาเมื่อโทรศัพท์เสีย
    • การยืนยันตัวตนผ่าน SMS อาจเสี่ยงจากโทรศัพท์เสีย การสูญเสียการเข้าถึงแพ็กเกจบริการ หรือปัญหาความปลอดภัยจากพนักงาน
    • การใช้อีเมล Gmail ของมหาวิทยาลัยดูเหมือนจะเป็นวิธีที่ดีที่สุดในตอนนี้ เพราะหากมีปัญหาสามารถขอความช่วยเหลือจากศูนย์สนับสนุนของมหาวิทยาลัยได้

  • ปัญหาของอีเมลและหมายเลขโทรศัพท์

    • อีเมลไม่เหมาะจะเป็นตัวระบุถาวร และการใช้หมายเลขโทรศัพท์เป็นส่วนหนึ่งของการระบุตัวยิ่งแย่กว่า
    • แม้จะใช้อีเมลเดิมผ่านโดเมนของตัวเองมาเกือบ 20 ปี แต่ในช่วงเวลาเดียวกันกลับเปลี่ยนหมายเลขโทรศัพท์ไปเกือบ 12 หมายเลข
    • กำลังจ่ายเงินให้ AT&T ราว $150 ต่อเดือนเพื่อคงหมายเลขสหรัฐฯ ไว้แม้อยู่ต่างประเทศ

  • ข้อเสนอเรื่องที่อยู่อีเมลแบบกุญแจสาธารณะ

    • มีการเสนอแนวคิดให้รองรับที่อยู่อีเมลแบบกุญแจสาธารณะ (<pk-12345@gmail.com>)
    • แม้ Google หรือ Hotmail จะยุติบริการ ก็ยังเข้าถึงบัญชีเดิมได้จากบริการอื่นโดยยืนยันตัวตนด้วยกุญแจส่วนตัว
    • ทำให้ไคลเอนต์อีเมลสามารถแมปที่อยู่ลักษณะนี้หรือใช้กุญแจสาธารณะในการติดตามได้
    • แนวคิดนี้ต้องการการรองรับในวงกว้าง แต่ก็น่าคิด

  • การใช้ UUID

    • มีความเห็นว่า UUID แบบสุ่มคือทางเลือกที่ดีที่สุด
    • การแฮชอีเมลเริ่มต้นของผู้ใช้อาจไม่เพียงพอ แม้จะใส่ salt แล้วก็ตาม

  • การเชื่อมโยงที่อยู่อีเมลหลายรายการ

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

  • ปัญหาการเชื่อมที่อยู่อีเมลกับที่อยู่จริง

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

  • โซลูชันฝั่งไคลเอนต์

    • สามารถจ่ายค่าโดเมนเพื่อควบคุมอีเมล alias ได้ 100%
    • แม้ผู้ให้บริการปัจจุบันอย่าง Google จะมีปัญหา ก็ยังโฮสต์เมลบนเซิร์ฟเวอร์ของตัวเองเพื่อค้นคืนบัญชีและคงความเป็นเจ้าของ alias ไว้ได้

  • ปัญหาของการระบุตัวตนและการยืนยันตัวตน

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

  • ปัญหาฝั่งแบ็กเอนด์

    • สำหรับผู้ใช้ อีเมลอาจเป็น ID แต่ภายในข้อมูลของระบบไม่ควรใช้อีเมลเป็น primary key
    • นี่เป็นปัญหาพื้นฐานของการออกแบบฐานข้อมูล โดยควรมีตาราง lookup ที่แมปไปยัง ID เฉพาะ (UUID หรือเลขเพิ่มอัตโนมัติจาก sequence) โดยไม่ใช้ตัวระบุอย่างอีเมลโดยตรง
    • บทความไม่ได้แยกความแตกต่างนี้ให้ชัด จนอาจทำให้อ่านเหมือนผู้ใช้ควรต้องรับรู้ abstraction นี้เอง