Địa chỉ email không phù hợp làm định danh 'vĩnh viễn' của tài khoản

Địa chỉ email không phù hợp làm định danh 'vĩnh viễn' của tài khoản

• Việc dùng địa chỉ email làm định danh nội bộ vĩnh viễn cho tài khoản là có vấn đề. Địa chỉ email của một người có thể thay đổi ngay cả trong cùng một tổ chức, tương tự như nhiều lý do khác nhau khiến tên hoặc thông tin đăng nhập thay đổi.
• Việc tổ chức không thay đổi hoặc đặt lại địa chỉ email đã cấp cho mọi người có thể không bền vững về mặt pháp lý.
• Địa chỉ email có thể bị tái sử dụng hoặc được cấp lại cho một người cụ thể, điều này có thể gây ra vấn đề bảo mật.

Định danh nội bộ nên không mang ý nghĩa

• Dù cần nhớ địa chỉ email để khôi phục tài khoản, định danh tài khoản nội bộ vẫn nên là một giá trị không mang ý nghĩa. Điều này giúp đơn giản hóa việc quản lý hệ thống về lâu dài.
• Trong các hệ thống xác thực như OIDC, nên dùng ID nội bộ duy nhất và vĩnh viễn thay vì địa chỉ email.
• Việc gán quá nhiều ý nghĩa cho địa chỉ email có thể dẫn đến các vấn đề bảo mật.

Ý kiến của GN⁺

• Điều quan trọng nhất trong bài viết này là việc dùng địa chỉ email làm định danh tài khoản vĩnh viễn có thể gây ra nhiều vấn đề khác nhau.
• Chủ đề này thú vị vì nhiều hệ thống dùng địa chỉ email để xác thực người dùng, nhưng bài viết chỉ ra rằng cách làm đó có thể tạo ra rủi ro bảo mật tiềm ẩn và các vấn đề trong quản trị.
• Bài viết này có thể giúp nâng cao nhận thức cho các kỹ sư phần mềm về những khía cạnh bảo mật và quản lý quan trọng cần cân nhắc khi thiết kế hệ thống nội bộ.

[GN⁺]

Ý kiến trên Hacker News

• Giới hạn của email và tên người dùng

  • Địa chỉ email có thể thay đổi, và mọi người có thể mất quyền truy cập vào email cũ.
  • Có nhiều bất mãn với tên người dùng, và mọi người muốn chọn những cái tên không nhất thiết phải là duy nhất. Ví dụ, thay vì những tên như user53267.
  • Cũng có trường hợp bị mất thiết bị, nên chỉ dựa vào UUID bí mật lưu trong cookie hoặc passkey của thiết bị là không đủ.
  • Có những người có email hoặc tên người dùng ổn định, nhưng hầu như không ai dùng cùng một thiết bị chính trong nhiều năm liền.
  • Vấn đề thường xuyên xảy ra với tài khoản email công việc ([e-mail]) và cách phần mềm của nhà cung cấp dùng "Đăng nhập bằng Google".
  • Mọi người kết hôn, ly hôn, chuyển giới, chuyển sang môi trường văn hóa khác và chọn tên mới. Tên và địa chỉ email đều thay đổi.
  • Những thứ như OIDC có thể cần API chuẩn cho phép thay đổi tên người dùng và địa chỉ email.

• Cách tự ứng phó của cá nhân

  • Gmail có thể bị khóa ngẫu nhiên bởi các thuật toán AI, và rất khó được hỗ trợ khắc phục khi có sự cố.
  • Yahoo có thể yêu cầu xác thực bằng email cũ, khiến người dùng mất quyền truy cập.
  • Yahoo/AOL/Tutanota/Protonmail có thể tự động xóa tài khoản nếu không đăng nhập thường xuyên.
  • Tự host vẫn cần email ban đầu, và nếu mất email đó thì có thể mất quyền truy cập vào tài khoản hosting.
  • Duo push có thể trở thành vấn đề khi điện thoại bị hỏng.
  • Xác thực qua SMS có thể rủi ro vì điện thoại hỏng, mất quyền truy cập gói cước, hoặc các vấn đề bảo mật từ phía nhân viên.
  • Dùng địa chỉ Gmail của trường đại học có vẻ là cách tốt nhất vào lúc này. Khi có vấn đề, có thể nhờ trung tâm hỗ trợ của trường giúp đỡ.

