- Magic link, tức liên kết đăng nhập gửi qua email, có thể giảm rủi ro phishing mật khẩu và rò rỉ mật khẩu dùng lại, nhưng nếu trở thành lựa chọn duy nhất thì ma sát đăng nhập sẽ bị đẩy sang phía người dùng
- Với người dùng dùng nhiều máy tính hoặc tách riêng thiết bị công việc và cá nhân, thiết bị nhận email và trình duyệt muốn đăng nhập khác nhau nên luồng thao tác rất dễ bị gián đoạn
- Do độ trễ SMTP và quá trình chuyển tiếp liên kết, việc đăng nhập có thể chậm từ 2 giây đến vài phút; trên trình duyệt trong ứng dụng và ứng dụng đọc RSS, trải nghiệm di động cũng có thể bị hỏng
- Cách nhập trực tiếp OTP nhận qua email hoặc SMS cũng phiền phức, nhưng khi khó chuyển liên kết giữa email client và trình duyệt thì có thể tốt hơn magic link
- Dù dùng magic link làm mặc định, vẫn nên cung cấp kèm các lựa chọn thay thế vững chắc như passkeys cho nhóm người dùng thiên về kỹ thuật và coi trọng quyền riêng tư
Khi magic link trở nên bất tiện
- “Magic Links” trước đây từng chỉ các PDA mang tính tương lai, nhưng hiện nay là thuật ngữ được các công ty như Auth0 dùng để chỉ liên kết đăng nhập nằm trong email
- 404 Media ủng hộ magic link trong “We Don’t Want Your Password”, cho rằng liên kết email khó bị phishing hơn mật khẩu, không dẫn đến rò rỉ mật khẩu và cũng giảm rủi ro tái sử dụng mật khẩu đã bị lộ
- Trong lối sống chủ yếu dùng một laptop và thiết bị di động, cách này có vẻ dễ dàng, nhưng với người dùng nhiều thiết bị và trình duyệt, độ phức tạp được chuyển nguyên sang họ
- Các tình huống bất tiện:
- Nhiều thiết bị: người dùng không đặt email cá nhân trên PC chơi game hoặc laptop công việc sẽ khó mở ngay liên kết đăng nhập
- Tốc độ: do độ trễ SMTP và việc chuyển liên kết sang đúng trình duyệt, quá trình có thể chậm từ 2 giây đến vài phút
- Di động: việc dùng trình duyệt trong ứng dụng bị hỏng, khiến xử lý liên kết cục bộ trong ứng dụng đọc RSS trở nên bất tiện
- Bảo mật: luồng thao tác khuyến khích mở email cá nhân trên thiết bị công việc, hoặc ngược lại, không phải là một lợi thế về bảo mật
Các phương án thay thế và bổ sung tối thiểu
- Phương thức passwordless nhập trực tiếp OTP nhận qua email hoặc SMS cũng bất tiện, nhưng trong tình huống không thể dễ dàng chuyển liên kết từ email client sang trình duyệt cần đăng nhập, nó có thể thực tế hơn
- Stratechery cung cấp lựa chọn nhấp liên kết hoặc nhập OTP thông qua Passport; dù vẫn có hạn chế là chuyển sự bất tiện sang người dùng vì không triển khai passkeys, cách này vẫn cân nhắc hoàn cảnh người dùng hơn so với chỉ dùng magic link
- Ngay cả khi vẫn cố giữ magic/tragic link làm mặc định, tốt hơn nên cung cấp kèm một phương án thay thế vững chắc như passkeys
- Bài viết tham khảo Magic Links Have Rough Edges, but Passkeys Can Smooth Them Over của Ricky Mondello bàn về cách dùng passkeys để giảm nhẹ vấn đề này
1 bình luận
Các ý kiến trên Hacker News
Những vấn đề gặp phải khi xây dựng ứng dụng bằng magic link: vì người dùng có thể cần đăng nhập trên thiết bị mà việc truy cập email không thuận tiện, nên cần đưa mã đăng nhập thay thế vào magic link
Ngoài ra, cần xử lý trường hợp client email tự động mở liên kết để tạo ảnh chụp màn hình xem trước, và cũng phải tính đến các client email mở liên kết bằng trình duyệt trong ứng dụng thay vì trình duyệt người dùng ưa thích
Ví dụ, dù người dùng iOS thích Firefox Mobile, ứng dụng email vẫn có thể buộc mở bằng trình duyệt trong ứng dụng dựa trên Safari
Tôi nghĩ cách dẫn tới trang nhập mã dùng một lần có thể tránh được nhiều vấn đề như vậy
Gần đây tôi gặp vấn đề một tài khoản email mới được xác minh tự động, và khi người dùng nhấp vào thì magic link đã vô hiệu, vì Microsoft đã đăng nhập trước bằng liên kết đó trong quá trình kiểm tra
Sau khi McDonald's chuyển từ email/mật khẩu sang magic link, việc làm cho liên kết hoạt động trong ứng dụng McD thực sự rất khó, và thường chỉ mở website McD
Khoảng 98% những lần ăn McD, nếu không đặt được bằng ứng dụng thì tôi sẽ không ăn, nên khá bực mình, và cuối cùng tôi chuyển sang “Sign in With Apple”(SIWA)
Tôi không tìm được cách thêm SIWA vào tài khoản McD hiện có, nên phải dùng SIWA để ẩn email thật của mình khỏi McD; một tài khoản mới được tạo và tôi mất điểm thưởng của tài khoản cũ, nhưng ít nhất đã có thể dùng lại ứng dụng McD
Trong ứng dụng có ưu đãi “Free Medium Fries on Friday” khi đặt hàng từ 1 đô la trở lên vào mỗi thứ Sáu, nên vào bữa trưa thứ Sáu tôi thường làm sandwich ở nhà rồi lấy bánh quy và khoai tây chiên miễn phí ở McD để ăn kèm
Vì thế tôi nhận magic link trên máy tính công ty rồi tạo mã QR, nhưng hệ thống cách ly email đã thay đổi toàn bộ liên kết, nên tôi phải trích xuất liên kết gốc
Chưa hết, URL chuyển hướng quay lại Slack bị hỏng do mã hóa URL, nên tôi phải tự sửa rồi mới tạo mã QR
Đáng ra chỉ cần đưa kèm mã QR hoặc mã ngay trong email magic link ban đầu là được
Ngay khi thêm bước nhập mã, ưu điểm đó biến mất hoàn toàn, và kẻ tấn công chỉ cần tạo một website giả yêu cầu mã là đủ
Magic link phải đăng nhập trên chính thiết bị được nhấp, chứ không được đăng nhập trên thiết bị đã yêu cầu phiên đăng nhập
Các cách khác có thể đỡ phiền hơn đôi chút, nhưng đó là vấn đề bảo mật và cần được nhìn nhận như vậy
Tôi đã dùng magic link trong nhiều năm, một phần cũng vì ở giai đoạn MVP muốn tránh gánh nặng bảo mật của việc lưu mật khẩu người dùng. Vấn đề lớn nhất là một số người dùng, khoảng 0,1%, hoàn toàn không nhận được email
Tôi đã thử IP riêng, MailGun, PostMark, thậm chí cả cách thử lại tuần tự qua nhiều công cụ email giao dịch, nhưng vẫn có những người tuyệt đối không thể đăng nhập
Ngoài ra, vì có người nhấp vào magic link từ 6 tháng trước rồi bực bội nói “không được”, nên thay vì thông báo lỗi, chúng tôi quyết định hiển thị một trang giải thích tình huống và gửi lại liên kết, giống Docusign
Người ta cũng hay nhập sai địa chỉ email rồi khi không nhận được mã thì đổ lỗi cho hệ thống
Dù vậy, tôi cảm thấy số ticket hỗ trợ ít hơn nhiều so với cách email+mật khẩu, nên vẫn thích magic link hơn
Tôi chưa từng dùng magic link, nhưng vài tháng trước khi thêm Google Sign in vào SaaS, nó đã chiếm hơn 90% lượt đăng ký mới
Dù nhóm người dùng là developer, có mức hiểu biết kỹ thuật và độ nhạy cảm về quyền riêng tư khá cao, tình hình vẫn như vậy; tôi không nghĩ các cách khác hiện còn là ưu tiên. Tất nhiên email/mật khẩu vẫn được duy trì
Tên người dùng+mật khẩu dùng cùng trình quản lý mật khẩu, hoặc passkey, có lẽ là những cách gần như duy nhất để trao đổi thông tin xác thực theo kiểu mã hóa đầu-cuối qua HTTPS mà vẫn mang lại trải nghiệm người dùng tốt cho đại chúng
Trình quản lý mật khẩu đảm bảo thông tin xác thực chỉ được dùng trên đúng domain
Tôi từng là khách hàng trung thành của Mercury, nhưng ngay cả sau khi vượt qua mật khẩu an toàn, trình quản lý mật khẩu và TOTP hợp lệ, mỗi khi địa chỉ IP thay đổi họ vẫn bắt buộc dùng magic link làm yếu tố xác thực thứ ba, đến mức khiến tôi nghĩ đến chuyện chuyển tài khoản ngân hàng của công ty sang nơi khác
Nếu tôi đăng nhập từ một vị trí hay ISP không phải nơi đã dùng suốt 5 năm qua thì còn hiểu được, nhưng nếu thứ duy nhất khác so với lần đăng nhập hôm qua chỉ là octet cuối của địa chỉ DHCP thì thật vô lý
Tôi đọc email qua SSH từ một máy tính khác với máy dùng để duyệt web, nên việc sao chép rồi dán một liên kết đăng nhập dài hàng trăm ký tự thực sự là cực hình
Trong Emacs, nó còn hiển thị trên nhiều dòng, nên tôi phải tự xóa cả dấu
\ở ranh giới dòngMỗi lần đăng nhập lại thêm ma sát thì ấn tượng về mọi tương tác tiếp theo trong ứng dụng đều xấu đi, và khiến tôi không muốn dùng nữa
Nếu đó là thiết bị đã từng dùng trước đây thì không nên hiện yêu cầu xác minh thiết bị. Chúng tôi lưu cookie vĩnh viễn để xác nhận điều này, và cũng không yêu cầu nếu cùng IP. Tôi tự hỏi liệu cookie của bạn có đang bị xóa định kỳ không
Tính năng này được thêm vào sau khi kẻ tấn công tạo các trang sao chép http://mercury.com và thậm chí chạy quảng cáo Google
Khi khách hàng nhập mật khẩu và TOTP vào trang phishing, kẻ lừa đảo dùng thông tin đăng nhập đó để đăng nhập, tạo thẻ ảo rồi mua tiền mã hóa, vàng, v.v.; sau đó chúng chuyển hướng người dùng về Mercury thật, hy vọng người dùng nghĩ đó chỉ là lỗi tạm thời
Liên kết xác minh thiết bị mà chúng tôi gửi sẽ phê duyệt IP/thiết bị đã mở liên kết, và cách này gần như chặn hoàn toàn kiểu phishing đó
WebAuthn miễn nhiễm với các cuộc tấn công phishing như vậy, nên nếu dùng WebAuthn thì chúng tôi không yêu cầu xác minh thiết bị
Nếu có thể, tôi rất khuyến nghị dùng TouchID/FaceID hoặc WebAuthn theo từng thiết bị. Nó tiện hơn và an toàn hơn, và có thể thêm tại đây: https://app.mercury.com/settings/security
Tuy vậy, nội bộ chúng tôi đang thảo luận về bài này, và cũng nhận thức rằng khi IPv6 phổ biến hơn, IP sẽ thay đổi thường xuyên hơn nhiều. Chúng tôi sẽ cân nhắc có nên nới lỏng giới hạn khớp cùng IP hay không
Tôi thấy đây là phản hồi rất tốt cho bài 404 tuần trước. Tôi thích 404, nhưng vì đúng những lý do tác giả nêu, magic link gây khó chịu
Bài viết tuần trước của Ricky Mondello[1] giải thích rất rõ rằng passkey có thể được dùng cùng với magic link, như được ngụ ý ở cuối bài, nên đáng đọc
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
Khi cố đăng nhập vào store, họ yêu cầu nhập mã 2 bước gửi qua email; đợi vài phút không thấy mail, yêu cầu mã mới cũng không thấy, rồi khi bỏ cuộc đi làm việc khác thì 30 phút sau cả hai mã đều đến
Thực ra email vốn khó tin cậy ngay cả trong điều kiện tốt nhất. Nó có thể vào hộp thư rác, bộ lọc spam của công ty có thể chặn liên kết, hoặc hộp thư đến có thể bị đầy
Cá nhân tôi chỉ có email trên iPhone; trên laptop công ty hoặc PC chơi game, tôi phải đăng nhập icloud.com mới kiểm tra được, khá phiền
Tôi mong họ cho nhập mật khẩu, hoặc cho quét mã QR như trên thiết bị nhúng, hoặc ít nhất cung cấp thêm một lựa chọn khác
Magic link cho phép truy cập vào passkey, còn passkey về cơ bản là phiên bản tăng cường của “ghi nhớ máy tính này”
Tôi vẫn quen với thời kỳ mà những người phía Apple hầu như không xuất hiện công khai
Không biết có phải mình hiểu nhầm gì không, nhưng passkey thực ra có vẻ không phải là phương án thay thế cho magic link
Mọi cách triển khai passkey mà mình từng thấy cho đến nay đều đề xuất tạo passkey sau khi đã đăng nhập bằng một cách khác
Mình chưa đào sâu, nhưng xét về trải nghiệm người dùng, passkey trông giống phương án thay thế cho nút “ghi nhớ máy tính này” hơn là phương án thay thế cho toàn bộ mật khẩu
Dù bằng cách nào, dịch vụ cũng cần biết rằng thiết bị mới này đã được phê duyệt
Tùy nhà cung cấp, có đồng bộ passkey, nhưng nó không giải quyết được chuyện xác thực ban đầu như thế nào
Điểm cốt lõi của magic link là hệ thống bảo mật không thể mạnh hơn cơ chế khôi phục của nó
Sẽ không có một thế giới nơi passkey được xem là phương thức xác thực duy nhất; cơ chế khôi phục sẽ luôn còn đó, và phần lớn sẽ là khôi phục tự động qua email
Nếu vậy, magic link trung thực ở chỗ nó đơn giản hóa mọi thứ thay vì giả vờ rằng bên trên còn có một lớp an toàn hơn
Khi biến cơ chế khôi phục thành phương tiện tương tác chính của luồng xác thực, ta cũng thành thật hơn về mức bảo mật thực tế của hệ thống xác thực
Chỉnh sửa: filmgirlcw đã để lại liên kết tới một bài viết hay hơn, giải thích hai cách này thực sự bổ sung cho nhau như thế nào: https://news.ycombinator.com/item?id=42628226
Magic link cũng có ưu điểm, nhưng mình không chắc việc biến email thành một vector tấn công mạnh hơn có phải là ưu điểm hay không
Với những người dùng trình quản lý mật khẩu, magic link rõ ràng là một điểm gây ma sát, và passkey có thể giảm đáng kể điều đó
Các vấn đề về trải nghiệm người dùng của passkey cũng còn chỗ để cải thiện, và khi có thể xuất ra, việc đồng bộ giữa các hệ thống sẽ tốt hơn nhiều
Một trong những lý do mình dùng 1Password làm hệ thống mật khẩu và passkey mặc định cũng là để dùng passkey giữa các thiết bị; công ty cũng dùng 1Password, nên mình đăng nhập cả tài khoản cá nhân lẫn tài khoản doanh nghiệp và có thể xác thực trên thiết bị cá nhân hoặc thiết bị công việc khi cần
Tuy nhiên, nếu vấn đề mà 404 định nghĩa là họ không muốn chịu trách nhiệm lưu trữ mật khẩu hay quyền kiểm soát xác thực, thì với một số người dùng, passkey tốt hơn magic link
Dù vậy, giống Ricky, mình nghĩ không nên là một trong hai mà phải là cả hai
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
Dùng passkey không nhất thiết đồng nghĩa với việc phải có phương thức đăng nhập thay thế, nhưng hiện chưa có dịch vụ nào chuyển hẳn sang chỉ dùng passkey
Người dùng OS cũ hoặc Linux có thể vẫn chưa tạo và lưu được passkey, và nhiều người dùng không dùng trình quản lý thông tin xác thực đa nền tảng
Ví dụ, nếu bạn tạo passkey bằng iCloud Passwords thì hiện tại không có cách nào đăng nhập trên Linux
Mình nghĩ sau vài năm nữa, chúng ta sẽ bắt đầu thấy các dịch vụ cho tạo passkey ngay từ đầu và hoàn toàn không thu thập mật khẩu
Hy vọng đặc tả về tính di động của passkey sẽ được triển khai, và Gnome/KDE cũng triển khai hỗ trợ passkey
Nếu việc dùng OTP trên điện thoại hoặc sao chép liên kết từ điện thoại khi truy cập website trên PC công việc đã là đau khổ, thì mình tự hỏi việc khiến máy tính làm việc liên kết với passkey cá nhân ở nơi như laptop sẽ dễ hơn và tốt hơn được bao nhiêu
Mình không dùng dịch vụ nào chỉ hỗ trợ magic link để xác thực. Nó rất thù địch với người dùng, và xét từ góc độ bảo mật thì rõ ràng tệ hơn mật khẩu dùng cùng trình quản lý mật khẩu
Điều chí mạng nhất là với thiết lập cá nhân của mình, nó hoàn toàn không hoạt động
Vì để bảo mật và an toàn tài khoản, mình không truy cập tài khoản email trên các thiết bị dùng để đăng nhập
Riêng Anthropic thì mình ngoại lệ vì Claude là LLM tốt nhất, nhưng mỗi lần phải đăng nhập lại đều cực kỳ khổ sở và mình đã gửi phản hồi phàn nàn nhiều lần
Mỗi lần thấy magic link, mình luôn nghĩ “chẳng phải ngay từ đầu chúng ta đã không nên nhấp vào liên kết trong email sao?”
Nghĩ đến liên kết email là mình cũng nghĩ ngay đến phishing
Mình thật sự ghét magic link
Mấu chốt là đừng nhấp vào các liên kết đáng ngờ. Nếu bạn biết magic link đã được gửi tới, thì đó không phải là liên kết đáng ngờ
Dù vậy, mình vẫn ghét magic link vì độ trễ
Cách bảo vệ quyền riêng tư email của Apple trông khá thú vị. Apple luôn tải tất cả ảnh, nhưng mình không rõ có nhược điểm nào không
Cách triển khai tốt nhất tôi từng thấy là vẫn phải nhấp vào liên kết trên thiết bị nhận email, nhưng không chuyển phiên sang thiết bị đó mà hoàn tất đăng nhập trên thiết bị ban đầu đã bắt đầu quy trình đăng nhập
Giải pháp tốt hơn là chỉ cho đăng nhập trên thiết bị đã mở liên kết, đồng thời để dùng giữa các thiết bị thì cung cấp thêm mã OTP có thể đọc trên thiết bị nhận và nhập dễ dàng vào thiết bị ban đầu
Hoặc cũng có thể chỉ cung cấp mã OTP, không cần liên kết
Không có gì tệ hơn việc đang làm trong một trình duyệt, nhưng khi mở email thì lại xác thực trong trình duyệt mặc định, hoặc tệ hơn là xác thực trên thiết bị khác, rồi phải chuyển liên kết sang đó và mở lại
Cũng có trường hợp không muốn truy cập một email cụ thể trên một thiết bị cụ thể, nên đây không hẳn là kịch bản kỳ lạ
Cách một trang gửi OTP kiểu
crazy-pink-horse-3837để người dùng sao chép rồi dán vào là một điểm cân bằng chấp nhận được nếu việc triển khai liên kết xác thực đúng yêu cầu ban đầu quá khóNhưng vấn đề trong triển khai là magic link được gửi lại bị bọc trong trình theo dõi lượt nhấp, và tên miền đó bị các công cụ như pihole chặn
Vì vậy không thể tới được URL xác thực thật để hoàn tất quy trình đăng nhập
Trình duyệt trong ứng dụng nên biến mất. Đặc biệt là những trình duyệt trong ứng dụng không cho chọn “mở trong trình duyệt thường”, và nếu là RSS reader thì càng phải cung cấp lựa chọn đó
Tất cả product manager ép người dùng dùng trình duyệt trong ứng dụng nên bị đưa vào tù
Lựa chọn tốt hơn nhiều là passkey dùng mã OTP gửi qua email và Conditional Mediation UI
Nếu người dùng đăng nhập trên thiết bị đã có passkey, CM UI sẽ cho chọn ngay để đăng nhập tức thì
Nếu là thiết bị chưa có passkey, có thể thiết kế trải nghiệm người dùng yêu cầu nhập mã email, và khi thành công thì lập tức thiết lập passkey để lần sau đăng nhập ngay
Như vậy trên thiết bị hiện có thì có được mức bảo mật của passkey, còn trên thiết bị mới thì có thiết lập không cần mật khẩu và khôi phục tài khoản
Thêm vào đó, cũng có thể tránh phụ thuộc nhà cung cấp khi nhà cung cấp đám mây nắm tất cả passkey