Địa chỉ email không phù hợp làm mã định danh 'vĩnh viễn' cho tài khoản
(utcc.utoronto.ca)- Khi tạo ID tài khoản dài hạn bên trong hệ thống, chỉ vì OIDC trả về địa chỉ email mà dùng nó làm ID vĩnh viễn thì sẽ phải gánh cùng lúc các vấn đề về thay đổi và tái sử dụng
- Địa chỉ email, ngay cả trong cùng một tổ chức, cũng có thể thay đổi như tên gọi hay tên đăng nhập, nên không đủ ổn định để dùng làm giá trị chuẩn của tài khoản
- Dù quyền truy cập thư hoặc chuyển tiếp từ địa chỉ cũ vẫn còn, không có gì đảm bảo địa chỉ đó vẫn tiếp tục hoạt động cho các mục đích không phải email như xác thực OIDC
- Địa chỉ email có thể cần cho việc khôi phục tài khoản, nhưng nếu hệ thống xác thực cung cấp một ID riêng biệt, duy nhất và vĩnh viễn thì nên dùng giá trị đó làm ID nội bộ
- Ngay cả khi đó là giá trị người dùng không nhìn thấy, mã định danh nội bộ của tài khoản vẫn nên là một ID vô nghĩa để việc vận hành dài hạn và bảo mật được đơn giản hơn
Vì sao người ta dễ muốn dùng địa chỉ email làm ID vĩnh viễn
- Lý do địa chỉ email trở thành ứng viên khi tạo mã định danh nội bộ cho từng tài khoản là vì các hệ thống xác thực như OIDC trả về dữ liệu có bao gồm địa chỉ email
- Nhưng nếu dùng địa chỉ email làm mã định danh nội bộ vĩnh viễn của tài khoản thì sẽ phát sinh hai vấn đề: khả năng thay đổi và khả năng tái sử dụng
Địa chỉ có thể thay đổi thì khó làm giá trị chuẩn
- Vấn đề lớn nhất là địa chỉ email có thể thay đổi
- Ngay cả trong cùng một tổ chức, địa chỉ email của một người vẫn có thể đổi
- Nó có thể thay đổi vì những lý do cùng loại với việc tên gọi dùng hằng ngày hay tên đăng nhập thay đổi
- Việc từ chối thay đổi hoặc cấp lại địa chỉ email do tổ chức cấp có thể là một sự cứng nhắc đến mức khó duy trì về mặt pháp lý ở nhiều nơi
- Ngay cả khi địa chỉ email cũ không biến mất hoàn toàn thì nó vẫn không đủ để làm mã định danh vĩnh viễn
- Quyền truy cập hoặc chuyển tiếp từ địa chỉ cũ có thể vẫn còn
- Nhưng như vậy cũng không có nghĩa địa chỉ cũ sẽ tiếp tục hoạt động cho các mục đích không phải email như xác thực OIDC
- Người dùng cũng muốn dùng địa chỉ email mới hiện tại thay vì địa chỉ cũ có thể gây bất tiện
Cần tách riêng chuyện tái sử dụng và email khôi phục
- Một vấn đề nhỏ hơn là không có gì đảm bảo tổ chức sẽ không tái sử dụng địa chỉ email
- Nói chung, địa chỉ có thể bị tái sử dụng
- Đặc biệt, các địa chỉ được ưa chuộng có thể bị tái sử dụng hoặc phân lại ngoại lệ theo mong muốn của người có ảnh hưởng
- Nếu việc khôi phục tài khoản cần được thực hiện qua địa chỉ email đã đăng ký thì có thể vẫn cần lưu email
- Nhưng nếu có một ID nội bộ về mặt lý thuyết là duy nhất và vĩnh viễn như trong OIDC thì nên dùng ID nội bộ đó
- Ngay cả khi phải lưu email dùng cho khôi phục tài khoản, mã định danh nội bộ của tài khoản vẫn nên là một ID vô nghĩa
- Dù giá trị này không lộ ra cho người dùng, về lâu dài nó vẫn giúp việc vận hành đơn giản hơn
- Nếu gán quá nhiều ý nghĩa cho địa chỉ email thì cũng có thể ẩn chứa vấn đề bảo mật
1 bình luận
Các ý kiến trên Hacker News
Không có định danh danh tính tốt
Email thay đổi, và đôi khi ta mất quyền truy cập vào email cũ
Tên người dùng cũng bị nhiều người không thích, nên thay vì một tên duy nhất vô nghĩa như
user53267, họ muốn chọn một tên không nhất thiết là duy nhấtThiết bị cũng có thể bị mất, nên chỉ lưu UUID bí mật trong cookie hoặc dùng passkey của thiết bị không giải quyết được vấn đề
Không có giải pháp lý tưởng, phải kết hợp nhiều cách. Với một số người, email ổn định lâu dài và là định danh danh tính tốt; với người khác, tên người dùng ổn định hơn nên họ thích cách đó. Tuy nhiên, tôi hầu như chưa thấy ai dùng cùng một thiết bị chính trong nhiều năm, chứ đừng nói vài chục năm, nên định danh dựa trên thiết bị có lẽ sẽ không hiệu quả
Điều này đặc biệt hay lộ rõ với email công ty dạng
first.last@company.com. Nhiều phần mềm của nhà cung cấp dùng Sign in with Google, rồi lưu địa chỉ email đó làm định danh trong ứng dụng của nhà cung cấpTên thay đổi do kết hôn, ly hôn, chuyển giới, chuyển sang môi trường văn hóa khác, chọn tên mới, v.v.; địa chỉ email cũng thay đổi theo
Có lẽ những thứ như OIDC cần các phần mở rộng mới, chẳng hạn API tiêu chuẩn để đổi tên người dùng và API tiêu chuẩn để đổi địa chỉ email
Trừ các định danh công như giấy tờ tùy thân chính thức hay số an sinh xã hội, có vẻ khó làm tốt hơn thế
subkhông được tái gán và phải là duy nhất: https://openid.net/specs/openid-connect-core-1_0.html#IDToke...Tất nhiên, điều đó có nghĩa là không được đặt địa chỉ email vào
subcủa ID tokenTôi từng gặp một công ty mà khi chuyển thành nhân viên chính thức thì phải tạo một tài khoản hoàn toàn mới; vì không có hệ thống phân quyền đơn giản và thống nhất, ngay sau khi chuyển đổi tôi mất khoảng 3 tuần để lấy lại quyền truy cập vào các hệ thống mà ngày hôm trước vẫn dùng được
Điều buồn cười hơn là công ty đó kinh doanh rất nhiều trong mảng cung cấp hệ thống tài khoản phức tạp cho khách hàng, và còn có hệ thống danh tính dùng cho bên ngoài có thể xử lý dễ dàng các vấn đề như vậy. Nhưng họ lại không áp dụng nó cho chính nhân viên nội bộ đang duy trì hệ thống danh tính bên ngoài đó
Vì ai cũng có số đi kèm nên con số đó không mang nhiều ý nghĩa. Tôi hơi tiếc khi họ chuyển sang ID tài khoản duy nhất, và đến giờ vẫn tò mò vì sao họ đổi
Với tư cách cá nhân, cách tốt nhất để xử lý vấn đề này là gì?
Gmail có thể đột ngột bị khóa hoặc bị cấm tài khoản do thuật toán AI, và nếu có gì sai thì không có cách cứu vãn
Yahoo gần đây khi đăng nhập đã yêu cầu xác thực bằng một email không hoạt động mà tôi đã không truy cập được suốt 15 năm, nên tôi mất quyền truy cập. May là tôi vẫn truy cập được qua ứng dụng email client, nên đã có thể chuyển các tài khoản quan trọng đi
Yahoo/AOL/Tutanota/Protonmail/và nhiều dịch vụ khác sẽ tự động xóa tài khoản nếu bạn không đăng nhập đủ thường xuyên. Protonmail hiện chưa làm vậy, nhưng điều khoản cho phép họ làm
Tự host thì ngay từ đầu toàn bộ hạ tầng cũng cần email. Nếu mất quyền truy cập email đó, bạn cũng bỏ lỡ thông báo thanh toán và có thể mất cả tài khoản hosting. Tôi từng suýt mất domain vì thông báo thanh toán được gửi tới một email không hỗ trợ IMAP nên tôi hầu như không kiểm tra. Nếu không phải quản trị viên hệ thống chuyên nghiệp và không có đủ thời gian bảo trì, rủi ro bị hack cũng cao hơn
Duo push thì điện thoại hỏng là xong, còn xác thực SMS có các vấn đề như điện thoại bị hỏng, mất quyền truy cập gói cước, nhân viên nội bộ làm lộ mã
Cuối cùng tôi quyết định dùng địa chỉ Gmail của trường đại học. Họ hứa cựu sinh viên vẫn được giữ, và nếu có gì trục trặc — có lẽ là trường hợp mất điện thoại nên mất bước xác thực thứ hai — thì có một trung tâm hỗ trợ cựu sinh viên khá ổn
Nhất thiết phải có kênh hỗ trợ có con người để nói chuyện ở đâu đó. Dù vậy tôi không chắc đây có phải cách tốt nhất không, và vẫn thắc mắc liệu còn rủi ro nào từ phía Google hay không
Như đã nói, nếu bị khóa thì “chỉ cần” đổi nhà cung cấp, và cùng lắm chỉ mất vài giờ email
Tôi đồng ý rằng email không phải là định danh lâu dài tốt. Nhưng dùng số điện thoại như một phần của việc định danh còn tệ hơn
Tôi đã dùng cùng một email với tên miền riêng gần 20 năm, nhưng trong cùng khoảng thời gian đó số điện thoại của tôi đã đổi gần 12 lần. Tôi thường thấy các trường hợp website vẫn bật xác thực 2 bước bằng số cũ, hoặc người dùng quên mất rằng ban đầu họ đã đăng ký số cũ đó trên site
Ngay cả khi đang sống ở nước ngoài, tôi vẫn phải duy trì số Mỹ với AT&T và trả khoảng 150 đô la tiền thuế mỗi tháng, vì vẫn có những site gửi mã đăng nhập tới số đó, và tôi sợ nếu bỏ số thì sẽ mất quyền truy cập vào các dịch vụ quan trọng do quên cập nhật hoặc do cần số Mỹ để đổi
Sau này nếu muốn dùng lại số đó trên tài khoản di động, chỉ cần chuyển số lại sang nhà mạng bạn muốn
Với các dịch vụ có thể, hãy đổi xác thực 2 bước sang ứng dụng như Google Authenticator, rồi chuyển số sang Google Voice để nhận tin nhắn tới số cũ miễn phí
Nếu hoàn toàn không muốn dính dáng đến Google, cũng có nhiều ứng dụng xác thực dựa trên thời gian khác, và có thể dùng www.tossabledigits.com cho tin nhắn
Ngay cả nếu xét như dịch vụ di động thông thường thì mức đó cũng quá cao. Tôi trả chưa đến 100 đô la/tháng cho hai đường dây
Trước đây khi chuyển nhà, số điện thoại văn phòng cá nhân của tôi không được phép dùng ở khu vực mới, nhưng may là tôi có thể chuyển nó sang tài khoản VoIP
Hồi đó Internet còn chậm nên tôi dùng bộ chuyển đổi điện thoại Ethernet một thời gian; về sau chỉ dùng số đó để nhận cuộc gọi. Cả cuộc gọi thoại và fax đều được chuyển tiếp vào email
Nó đã hoạt động tốt hơn 20 năm. Vì không có thiết bị nào cần kết nối nên chi phí hằng năm cũng khá thấp
Một ngày nào đó tôi có thể kết nối điện thoại để tận dụng Internet hiện đại, nhưng tôi thích cách hiện tại và thích việc nó không bị ràng buộc vào một địa điểm cụ thể
Kinh nghiệm của tôi cũng vậy. Cá nhân tôi cho rằng UUID ngẫu nhiên là tốt nhất
Ngay cả hash của email ban đầu của người dùng cũng không lý tưởng. Chỉ salt có thể là chưa đủ, và người khác có thể giả định rằng bất kỳ email đầu vào nào cũng có thể được hash một cách an toàn
Trong thực tế, tôi luôn dùng số nguyên tự tăng hoặc chuỗi/UUID ngẫu nhiên làm khóa chính
Nó không nên liên quan gì đến các thuộc tính ngoài đời mà mọi người quan tâm, như số điện thoại, địa chỉ email, ID quốc gia kiểu số định danh công dân, tên hay vân tay
Chuỗi ngẫu nhiên đáp ứng đúng điều kiện này. Số nguyên tuần tự cũng ổn, nhưng dễ đoán nên có thể cần thêm biện pháp bảo mật
Sẽ thế nào nếu hỗ trợ địa chỉ email khóa công khai? Ví dụ coi những thứ như . và . là tương đương nhau
Cho phép người dùng đăng ký bằng một bên rồi vẫn đăng nhập hoặc khôi phục tài khoản bằng bên còn lại. Nếu Google cấm tôi hoặc Hotmail sập, tôi có thể sang dịch vụ khác, xác thực bằng khóa riêng và mở cùng tài khoản
Tất nhiên sẽ cần một quy trình bí danh để dùng tên thuận tiện, nhưng có lẽ trình email phải ánh xạ các địa chỉ như vậy hoặc ít nhất theo dõi chúng cùng với khóa công khai
Đây cũng có thể là cơ hội để đưa email mã hóa đầu cuối vào. Thứ này hầu như chưa từng được áp dụng rộng rãi
Để thực sự hoạt động thì các nhà cung cấp lớn phải hỗ trợ, nhưng nghĩ nhanh thì ý tưởng này có vẻ khá vững. Chỉ trừ việc hiện chưa ai hỗ trợ nó
Các cách mới để định danh và giao tiếp trên web đang được xây dựng theo hướng bạn sở hữu danh tính của mình, không phụ thuộc vào nhà cung cấp hay một cơ quan trung ương
Nhà cung cấp năng lượng trước đây của tôi, British Gas (thuộc sở hữu của Centrica), không cho phép dùng một địa chỉ email cho nhiều hơn một địa chỉ thực
Sau khi chuyển nhà, tôi cố “thiết lập” tài khoản online thì cứ mỗi lần xem thông tin địa chỉ hiện tại là gặp HTTP 500
Khi gọi điện hỏi, họ nói rằng dù tài khoản năng lượng ở địa chỉ cũ đã đóng, “không thể dùng cùng một địa chỉ email cho nhiều địa chỉ bưu chính”
+whatever. Nếu là Gmail thì cũng dùng được mẹo dấu chấm.Hiện tôi đang sửa hệ thống email để cho phép nhiều địa chỉ email liên kết với một tài khoản
Một trong các lý do chính là chúng tôi cung cấp giảm giá cho sinh viên. Cách dễ nhất để áp dụng giảm giá cho tài khoản là kiểm tra xem email có phải địa chỉ của cơ sở giáo dục không, như
.edu,.ac.ukNhưng có vẻ phần lớn người dùng không thực sự muốn đăng ký bằng email đó. Cho phép nhiều email thì có thể có được ưu điểm của cả hai bên
Giá mà ngay từ đầu chúng tôi đã làm như vậy
.edusau khi tốt nghiệp đại họcTôi có một địa chỉ khá hay. Tôi đăng ký sớm nên địa chỉ chỉ có tên của tôi
Tuy vậy tôi không dùng nhiều. Thời kỳ đầu, việc chuyển tiếp thỉnh thoảng không ổn định, nhưng giờ chắc đã tốt hơn
Thực tế là địa chỉ Gmail của tôi đã ổn định gần vài chục năm rồi và có vẻ cũng sẽ không thay đổi
Dù sao thì tôi chỉ cho rất ít người biết địa chỉ edu của mình
Dù không phải cách thanh lịch nhất, vẫn có giải pháp phía client
Nếu tự trả phí và duy trì tên miền, bạn có thể kiểm soát 100% bí danh email
Ngay cả khi nhà cung cấp hiện tại là Google sụp đổ, bạn vẫn có thể tự host mail để khôi phục tài khoản và giữ quyền sở hữu bí danh
Tôi xem đây là vấn đề backend. ID hiển thị cho người dùng có thể là email, nhưng khóa chính trong dữ liệu hệ thống thì không được là email
Đến giờ vẫn còn nơi làm như vậy sao? Không nên dùng những thứ như email làm định danh; việc có một bảng tra cứu ánh xạ chúng tới một ID thực sự duy nhất (UUID hoặc giá trị tự tăng dựa trên sequence) là vấn đề thiết kế cơ sở dữ liệu cơ bản nhất
Bài viết không phân biệt rõ điều này, nên đôi khi có thể đọc thành kiểu người dùng phải nhận thức được lớp trừu tượng hóa này
Không có gì là vĩnh viễn. Ngay cả những thứ ổn định trong suốt cả đời người cũng gần như không có
Các dấu hiệu sinh trắc học dễ quét cũng không ổn định và duy nhất trong một quần thể đủ lớn
Địa chỉ email được chọn cho mục đích này vì chúng ổn định và duy nhất trong một khoảng thời gian khá dài
Số điện thoại cũng đã trở thành một định danh bám dính hơn trước, và giờ tương tự email với tư cách là một định danh hữu ích
Cả email lẫn số điện thoại đều thường xuyên bị mất, và thường mất cùng lúc
Địa chỉ email dự phòng là câu trả lời
Tôi cho rằng GitHub xử lý danh tính khá tốt, nhưng họ vẫn dùng mật khẩu. Mật khẩu thì tệ