• Vấn đề của email và số điện thoại

  • Email không phù hợp làm định danh vĩnh viễn, còn dùng số điện thoại như một phần của định danh thì lại càng tệ hơn.
  • Có người đã dùng cùng một email gần 20 năm thông qua tên miền riêng, nhưng trong cùng khoảng thời gian đó đã đổi gần 12 số điện thoại.
  • Họ đang trả khoảng $150 mỗi tháng cho AT&T để giữ số Mỹ ngay cả khi sống ở nước ngoài.

• Đề xuất về địa chỉ email khóa công khai

  • Đưa ra ý tưởng hỗ trợ địa chỉ email khóa công khai (<[e-mail]>).
  • Ngay cả khi Google hoặc Hotmail ngừng dịch vụ, người dùng vẫn có thể xác thực bằng khóa riêng ở dịch vụ khác để truy cập cùng một tài khoản.
  • Ứng dụng email có thể ánh xạ các địa chỉ như vậy hoặc theo dõi chúng bằng khóa công khai.
  • Ý tưởng này cần được hỗ trợ ở quy mô lớn, nhưng đáng để suy nghĩ.

• Sử dụng UUID

  • Có ý kiến cho rằng UUID ngẫu nhiên là lựa chọn tốt nhất.
  • Việc băm email ban đầu của người dùng có thể không đủ an toàn chỉ với salting.

• Liên kết nhiều địa chỉ email

  • Đang thay đổi hệ thống email để cho phép liên kết nhiều địa chỉ email với một tài khoản.
  • Để cấp ưu đãi cho sinh viên, cách dễ nhất là xác minh email giáo dục, nhưng hầu hết mọi người không muốn đăng ký bằng email đó.
  • Cho phép nhiều email sẽ giúp có được ưu điểm của cả hai phía.

• Vấn đề liên kết địa chỉ email với địa chỉ vật lý

  • Ví dụ về một nhà cung cấp năng lượng không cho phép dùng một địa chỉ email cho nhiều địa chỉ vật lý.
  • Điều này gây rắc rối khi thiết lập tài khoản trực tuyến vì không thể dùng cùng một địa chỉ email.

• Giải pháp phía client

  • Có thể trả tiền cho một tên miền để kiểm soát 100% các bí danh email.
  • Ngay cả khi nhà cung cấp hiện tại (Google) gặp sự cố, vẫn có thể host mail trên máy chủ riêng để khôi phục tài khoản và giữ quyền sở hữu bí danh.

• Vấn đề giữa định danh và xác thực

  • Có vấn đề khi trộn lẫn khái niệm định danh và xác thực trong cùng một cuộc thảo luận.
  • Bài toán định danh về cơ bản đã được giải quyết bằng các chuỗi hoặc con số duy nhất gắn với con người, như tên, email, giấy tờ tùy thân, v.v.
  • Bài toán xác thực là kiểm tra một người có thực sự là chính họ hay không, và đây là một trong những vấn đề lớn nhất mà công nghệ hiện đại đang đối mặt.
  • Người ta dùng kết hợp mật khẩu, vị trí địa lý, địa chỉ IP, email, số điện thoại, token bảo mật và chứng chỉ, nhưng các hệ thống này vẫn thường xuyên bị xâm phạm, còn việc siết bảo mật hơn nữa lại ảnh hưởng tiêu cực đến người dùng hợp pháp.

• Vấn đề backend

  • Với người dùng, email là ID, nhưng trong dữ liệu hệ thống thì không nên dùng email làm khóa chính.
  • Đây là vấn đề cơ bản trong thiết kế cơ sở dữ liệu: nên có bảng tra cứu ánh xạ sang một ID duy nhất mà không dùng các định danh như email làm khóa chính, chẳng hạn UUID hoặc số tự tăng từ sequence.
  • Bài viết không làm rõ sự phân biệt này, nên có thể khiến người đọc hiểu như thể người dùng cần tự nhận thức về lớp trừu tượng đó.