อีเมลไม่เหมาะเป็นตัวระบุบัญชีแบบ “ถาวร”
(utcc.utoronto.ca)- เมื่อสร้าง ID บัญชีระยะยาวภายในระบบ หากใช้อีเมลเป็น ID ถาวร เพียงเพราะ OIDC ส่งคืนที่อยู่อีเมลมา ก็จะต้องแบกรับปัญหาทั้งการเปลี่ยนแปลงและการนำกลับมาใช้ซ้ำ
- ที่อยู่อีเมลอาจเปลี่ยนได้แม้ภายในองค์กรเดียวกัน เช่นเดียวกับชื่อหรือ login จึงไม่มั่นคงพอที่จะใช้เป็น ค่าหลักของบัญชี
- แม้จะยังเข้าถึงอีเมลเดิมหรือมีการส่งต่อเมลจากที่อยู่เดิมอยู่ ก็ไม่มีหลักประกันว่าที่อยู่นั้นจะยังใช้งานได้ต่อใน การใช้งานที่ไม่ใช่อีเมล เช่น การยืนยันตัวตนผ่าน OIDC
- การกู้คืนบัญชีอาจจำเป็นต้องใช้ที่อยู่อีเมล แต่หากระบบยืนยันตัวตนมี ID ที่ไม่ซ้ำและถาวรแยกต่างหากให้ ก็ควรใช้ค่านั้นเป็น ID ภายใน
- แม้จะเป็นค่าที่ผู้ใช้มองไม่เห็น ตัวระบุภายในบัญชีก็ควรเป็น ID ที่ไม่มีความหมายในตัวเอง ซึ่งทำให้การดำเนินงานระยะยาวและด้านความปลอดภัยเรียบง่ายกว่า
เหตุผลที่ทำให้อยากใช้อีเมลเป็น ID ถาวร
- เหตุผลที่ที่อยู่อีเมลมักถูกนึกถึงเป็นตัวเลือกเมื่อสร้างตัวระบุภายในสำหรับแต่ละบัญชี คือ ระบบยืนยันตัวตนอย่าง OIDC ส่งคืนข้อมูลที่รวมถึงที่อยู่อีเมล
- แต่หากใช้ที่อยู่อีเมลเป็น ตัวระบุภายในถาวร ของบัญชี จะเกิดปัญหาสองอย่างคือ ความเป็นไปได้ที่จะเปลี่ยนแปลง และความเป็นไปได้ที่จะถูกนำกลับมาใช้ซ้ำ
ที่อยู่ที่เปลี่ยนได้ย่อมเป็นค่าหลักได้ยาก
- ปัญหาใหญ่ที่สุดคือที่อยู่อีเมล สามารถเปลี่ยนได้
- อีเมลของคนคนหนึ่งอาจเปลี่ยนได้แม้อยู่ในองค์กรเดียวกัน
- อาจเปลี่ยนด้วยเหตุผลประเภทเดียวกับที่ ชื่อที่ใช้ในชีวิตประจำวัน หรือ login ของคนคนหนึ่งเปลี่ยนได้
- การปฏิเสธไม่ให้เปลี่ยนหรือออกที่อยู่อีเมลที่องค์กรจัดสรรให้ใหม่ อาจเป็นเรื่องโหดร้ายถึงขั้นยากจะดำรงอยู่ได้ในทางกฎหมายในหลายที่
- แม้ที่อยู่อีเมลเดิมจะไม่ได้หายไปโดยสิ้นเชิง ก็ยังไม่เพียงพอสำหรับการเป็น ตัวระบุถาวร
- อาจยังเข้าถึงที่อยู่เดิมได้ หรือยังมีการส่งต่ออีเมลอยู่
- ถึงอย่างนั้น ที่อยู่เดิมก็อาจไม่ทำงานต่อในการใช้งานที่ไม่ใช่อีเมล เช่น การยืนยันตัวตนผ่าน OIDC
- ผู้ใช้ต้องการใช้ที่อยู่ใหม่ปัจจุบัน แทนที่อยู่อีเมลเดิมที่อาจทำให้ไม่สะดวก
การนำกลับมาใช้ซ้ำและอีเมลสำหรับกู้คืนควรจัดการแยกกัน
- ปัญหาที่เล็กกว่า คือไม่มีหลักประกันว่าองค์กรจะ ไม่นำที่อยู่อีเมลกลับมาใช้ซ้ำ
- โดยทั่วไปแล้วอาจมีการนำกลับมาใช้ซ้ำได้
- โดยเฉพาะที่อยู่ซึ่งเป็นที่ต้องการสูง อาจถูกนำกลับมาใช้ซ้ำหรือจัดสรรใหม่เป็นกรณีพิเศษ เพราะบุคคลที่มีอิทธิพลต้องการ
- หากการกู้คืนบัญชีต้องทำผ่านที่อยู่อีเมลที่ลงทะเบียนไว้ ก็อาจจำเป็นต้องเก็บอีเมลไว้
- แต่ในกรณีอย่าง OIDC ซึ่งในทางทฤษฎีมี ID ภายในที่ไม่ซ้ำและถาวรอยู่แล้ว ก็ควรใช้ ID ภายใน นั้น
- แม้จำเป็นต้องเก็บอีเมลสำหรับกู้คืนบัญชี ตัวระบุภายในของบัญชีก็ควรเป็น ID ที่ไม่มีความหมายในตัวเอง
- แม้ค่านี้จะไม่ถูกเปิดเผยต่อผู้ใช้ก็ตาม แต่ในระยะยาวจะทำให้การดำเนินงานเรียบง่ายขึ้น
- หากใส่ความหมายให้ที่อยู่อีเมลมากเกินไป ก็อาจมี ปัญหาด้านความปลอดภัย ซ่อนอยู่ด้วย
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ไม่มี ตัวระบุตัวตนที่ดี
อีเมลเปลี่ยนได้ และบางครั้งก็เสียสิทธิ์เข้าถึงอีเมลเก่า
ชื่อผู้ใช้ก็มีหลายคนไม่ชอบ จึงอยากเลือกชื่อที่ไม่จำเป็นต้องไม่ซ้ำ มากกว่าจะใช้ชื่อเฉพาะที่ไร้ความหมายอย่าง
user53267อุปกรณ์ก็ทำหายได้เหมือนกัน ดังนั้นแค่เก็บ UUID ลับไว้ในคุกกี้ หรือใช้ passkey ของอุปกรณ์อย่างเดียวก็แก้ปัญหาไม่ได้
ไม่มีวิธีแก้ที่สมบูรณ์แบบ ต้องผสมหลายวิธีเข้าด้วยกัน สำหรับบางคน อีเมลคงอยู่ยาวนานและเสถียร จึงเหมาะเป็นตัวระบุตัวตน แต่สำหรับบางคน ชื่อผู้ใช้เสถียรกว่าและชอบแบบนั้นมากกว่า อย่างไรก็ตาม แทบไม่เคยเห็นใครใช้อุปกรณ์หลักเครื่องเดิมนานหลายปี นับประสาอะไรกับหลายสิบปี ดังนั้นการระบุตัวตนที่อิงอุปกรณ์คงใช้ได้ไม่ดีนัก
เรื่องนี้เห็นได้ชัดเป็นพิเศษกับอีเมลที่ทำงานแบบ
first.last@company.comซอฟต์แวร์จากผู้ให้บริการจำนวนมากใช้ Sign in with Google แล้วเก็บที่อยู่อีเมลนั้นเป็นตัวระบุตัวตนภายในแอปของผู้ให้บริการชื่อเปลี่ยนได้จากการแต่งงาน การหย่า การเปลี่ยนผ่านทางเพศ การย้ายบริบททางวัฒนธรรม การเลือกชื่อใหม่ ฯลฯ และที่อยู่อีเมลก็เปลี่ยนตาม
บางทีสิ่งอย่าง OIDC อาจต้องมีส่วนขยายใหม่ เช่น API มาตรฐานสำหรับเปลี่ยนชื่อผู้ใช้ และ API มาตรฐานสำหรับเปลี่ยนที่อยู่อีเมล
ถ้าไม่นับตัวระบุทางการอย่างบัตรประจำตัวทางราชการหรือหมายเลขประกันสังคม ก็ดูยากที่จะทำให้ดีกว่านี้
subต้องไม่ถูกนำไปกำหนดใหม่และต้องไม่ซ้ำกัน: https://openid.net/specs/openid-connect-core-1_0.html#IDToke...แน่นอนว่านั่นหมายความว่าไม่ควรใส่ที่อยู่อีเมลลงใน
subของ ID tokenเคยเจอบริษัทที่เมื่อเปลี่ยนสถานะเป็นพนักงานประจำแล้วต้องสร้างบัญชีใหม่ทั้งหมด และเพราะไม่มีระบบสิทธิ์ที่เรียบง่ายและรวมศูนย์ หลังเปลี่ยนสถานะแล้วต้องใช้เวลาประมาณ 3 สัปดาห์กว่าจะได้สิทธิ์เข้าระบบที่เพิ่งเข้าถึงได้เมื่อวันก่อนกลับมา
ที่ตลกกว่านั้นคือบริษัทนั้นทำธุรกิจจำนวนมากเกี่ยวกับการให้ระบบบัญชีที่ซับซ้อนแก่ลูกค้า และยังมีระบบตัวตนสำหรับภายนอกที่จัดการปัญหาแบบนี้ได้ง่ายด้วย แต่กลับไม่เอามาใช้กับพนักงานภายในที่ดูแลระบบตัวตนสำหรับภายนอกนั้นเอง
ทุกคนมีตัวเลขต่อท้ายอยู่แล้ว ตัวเลขจึงไม่ได้มีความหมายมากนัก ตอนเปลี่ยนไปเป็น ID บัญชีที่ไม่ซ้ำกันก็รู้สึกเสียดายนิดหน่อย และจนถึงตอนนี้ก็ยังสงสัยว่าทำไมถึงเปลี่ยน
ในฐานะบุคคลทั่วไป แนวทางที่ดีที่สุดในการรับมือปัญหานี้คืออะไร?
Gmail อาจถูกล็อกกะทันหันหรือถูกแบนบัญชีเพราะอัลกอริทึม AI และถ้ามีอะไรผิดพลาดก็ไม่มีช่องทางเยียวยา
Yahoo เพิ่งขอให้ยืนยันตัวตนตอนล็อกอินด้วยอีเมลที่ไม่ใช้งานซึ่งไม่ได้เข้าถึงมา 15 ปี ทำให้เสียสิทธิ์เข้าถึงไป โชคดีที่ยังเข้าถึงอีเมลไคลเอนต์ได้ จึงย้ายบัญชีสำคัญ ๆ ออกมาได้
Yahoo/AOL/Tutanota/Protonmail/และอีกหลายเจ้า จะลบบัญชีอัตโนมัติถ้าไม่ได้ล็อกอินบ่อยพอ Protonmail ยังไม่ทำตอนนี้ แต่เงื่อนไขการใช้งานอนุญาตให้ทำได้
การโฮสต์เองก็ยังต้องใช้อีเมลสำหรับโครงสร้างพื้นฐานทั้งหมดตั้งแต่แรก ถ้าเสียสิทธิ์เข้าถึงอีเมลนั้น ก็อาจพลาดการแจ้งเตือนชำระเงินและเสียบัญชีโฮสติ้งได้ เคยเกือบเสียโดเมนเพราะการแจ้งเตือนชำระเงินถูกส่งไปยังอีเมลที่แทบไม่เคยเช็ก เพราะไม่รองรับ IMAP ถ้าไม่ใช่ผู้ดูแลระบบมืออาชีพและไม่มีเวลาบำรุงรักษามากพอ ความเสี่ยงถูกแฮ็กก็สูงขึ้นด้วย
Duo push ก็จบถ้ามือถือพัง ส่วนการยืนยันตัวตนด้วย SMS ก็มีปัญหาอย่างมือถือเสีย การเสียสิทธิ์เข้าถึงแพ็กเกจโทรศัพท์ หรือพนักงานภายในปล่อยโค้ดรั่ว
สุดท้ายเลยตัดสินใจใช้ที่อยู่ Gmail ของมหาวิทยาลัย เพราะสัญญาว่าศิษย์เก่าจะยังเก็บไว้ได้ และถ้ามีอะไรผิดพลาด—น่าจะเป็นกรณีทำมือถือหายจนเสีย 2FA—ก็มีศูนย์ช่วยเหลือศิษย์เก่าที่พอใช้ได้
จำเป็นต้องมี ช่องทางช่วยเหลือที่เป็นคนจริง ๆ ให้คุยด้วยสักที่ ถึงอย่างนั้นก็ยังไม่มั่นใจว่านี่ดีที่สุดหรือไม่ และยังสงสัยว่ายังมีความเสี่ยงฝั่ง Google เหลืออยู่หรือเปล่า
อย่างที่บอก ถ้าถูกล็อก ก็ “แค่” เปลี่ยนผู้ให้บริการ และอย่างมากก็เสียอีเมลไปไม่กี่ชั่วโมง
เห็นด้วยว่าอีเมลไม่เหมาะเป็นตัวระบุถาวร แต่การใช้ หมายเลขโทรศัพท์ เป็นส่วนหนึ่งของการระบุตัวตนยิ่งแย่กว่า
ผมใช้อีเมลเดิมกับโดเมนของตัวเองมาเกือบ 20 ปีแล้ว แต่ในช่วงเวลาเดียวกันหมายเลขโทรศัพท์เปลี่ยนไปเกือบ 12 เบอร์ มักเห็นกรณีที่เว็บไซต์เปิด 2FA ไว้กับเบอร์เก่า หรือเจ้าตัวลืมไปเลยว่าเคยลงทะเบียนเบอร์เก่าไว้กับเว็บไซต์นั้น
แม้ตอนอยู่ต่างประเทศ ผมยังคงจ่าย ภาษีประมาณ 150 ดอลลาร์ ให้ AT&T ทุกเดือนเพื่อรักษาเบอร์สหรัฐฯ ไว้ เพราะยังมีเว็บที่ส่งโค้ดล็อกอินมาที่เบอร์นั้น และกลัวว่าถ้าทิ้งไปจะสูญเสียการเข้าถึงบริการสำคัญที่ลืมอัปเดตไว้ หรือต้องใช้เบอร์สหรัฐฯ จนเปลี่ยนไม่ได้
ถ้าวันหลังอยากใช้เบอร์นั้นกับบัญชีมือถืออีกครั้ง ก็โอนกลับไปยังผู้ให้บริการเครือข่ายที่ต้องการได้
2FA ที่ทำได้ให้เปลี่ยนไปใช้แอปอย่าง Google Authenticator แล้วโอนเบอร์ไป Google Voice ก็จะรับข้อความที่ส่งมายังเบอร์เก่าได้ฟรี
ถ้าไม่อยากยุ่งกับ Google เลย ก็มีแอปยืนยันตัวตนแบบ time-based อื่น ๆ อีกมาก และอาจใช้ www.tossabledigits.com สำหรับข้อความได้
แม้มองเป็นบริการมือถือทั่วไปก็ยังแพงเกินไป ผมจ่ายไม่ถึง 100 ดอลลาร์ต่อเดือนสำหรับสองสาย
ตอนย้ายบ้านเมื่อก่อน เบอร์โทรศัพท์สำนักงานส่วนตัวของผมใช้ในพื้นที่ใหม่ไม่ได้ แต่โชคดีที่โอนไปบัญชี VoIP ได้
ตอนนั้นอินเทอร์เน็ตยังช้าอยู่ เลยใช้อะแดปเตอร์โทรศัพท์ผ่าน Ethernet อยู่พักหนึ่ง หลังจากนั้นใช้เบอร์นั้นเป็นแบบรับสายอย่างเดียว ทั้งสายเสียงและแฟกซ์ถูกส่งต่อไปยังอีเมลทั้งหมด
ใช้งานได้ดีมานานกว่า 20 ปีแล้ว เพราะไม่มีอุปกรณ์ต้องต่อ ค่าใช้จ่ายรายปีก็ค่อนข้างต่ำ
สักวันอาจต่อโทรศัพท์เพื่อใช้ประโยชน์จากอินเทอร์เน็ตสมัยใหม่ก็ได้ แต่ตอนนี้ชอบวิธีนี้ และชอบที่มันไม่ผูกติดกับสถานที่ใดสถานที่หนึ่ง
ประสบการณ์ของผมก็เหมือนกัน โดยส่วนตัวคิดว่า UUID แบบสุ่ม ดีที่สุด
แม้แต่แฮชของอีเมลแรกของผู้ใช้ก็ยังไม่เหมาะ การใส่ salt อย่างเดียวอาจไม่พอ และคนอื่นอาจคิดเอาเองว่าอีเมลอินพุตแบบไหนก็เอาไปแฮชได้อย่างปลอดภัย
ในงานจริง ผมใช้เลขจำนวนเต็มแบบ auto-increment หรือสตริงสุ่ม/UUID เป็น primary key เสมอ
มันต้องไม่เกี่ยวข้องกับคุณสมบัติในโลกจริงที่ผู้คนให้ความสำคัญ เช่น เบอร์โทร อีเมล หมายเลขประจำตัวประชาชนแบบรัฐออกให้ ชื่อ หรือรอยนิ้วมือ
สตริงสุ่มตรงตามเงื่อนไขนี้พอดี เลขจำนวนเต็มเรียงลำดับก็ใช้ได้ แต่เดาง่าย จึงอาจต้องมีมาตรการความปลอดภัยเพิ่มเติม
ถ้ารองรับที่อยู่อีเมลแบบ public key ล่ะ? เช่น ปฏิบัติกับสิ่งอย่าง . และสิ่งอย่าง . ให้เท่าเทียมกัน
ให้สมัครด้วยฝั่งหนึ่ง แล้วล็อกอินหรือกู้บัญชีด้วยอีกฝั่งได้ ถ้า Google แบนผม หรือ Hotmail ล่มสลาย ผมก็ไปใช้บริการอื่น ยืนยันตัวตนด้วย private key แล้วเปิดบัญชีเดิมได้
แน่นอนว่าคงต้องมีกระบวนการ alias เพื่อใช้ชื่อที่สะดวก แต่ดูเหมือนเมลไคลเอนต์ต้อง map ที่อยู่แบบนั้น หรืออย่างน้อยติดตามมันคู่กับ public key
อาจเป็นโอกาสแทรก อีเมลเข้ารหัสแบบ end-to-end เข้าไปด้วย สิ่งนี้แทบไม่เคยตั้งหลักได้ในวงกว้าง
ถ้าจะให้ใช้งานได้จริง ผู้ให้บริการรายใหญ่ต้องรองรับ แต่ลองคิดคร่าว ๆ แล้วก็ดูค่อนข้างแข็งแรงทีเดียว ติดแค่ว่ายังไม่มีใครรองรับเท่านั้น
กำลังมีการสร้างวิธีใหม่ ๆ สำหรับระบุตัวตนและสื่อสารบนเว็บ โดยที่คุณเป็นเจ้าของอัตลักษณ์ของตัวเอง ไม่ต้องพึ่งผู้ให้บริการหรือผู้มีอำนาจกลาง
ผู้ให้บริการพลังงานรายก่อนของผมคือ British Gas (ของ Centrica) ไม่อนุญาตให้ใช้อีเมลเดียวกับที่อยู่จริงมากกว่าหนึ่งแห่ง
หลังย้ายบ้าน พอพยายาม “ตั้งค่า” บัญชีออนไลน์ ทุกครั้งที่ดูรายละเอียดที่อยู่ปัจจุบันก็เจอ HTTP 500
โทรไปถาม เขาบอกว่า “ใช้อีเมลเดียวกันกับที่อยู่ไปรษณีย์หลายแห่งไม่ได้” แม้บัญชีพลังงานของที่อยู่เดิมจะปิดไปแล้วก็ตาม
+whateverได้ ถ้าเป็น Gmail ก็ใช้ทริกจุด.ได้ด้วยตอนนี้กำลังปรับระบบอีเมลให้อนุญาต อีเมลที่เชื่อมโยงหลายรายการ ต่อบัญชีเดียว
เหตุผลหลักอย่างหนึ่งคือเรามีส่วนลดนักศึกษา วิธีที่ง่ายที่สุดในการใช้ส่วนลดกับบัญชีคือยืนยันว่าอีเมลเป็นที่อยู่ของสถาบันการศึกษา เช่น
.edu,.ac.ukแต่ดูเหมือนคนส่วนใหญ่ไม่อยากสมัครด้วยอีเมลนั้นจริง ๆ การอนุญาตหลายอีเมลทำให้ได้ข้อดีทั้งสองทาง
น่าจะทำแบบนี้มาตั้งแต่แรก
.eduได้หลังเรียนจบมหาวิทยาลัยผมมีที่อยู่หนึ่งที่ค่อนข้างเท่ เพราะสมัครไว้เร็ว เลยมีแค่ชื่อผมอยู่ในที่อยู่นั้น
แต่ไม่ได้ใช้มากนัก ช่วงแรก ๆ การ forward บางครั้งไม่ค่อยเสถียร แต่ตอนนี้น่าจะดีขึ้นแล้ว
ในทางปฏิบัติ ที่อยู่ Gmail ของผมก็เสถียรมาหลายสิบปีแล้ว และไม่น่าจะเปลี่ยน
อย่างไรก็ดี ผมบอกที่อยู่ edu ของผมให้คนจำนวนน้อยมากเท่านั้น
แม้จะไม่หรูหราที่สุด แต่ก็มี วิธีแก้ฝั่งไคลเอนต์ อยู่
ถ้าจ่ายเงินดูแลโดเมนเอง ก็จะควบคุม email alias ได้ 100%
ต่อให้ผู้ให้บริการปัจจุบันอย่าง Google ล่มสลาย ก็โฮสต์เมลเองเพื่อกู้บัญชีและรักษาความเป็นเจ้าของ alias ได้
ผมมองว่านี่เป็นปัญหาฝั่งแบ็กเอนด์ ID ที่ผู้ใช้เห็นอาจเป็นอีเมลได้ แต่ คีย์หลัก ในข้อมูลของระบบไม่ควรเป็นอีเมล
ยังมีที่ไหนทำแบบนี้อยู่หรือ? การไม่ใช้อะไรอย่างอีเมลเป็นตัวระบุ แต่มีตารางค้นหาที่แมปไปยัง ID ที่ไม่ซ้ำกันจริง ๆ (UUID หรือค่าที่เพิ่มอัตโนมัติตามลำดับ) เป็นเรื่องพื้นฐานที่สุดของการออกแบบฐานข้อมูล
บทความไม่ได้แยกแยะเรื่องนี้ให้ชัด จึงอาจอ่านได้เหมือนว่าผู้ใช้ต้องรับรู้ abstraction นี้เอง
ไม่มีอะไรคงอยู่ตลอดไป แม้แต่สิ่งที่เสถียรตลอดช่วงชีวิตมนุษย์ทั้งชีวิตก็แทบไม่มี
แม้แต่เครื่องหมายชีวภาพที่สแกนได้ง่าย ก็ไม่ได้มีเอกลักษณ์อย่างเสถียรในกลุ่มประชากรที่ใหญ่พอ
ที่อยู่อีเมลถูกเลือกใช้เพื่อจุดประสงค์แบบนี้ เพราะมีเอกลักษณ์และเสถียรได้นานพอสมควร
เบอร์โทรศัพท์ก็กลายเป็น ตัวระบุที่เหนียวแน่น กว่าเดิมมาก และตอนนี้คล้ายกับอีเมลในฐานะตัวระบุที่มีประโยชน์
ทั้งอีเมลและเบอร์โทรศัพท์มักสูญหายบ่อย และบ่อยครั้งก็หายไปพร้อมกัน
อีเมลสำรองคือคำตอบ
ผมมองว่า GitHub จัดการเรื่องตัวตนได้ค่อนข้างดี แต่ก็ยังใช้รหัสผ่านอยู่ รหัสผ่านเป็นสิ่งไม่ดี