- Magic Link ที่ส่งลิงก์สำหรับล็อกอินทางอีเมลสามารถลดความเสี่ยงจากการฟิชชิงรหัสผ่านและการรั่วไหลจากการนำรหัสผ่านเดิมกลับมาใช้ซ้ำได้ แต่ถ้าบังคับให้เป็นตัวเลือกเดียว ภาระความติดขัดในการล็อกอินจะถูกผลักไปให้ผู้ใช้
- ผู้ใช้ที่ใช้คอมพิวเตอร์หลายเครื่อง หรือแยกอุปกรณ์งานกับอุปกรณ์ส่วนตัว มักมีอุปกรณ์ที่ได้รับอีเมลกับเบราว์เซอร์ที่ต้องการล็อกอินเป็นคนละเครื่อง ทำให้ขั้นตอนสะดุดได้ง่าย
- เพราะความล่าช้าของ SMTP และกระบวนการส่งต่อของลิงก์ การล็อกอินอาจช้าตั้งแต่ 2 วินาทีไปจนถึงหลายสิบนาที และใน in-app browser กับแอป RSS reader ก็อาจทำให้ประสบการณ์ใช้งานบนมือถือพังได้
- วิธีให้ผู้ใช้พิมพ์ OTP ที่ได้รับทางอีเมลหรือ SMS เองก็ยังยุ่งยาก แต่ในกรณีที่ย้ายลิงก์จากอีเมลไคลเอนต์ไปยังเบราว์เซอร์ที่จะใช้ล็อกอินได้ยาก วิธีนี้อาจดีกว่า Magic Link
- ต่อให้ใช้ Magic Link เป็นค่าเริ่มต้น ก็ควรมีทางเลือกที่แข็งแรงอย่าง passkeys ให้กับกลุ่มผู้ใช้สายเทคนิคและผู้ที่ให้ความสำคัญกับความเป็นส่วนตัวด้วย
สถานการณ์ที่ Magic Link กลายเป็นเรื่องน่ารำคาญ
- “Magic Links” เดิมเคยหมายถึง PDA แนวล้ำยุคในอดีต แต่ปัจจุบันใช้เรียกลิงก์สำหรับล็อกอินที่ฝังอยู่ในอีเมลโดยบริษัทอย่าง Auth0
- 404 Media สนับสนุน Magic Link ในบทความ “We Don’t Want Your Password” โดยมองว่าลิงก์ทางอีเมลฟิชชิงได้ยากกว่ารหัสผ่าน ไม่ทำให้เกิดการรั่วไหลของรหัสผ่าน และยังลดความเสี่ยงจากการนำรหัสผ่านที่รั่วไปใช้ซ้ำ
- แม้จะดูสะดวกในชีวิตที่ใช้แล็ปท็อปเครื่องเดียวกับมือถือเป็นหลัก แต่สำหรับผู้ใช้ที่ใช้อุปกรณ์และเบราว์เซอร์หลายแบบ ความซับซ้อน ก็ยังถูกโยนกลับมาที่ผู้ใช้เหมือนเดิม
- ตัวอย่างความไม่สะดวก:
- หลายอุปกรณ์: ผู้ใช้ที่ไม่ได้เปิดอีเมลส่วนตัวไว้บนพีซีสำหรับเล่นเกมหรือแล็ปท็อปทำงาน จะเปิดลิงก์ล็อกอินได้ยากทันที
- ความเร็ว: ความหน่วงของ SMTP และขั้นตอนการย้ายลิงก์ไปยังเบราว์เซอร์ที่ถูกต้อง อาจทำให้ช้าตั้งแต่ 2 วินาทีไปจนถึงหลายนาที
- มือถือ: การใช้ in-app browser อาจทำให้ระบบรวน และทำให้การจัดการลิงก์ภายในแอป RSS reader ที่เป็นลิงก์โลคัลใช้งานลำบาก
- ความปลอดภัย: ขั้นตอนที่ชวนให้เปิดอีเมลส่วนตัวบนอุปกรณ์งาน หรือกลับกัน ไม่ได้เป็นข้อดีด้านความปลอดภัย
ทางเลือกและการเสริมให้พอใช้งานได้
- วิธี passwordless ที่ให้พิมพ์ OTP จากอีเมลหรือ SMS เองก็ยังไม่สะดวก แต่ในสถานการณ์ที่ย้ายลิงก์จากอีเมลไคลเอนต์ไปยังเบราว์เซอร์ที่จะใช้ล็อกอินได้ไม่ง่าย มันอาจใช้งานได้จริงมากกว่า
- Stratechery ผ่าน Passport มีทั้งการคลิกลิงก์และการกรอก OTP ให้เลือก แม้ยังมีข้อจำกัดที่ผลักความไม่สะดวกไปให้ผู้ใช้หากไม่มีการทำ passkeys แต่ก็ยังคำนึงถึงสถานการณ์ของผู้ใช้มากกว่าการมีแค่ Magic Link
- ต่อให้ยืนยันจะใช้ Magic/Tragic Link เป็นค่าเริ่มต้น ก็ควรมีทางเลือกที่แข็งแรงอย่าง passkeys ควบคู่กันไป
- บทความอ้างอิงของ Ricky Mondello Magic Links Have Rough Edges, but Passkeys Can Smooth Them Over กล่าวถึงวิธีใช้ passkeys เพื่อบรรเทาปัญหานี้
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ปัญหาที่เจอระหว่างสร้างแอปด้วย magic link: ผู้ใช้อาจต้องล็อกอินบนอุปกรณ์ที่เข้าถึงอีเมลได้ไม่สะดวก จึงควรใส่ รหัสล็อกอินทางเลือก ไว้ใน magic link ด้วย
นอกจากนี้ยังต้องรองรับกรณีที่ไคลเอนต์อีเมลเปิดลิงก์อัตโนมัติเพื่อสร้างภาพตัวอย่างพรีวิว และต้องคำนึงถึงไคลเอนต์อีเมลที่เปิดด้วย in-app browser แทนเบราว์เซอร์ที่ผู้ใช้ต้องการ
ตัวอย่างเช่น ผู้ใช้ iOS อาจชอบ Firefox บนมือถือ แต่แอปอีเมลอาจบังคับเปิดด้วย in-app browser ที่อิง Safari
มองว่าถ้าใช้วิธีพาไปยัง หน้าใส่รหัสแบบใช้ครั้งเดียว ก็จะหลีกเลี่ยงปัญหาเหล่านี้ได้มาก
ไม่นานมานี้เจอปัญหาที่บัญชีอีเมลใหม่ถูกยืนยันอัตโนมัติ และพอผู้ใช้คลิกจริง magic link ก็หมดอายุไปแล้ว เพราะ Microsoft ล็อกอินด้วยลิงก์นั้นไปก่อนระหว่างการตรวจสอบ
หลัง McDonald's เปลี่ยนจากอีเมล/รหัสผ่านมาเป็น magic link การทำให้ลิงก์ใช้งานในแอป McD กลายเป็นเรื่องยากมาก และมักเปิดแค่เว็บไซต์ McD
เวลากิน McD ประมาณ 98% ถ้าสั่งผ่านแอปไม่ได้ก็จะไม่กินเลย เลยหงุดหงิดมาก และสุดท้ายก็เปลี่ยนไปใช้ “Sign in With Apple”(SIWA)
หาวิธีเพิ่ม SIWA ให้กับบัญชี McD เดิมไม่เจอ จึงต้องใช้ SIWA แบบซ่อนอีเมลจริงจาก McD ทำให้เกิดบัญชีใหม่และเสียแต้มสะสมของบัญชีเดิมไป แต่ก็อย่างน้อยกลับมาใช้แอป McD ได้อีกครั้ง
ในแอปมีดีล “Free Medium Fries on Friday” เมื่อสั่งเกิน 1 ดอลลาร์ทุกวันศุกร์ ดังนั้นมื้อเที่ยงวันศุกร์ก็มักทำแซนด์วิชที่บ้าน แล้วไปรับคุกกี้กับมันฝรั่งทอดฟรีจาก McD มากินคู่กัน
เลยรับ magic link บนคอมพิวเตอร์ที่ทำงานแล้วสร้าง QR code แต่ระบบแยกกักอีเมลไปเปลี่ยนลิงก์ทั้งหมด จึงต้องดึงลิงก์ต้นฉบับออกมา
ยังไม่จบแค่นั้น เพราะ URL redirect กลับไปที่ Slack พังจากการ URL encode เลยต้องแก้เองก่อนสร้าง QR code
ความจริงแค่ใส่ QR code หรือโค้ด มาในอีเมล magic link เดิมเลยก็จบแล้ว
พอใส่โค้ดเข้าไป ข้อดีนี้ก็หายไปหมด เพราะผู้โจมตีแค่สร้างเว็บไซต์ปลอมที่ขอรหัสก็พอ
magic link ควรล็อกอินบนอุปกรณ์ที่กดคลิก ไม่ใช่ไปล็อกอินบนอุปกรณ์ที่ร้องขอเซสชันล็อกอิน
วิธีอื่นนอกจากนั้นอาจยุ่งยากน้อยกว่านิดหน่อยก็จริง แต่ถือเป็นปัญหาด้านความปลอดภัย และควรถูกมองแบบนั้น
ใช้ magic link มาหลายปีแล้ว และในช่วง MVP ก็มีเหตุผลเพราะอยากหลีกเลี่ยงภาระด้านความปลอดภัยของการเก็บรหัสผ่านผู้ใช้ ปัญหาใหญ่สุดคือมีผู้ใช้บางส่วนราว 0.1% ที่ ไม่ได้รับอีเมลเลย
ลองทั้ง IP ของตัวเอง, MailGun, PostMark และวิธีสลับ retry ผ่านเครื่องมือส่งอีเมลธุรกรรมหลายตัวตามลำดับแล้ว แต่ก็ยังมีคนที่ไม่มีทางล็อกอินได้เลย
อีกทั้งคนมักคลิก magic link เมื่อ 6 เดือนก่อนแล้วบ่นว่า “ใช้ไม่ได้” จึงตัดสินใจแสดงหน้าแบบ Docusign ที่อธิบายสถานการณ์และส่งลิงก์ใหม่ให้ แทนที่จะขึ้นข้อความผิดพลาดเฉย ๆ
คนยังชอบกรอกอีเมลผิดเอง แล้วพอไม่ได้รับโค้ดก็โทษระบบ
ถึงอย่างนั้นก็ยังรู้สึกว่ามี support ticket น้อยกว่าวิธีอีเมล+รหัสผ่านมาก จึงยังชอบ magic link มากกว่า
ไม่เคยใช้ magic link แต่เมื่อไม่กี่เดือนก่อนเพิ่ม Google Sign in ใน SaaS แล้วพบว่ามันกลายเป็นมากกว่า 90% ของการสมัครใหม่
ทั้งที่กลุ่มผู้ใช้เป็นนักพัฒนา ซึ่งโดยทั่วไปมีความเข้าใจเทคนิคสูงและค่อนข้างอ่อนไหวเรื่องความเป็นส่วนตัว แต่ก็ยังเป็นแบบนั้น และตอนนี้ไม่คิดว่าวิธีอื่นจะเป็นเรื่องเร่งด่วนกว่า แน่นอนว่ายังเก็บอีเมล/รหัสผ่านไว้
ชื่อผู้ใช้+รหัสผ่านที่ใช้ร่วมกับตัวจัดการรหัสผ่าน หรือ passkey อาจเป็นแทบจะวิธีเดียวที่ให้ประสบการณ์ใช้งานที่ดีสำหรับคนทั่วไปบน HTTPS พร้อมแลกเปลี่ยนข้อมูลรับรองแบบเข้ารหัสตั้งแต่ต้นทางถึงปลายทาง
ตัวจัดการรหัสผ่านยังช่วยรับประกันด้วยว่าข้อมูลรับรองจะถูกใช้กับโดเมนที่ถูกต้องเท่านั้น
เคยเป็นลูกค้าประจำของ Mercury แต่ถึงจะผ่านทั้งรหัสผ่านที่ปลอดภัย ตัวจัดการรหัสผ่าน และ TOTP ที่ยังใช้ได้ ก็ยังถูกบังคับให้ใช้เมจิกลิงก์เป็น ปัจจัยยืนยันตัวตนลำดับที่สาม ทุกครั้งที่ IP address เปลี่ยน จนทำให้อยากย้ายธนาคารของบริษัทไปที่อื่น
ถ้าเป็นการล็อกอินจากสถานที่หรือ ISP ที่ไม่เคยใช้ในช่วง 5 ปีที่ผ่านมา ก็คงพอเข้าใจได้ แต่ถ้าต่างจากตอนล็อกอินเมื่อวานแค่ octet สุดท้ายของ DHCP address แบบนี้ก็ไม่สมเหตุสมผล
อีเมลถูกอ่านผ่านการท่องเว็บและผ่าน SSH บนคอมพิวเตอร์อีกเครื่อง ดังนั้นการคัดลอกแล้ววางลิงก์ล็อกอินที่ยาวหลายร้อยตัวอักษรจึงทรมานมาก
ใน Emacs มันยังแสดงคร่อมหลายบรรทัด จนต้องลบ
\ตรงรอยต่อบรรทัดเองด้วยการเพิ่มแรงเสียดทานทุกครั้งที่ล็อกอินทำให้ความรู้สึกต่อทุกปฏิสัมพันธ์ที่ตามมาในแอปแย่ลง และทำให้ไม่อยากใช้งาน
ถ้าเป็นอุปกรณ์ที่เคยใช้มาก่อน ก็ไม่ควรถูกขอให้ยืนยันอุปกรณ์ และเราเก็บ persistent cookie ไว้เพื่อตรวจสอบเรื่องนี้ อีกทั้งไม่ได้บังคับแม้อยู่ IP เดียวกัน จึงสงสัยว่าคุกกี้อาจถูกลบเป็นระยะหรือไม่
ฟีเจอร์นี้เพิ่มเข้ามาหลังจากมีผู้โจมตีสร้างเว็บปลอมของ http://mercury.com และถึงขั้นลงโฆษณา Google ด้วย
เมื่อลูกค้าใส่รหัสผ่านและ TOTP ลงในเว็บฟิชชิง ฟิชเชอร์ก็จะใช้ข้อมูลรับรองนั้นล็อกอิน สร้าง virtual card แล้วนำไปซื้อคริปโต ทองคำ ฯลฯ โดยหวังว่าผู้ใช้จะถูกรีไดเร็กต์ไปยัง Mercury ของจริงและคิดว่าเป็นแค่ข้อผิดพลาดชั่วคราว
ลิงก์ยืนยันอุปกรณ์ ที่เราส่งจะอนุมัติ IP/อุปกรณ์ที่เปิดลิงก์ และด้วยวิธีนี้เราสามารถหยุดฟิชเชอร์ได้แทบทั้งหมด
WebAuthn มีภูมิคุ้มกันต่อการโจมตีฟิชชิงแบบนี้ ดังนั้นถ้าใช้ WebAuthn จะไม่ถูกขอให้ยืนยันอุปกรณ์
ถ้าเป็นไปได้ ขอแนะนำอย่างยิ่งให้ใช้ TouchID/FaceID หรือ WebAuthn แบบผูกกับแต่ละอุปกรณ์ สะดวกกว่าและปลอดภัยกว่า และเพิ่มได้ที่นี่: https://app.mercury.com/settings/security
อย่างไรก็ตาม ภายในเรากำลังคุยเรื่องโพสต์นี้กันอยู่ และก็ตระหนักดีว่าเมื่อ IPv6 แพร่หลายมากขึ้น IP จะเปลี่ยนบ่อยกว่านี้มาก เราจะลองพิจารณาดูว่าควรผ่อนข้อจำกัดการจับคู่ IP เดียวกันหรือไม่
มองว่าเป็นการตอบรับที่ดีมากต่อโพสต์ 404 เมื่อสัปดาห์ก่อน ผมชอบ 404 แต่ก็รำคาญ เมจิกลิงก์ ด้วยเหตุผลเดียวกับที่ผู้เขียนบอก
บทความที่ Ricky Mondello เขียนเมื่อสัปดาห์ก่อน[1] อธิบายได้ดีว่าพาสคีย์สามารถใช้ร่วมกับเมจิกลิงก์ได้ ไม่ใช่อย่างที่เกริ่นไว้ท้ายบทความว่าเป็นทางเลือกแทนกัน จึงน่าอ่านมาก
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
พอจะล็อกอินเข้า store ก็ให้กรอกรหัส 2FA ที่ส่งไปทางอีเมล แต่เมลไม่มาหลายนาที พอกดขอรหัสใหม่ก็ยังไม่มา แล้วพอเลิกสนใจไปทำอย่างอื่น 30 นาทีต่อมารหัสทั้งสองอันก็มาพร้อมกัน
ความจริงแล้วอีเมลเป็นสิ่งที่เชื่อถือได้ยากแม้ในวันที่ทุกอย่างดีที่สุด มันอาจเข้าโฟลเดอร์สแปม ตัวกรองสแปมของบริษัทอาจบล็อกลิงก์ หรือกล่องจดหมายอาจเต็มก็ได้
ส่วนตัวผมมีอีเมลอยู่แค่บน iPhone ดังนั้นบนโน้ตบุ๊กที่ทำงานหรือพีซีเล่นเกมก็ต้องล็อกอินเข้า icloud.com เพื่อเช็ก ทำให้ยุ่งยาก
อยากให้มีตัวเลือกอย่างน้อยสักอย่าง ไม่ว่าจะให้พิมพ์รหัสผ่าน สแกน QR code แบบอุปกรณ์ embedded หรืออะไรก็ตาม
เมจิกลิงก์ช่วยให้เข้าถึงพาสคีย์ได้ และพาสคีย์ก็เป็นเวอร์ชันอัปเกรดของ “จดจำคอมพิวเตอร์เครื่องนี้” โดยพื้นฐาน
ผมยังคุ้นเคยกับยุคที่คนฝั่ง Apple แทบไม่ค่อยออกมาพูดในที่สาธารณะเลย
ไม่แน่ใจว่าผมเข้าใจอะไรผิดไปหรือเปล่า แต่ดูเหมือนว่า passkey จะไม่ใช่ ทางเลือกแทน magic link โดยตรง
implementation ของ passkey ทุกแบบที่ผมเคยเห็นจนถึงตอนนี้ ล้วนแนะนำให้ล็อกอินด้วยวิธีอื่นก่อนแล้วค่อยสร้าง passkey
ยังไม่ได้ขุดลึกมากนัก แต่ในมุมประสบการณ์ผู้ใช้ passkey ดูจะเป็นทางเลือกแทนปุ่ม “จดจำคอมพิวเตอร์เครื่องนี้” มากกว่าจะเป็นทางเลือกแทนรหัสผ่านทั้งหมด
ไม่ว่าด้วยวิธีไหน บริการก็ต้องรู้ก่อนว่าอุปกรณ์ใหม่นี้ได้รับการอนุมัติแล้ว
แม้จะมีการซิงก์ passkey อยู่บ้างขึ้นกับผู้ให้บริการ แต่ก็ไม่ได้แก้ปัญหาว่าจะยืนยันตัวตนครั้งแรกอย่างไร
แก่นสำคัญของ magic link คือ ระบบความปลอดภัยจะไม่มีวันแข็งแกร่งไปกว่ากลไกการกู้คืนได้
โลกที่ถือว่า passkey เป็นวิธียืนยันตัวตนเพียงหนึ่งเดียวคงไม่เกิดขึ้นจริง เพราะจะต้องมีกลไกกู้คืนเหลืออยู่เสมอ และส่วนใหญ่ก็น่าจะเป็นการกู้คืนอัตโนมัติผ่านอีเมล
ถ้าอย่างนั้น magic link ก็ดูซื่อตรงดี เพราะมันทำให้เรื่องง่ายขึ้นโดยไม่แสร้งทำเป็นว่ามีชั้นความปลอดภัยที่เข้มกว่าอยู่ด้านบน
ถ้าทำให้กลไกกู้คืนกลายเป็นช่องทางโต้ตอบหลักของ flow การยืนยันตัวตน ก็เท่ากับซื่อตรงมากขึ้นกับระดับความปลอดภัยที่แท้จริงของระบบยืนยันตัวตน
แก้ไข: filmgirlcw ทิ้งลิงก์ไปยังโพสต์ที่อธิบายได้ดีกว่าว่าสองแนวทางนี้เสริมกันอย่างไร: https://news.ycombinator.com/item?id=42628226
magic link ก็มีข้อดีของมัน แต่ผมไม่แน่ใจว่าการทำให้อีเมลกลายเป็นช่องทางโจมตีที่ทรงพลังขึ้นจะนับเป็นข้อดีหรือไม่
สำหรับคนที่ใช้ password manager, magic link เป็นจุดเสียดทานที่ชัดเจน และ passkey น่าจะช่วยลดตรงนี้ได้มาก
ปัญหาด้านประสบการณ์ผู้ใช้ของ passkey เองก็ยังมีช่องให้ปรับปรุง และถ้าส่งออกได้เมื่อไร การซิงก์ข้ามระบบก็น่าจะดีขึ้นมาก
เหตุผลข้อหนึ่งที่ผมใช้ 1Password เป็นระบบรหัสผ่านและ passkey หลัก ก็เพราะการใช้ passkey ข้ามอุปกรณ์ และที่บริษัทก็ใช้ 1Password เหมือนกัน เลยล็อกอินทั้งบัญชีส่วนตัวและบัญชีองค์กรไว้ แล้วค่อยยืนยันตัวตนจากอุปกรณ์ส่วนตัวหรืออุปกรณ์งานตามต้องการ
แต่ถ้าปัญหาที่ 404 นิยามไว้คือไม่อยากรับผิดชอบการเก็บรหัสผ่านหรือการควบคุมการยืนยันตัวตน สำหรับผู้ใช้บางส่วน passkey ก็น่าจะดีกว่า magic link
ถึงอย่างนั้นผมก็คิดเหมือน Ricky ว่าไม่ควรเลือกอย่างใดอย่างหนึ่ง แต่ควรเป็น ทั้งสองอย่าง
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
ไม่ได้แปลว่าถ้าใช้ passkey แล้วจำเป็นต้องมีวิธีล็อกอินสำรองเสมอไป แต่ตอนนี้ก็ยังไม่มีบริการไหนเปลี่ยนไปใช้ passkey อย่างเดียวเต็มตัว
ผู้ใช้ OS เก่าหรือ Linux บางคนอาจยังสร้างและเก็บ passkey ไม่ได้ และผู้ใช้จำนวนมากก็ไม่ได้ใช้ credential manager แบบข้ามแพลตฟอร์ม
ตัวอย่างเช่น ถ้าคุณสร้าง passkey ด้วย iCloud Passwords ตอนนี้ก็ยังไม่มีวิธีล็อกอินบน Linux
อีกไม่กี่ปี เราน่าจะเริ่มเห็นบริการที่ให้สร้าง passkey ตั้งแต่แรกและไม่เก็บรหัสผ่านเลย
หวังว่าเมื่อมีการ implement สเปกเรื่องการพกพา passkey แล้ว Gnome/KDE ก็จะ implement การรองรับ passkey ด้วย
ถ้าการใช้ OTP บนมือถือหรือต้องคัดลอกลิงก์จากมือถือเวลาจะเข้าเว็บบน PC ที่ทำงานเป็นเรื่องทรมาน ผมก็สงสัยว่าการทำให้คอมพิวเตอร์ที่ทำงานเชื่อมกับ passkey ส่วนตัวที่อยู่บนโน้ตบุ๊กหรืออุปกรณ์อื่นจะง่ายและดีกว่าขนาดไหน
ผมไม่ใช้บริการที่รองรับแค่ magic link สำหรับการยืนยันตัวตน มันไม่เป็นมิตรกับผู้ใช้มาก ๆ และในมุมความปลอดภัยก็ แย่กว่ารหัสผ่านที่ใช้คู่กับ password manager อย่างชัดเจน
เรื่องที่ร้ายแรงที่สุดคือมันใช้ไม่ได้เลยกับการตั้งค่าส่วนตัวของผม
เพราะเพื่อความปลอดภัยของบัญชีและความมั่นคงปลอดภัย ผมจะไม่เปิดให้อุปกรณ์ที่ใช้ล็อกอินเข้าถึงบัญชีอีเมล
ยกเว้นแค่ Anthropic เพราะ Claude เป็น LLM ที่ดีที่สุด แต่ทุกครั้งที่ต้องล็อกอินใหม่มันทรมานมาก และผมก็ส่งคำบ่นไปหลายครั้งแล้ว
ทุกครั้งที่เห็น magic link ผมจะคิดเสมอว่า “ตกลงเราไม่ควรกดลิงก์ในอีเมลตั้งแต่แรกไม่ใช่เหรอ?”
พอนึกถึงลิงก์ในอีเมลก็จะนึกถึง phishing ไปด้วย
ผมเกลียด magic link มาก
ประเด็นคืออย่าคลิกลิงก์ที่น่าสงสัย ถ้าคุณรู้อยู่แล้วว่ามีการส่ง magic link มา มันก็ไม่ใช่ลิงก์น่าสงสัย
ถึงอย่างนั้นผมก็ยังไม่ชอบ magic link เพราะความหน่วง
แนวทางคุ้มครองความเป็นส่วนตัวอีเมลของ Apple ดูน่าสนใจดี ที่ Apple เป็นฝ่ายโหลดรูปทั้งหมดให้เสมอ แต่ผมก็ไม่รู้ว่ามันมีข้อเสียอะไรหรือเปล่า
การใช้งานที่ดีที่สุดที่ฉันเคยเห็นคือ ต้องคลิกลิงก์บนอุปกรณ์ที่ได้รับอีเมล แต่จะไม่ย้ายเซสชันไปยังอุปกรณ์นั้น และให้ล็อกอินเสร็จสิ้นบน อุปกรณ์ที่เริ่มขั้นตอนล็อกอินครั้งแรก
ทางออกที่ดีกว่าคือ ให้ล็อกอินได้เฉพาะบนอุปกรณ์ที่เปิดลิงก์ และหากต้องการใช้งานข้ามอุปกรณ์ก็ควรมี รหัส OTP ให้ด้วย โดยอ่านจากอุปกรณ์ที่รับอีเมลแล้วนำไปกรอกบนอุปกรณ์เดิมได้ง่าย
หรือจะให้เฉพาะรหัส OTP โดยไม่มีลิงก์เลยก็ได้
ไม่มีอะไรแย่ไปกว่าการทำงานอยู่ในเบราว์เซอร์หนึ่ง แต่พอเปิดอีเมลกลับถูกยืนยันตัวตนในเบราว์เซอร์เริ่มต้น หรือแย่กว่านั้นคือไปยืนยันตัวตนบนอีกอุปกรณ์หนึ่ง แล้วต้องส่งต่อลิงก์ไปฝั่งนั้นก่อนค่อยกลับมาเปิดใหม่
บางครั้งก็ไม่ได้อยากให้บางอุปกรณ์เข้าถึงอีเมลบางบัญชีอยู่แล้ว ดังนั้นนี่ไม่ใช่สถานการณ์ประหลาดอะไร
ถ้าเว็บไซต์ส่ง OTP แบบ
crazy-pink-horse-3837มาให้คัดลอกไปวาง ก็ถือเป็นจุดกึ่งกลางที่ใช้ได้ หากการทำลิงก์สำหรับยืนยันคำขอเดิมนั้นยากเกินไปแต่ปัญหาของการทำระบบคือ เมจิก์ลิงก์ที่ส่งมาถูกครอบด้วย ตัวติดตามการคลิก และโดเมนนั้นโดนเครื่องมืออย่าง pihole บล็อก
เลยไปไม่ถึง URL สำหรับยืนยันตัวตนจริง ๆ และล็อกอินให้เสร็จไม่ได้
อินแอปเบราว์เซอร์ควรหายไปได้แล้ว โดยเฉพาะอินแอปเบราว์เซอร์ที่ไม่มีตัวเลือก “เปิดในเบราว์เซอร์ปกติ” และถ้าเป็น RSS reader ก็ควรมีตัวเลือกนี้อยู่แล้ว
ผู้จัดการผลิตภัณฑ์ที่บังคับให้ผู้ใช้ต้องใช้อินแอปเบราว์เซอร์ควรถูกจับเข้าคุกให้หมด
ทางเลือกที่ดีกว่ามากคือใช้ รหัส OTP ที่ส่งทางอีเมลร่วมกับ passkey ที่มี Conditional Mediation UI
ถ้าผู้ใช้กำลังล็อกอินบนอุปกรณ์ที่มี passkey อยู่แล้ว CM UI ก็จะให้เลือกได้ทันทีและล็อกอินได้เลย
ถ้าเป็นอุปกรณ์ที่ยังไม่มี passkey ก็สามารถออกแบบประสบการณ์ผู้ใช้ให้กรอกรหัสจากอีเมล และเมื่อสำเร็จแล้วก็ตั้งค่า passkey ได้ทันที เพื่อให้ครั้งถัดไปล็อกอินได้เลย
แบบนี้จะได้ทั้งความปลอดภัยของ passkey บนอุปกรณ์เดิม และได้การตั้งค่าแบบไม่มีรหัสผ่านรวมถึงการกู้คืนบัญชีบนอุปกรณ์ใหม่
แถมยังหลีกเลี่ยง vendor lock-in ที่ผู้ให้บริการคลาวด์ถือ passkey ทั้งหมดไว้อีกด้วย