Mẫu “email chính là xác thực”

• Một số người dùng, thay vì ghi nhớ hoặc quản lý mật khẩu, lại dùng quy trình “Quên mật khẩu” mỗi lần như một cách đăng nhập
• Luồng thực tế là: tại trang đăng nhập, họ nhận liên kết khôi phục qua email, nhập mật khẩu tạm thời, rồi trong lần truy cập tiếp theo lại lặp lại cùng quy trình
• Thói quen này không hẳn là một chiến lược bảo mật có chủ ý, mà gần với một hành vi đã học được và hình thành theo thời gian
• Ngay cả các biện pháp cải thiện như trình quản lý mật khẩu và xác thực hai bước/đa yếu tố cũng có thể bị người dùng cảm nhận là tăng thêm ma sát hơn là tăng cường bảo mật
• Thiết kế hệ thống cần lấy hành vi lặp lại của người dùng làm tiền đề, và dẫn dắt họ chuyển sang cách sử dụng tốt hơn một cách tự nhiên

---

Khôi phục mật khẩu được dùng như đăng nhập

• Một số người dùng không nhập mật khẩu khi đăng nhập vào tài khoản trực tuyến, mà lặp lại quy trình khôi phục mỗi lần
  • Đi tới trang đăng nhập
  • Nhấp vào “I forgot my password”
  • Chuyển sang email
  • Nhấp vào liên kết khôi phục
  • Nhập một mật khẩu tạm thời mà họ sẽ không nhớ
  • Sau đó lặp lại cùng quy trình
• Khi được hỏi vì sao làm vậy, họ không trả lời được, hoặc phản ứng rằng chưa từng nghĩ đến lý do
• Hành vi này không phải là một chiến lược đăng nhập được đặt ra vào buổi sáng, mà gần với một quy trình lặp lại đã hình thành theo thời gian

Ma sát mà cải tiến bảo mật tạo ra cho người dùng

• Cách này hoạt động như một giải pháp ít tốn công sức, giúp người dùng không cần nhớ cụm mật khẩu
• Trình quản lý mật khẩu, đánh cắp danh tính, xác thực hai bước và xác thực đa yếu tố, cũng như sự lỗi thời của mô hình tên người dùng/mật khẩu, đều là những chủ đề đã được thảo luận rộng rãi
• Các quy trình bảo mật tốt hơn thường làm tăng rào cản và ma sát, khiến người dùng khó chấp nhận một cách tự nhiên
• Nhà thiết kế cần cân nhắc hành vi đã học được của người dùng, để tạo ra luồng giúp họ dần chuyển sang cách sử dụng tốt hơn theo thời gian

[GN⁺]

Ý kiến trên Hacker News

• Tài khoản email là mẫu số chung phổ biến nhất trong xác thực trực tuyến. Điện thoại di động cũng có sức cạnh tranh, nhưng có thể bị mất; số điện thoại thì phổ biến hơn và tồn tại lâu hơn, nhưng mức độ bảo mật thấp hơn nhiều so với tài khoản của các nhà cung cấp email lớn
  Nếu muốn thiết kế “hệ thống xác thực tưởng tượng dành cho Internet”, trước hết phải nhìn vào khôi phục tài khoản. Nếu câu trả lời khi đánh mất bộ xác thực xịn là “thì không truy cập được nữa” hoặc “một hội đồng đồng nghiệp bảo chứng danh tính”, thì hệ thống đó chỉ hoạt động khi người dùng là một dạng sinh vật trí tuệ tưởng tượng chứ không phải con người

  • Đây là lý do lớn nhất khiến tôi phản đối blockchain/tiền mã hóa trong nhiều năm. Cách nghĩ “mất khóa là mất ví” về căn bản không phù hợp với người dùng trong đời thực
    Con người cần có khả năng phục hồi sau sai lầm
  • Danh tính số do chính phủ cấp có thể giải quyết phần lớn vấn đề này. Dù sẽ có vấn đề riêng, việc giao định danh cá nhân cho chính phủ có vẻ có giá trị hơn và ít rủi ro hơn so với việc bị các hãng như Google khóa tài khoản
  • Đáng tiếc là ngay cả ở các nhà cung cấp email lớn như Google, “thì không truy cập được nữa” cũng là một mẫu hình phổ biến. Những người mất hoặc bị trộm điện thoại rồi bị khóa vĩnh viễn khỏi tài khoản là ví dụ rõ nhất
  • Với “tài khoản email của nhà cung cấp lớn” cũng có thêm điều kiện kiểu “tài khoản bị đình chỉ không lý do, không có cách khiếu nại, và cũng không cho biết vì sao bị đình chỉ”
  • Cách một hội đồng đồng nghiệp bảo chứng danh tính của một cá nhân là một bài toán thiết kế thú vị. Nếu có một hệ thống chung có thể tái hợp các bí mật xác thực được phân tán hợp lý theo chỉ dẫn của các bên liên quan, thì có thể làm khá mượt
    Liệu có thể làm cho nó hoạt động với người bình thường không? Tôi nghĩ ta có đủ sức sáng tạo để thiết kế được

• Dịch vụ của chúng tôi là một mảng kinh doanh khá nhẹ nhàng, nên người dùng chỉ dùng tài khoản vì tiện. Cách chúng tôi chốt lại là: người dùng nhập email, chúng tôi gửi mã xác thực qua email, người dùng nhập mã thì được cấp một cookie rất dài, về thực chất là đăng nhập vô thời hạn
  Việc đã có tài khoản hay chưa không quan trọng; nếu là email mới thì tạo tài khoản mới. Đôi khi người dùng có nhiều email vô tình tạo tài khoản mới, nhưng tỷ lệ chuyển đổi đăng ký và đăng nhập tốt hơn nhiều nên đáng chấp nhận. Thời hạn hiệu lực của mã và số lần thử cần phân tích rủi ro, và nếu có thể thì nên dùng cơ chế khóa. Nếu dịch vụ không quá quan trọng, tôi khuyên dùng chiến lược này. iOS Mail giờ cũng hỗ trợ kiểu này giống tính năng mã dùng một lần của Messages, nên khá tiện cho một số người dùng

  • Theo dữ liệu tôi từng thấy, cách này vượt trội trong việc tối đa hóa doanh thu thương mại điện tử
    Đừng ép người mua tạo tài khoản, chỉ cần yêu cầu thông tin chi tiết. Dù sao trình duyệt cũng tự động điền. Sau đó gửi liên kết kiểm tra trạng thái đơn hàng qua email, và ở đơn hàng tiếp theo lại hỏi email. Ma sát bổ sung sẽ gây mất doanh thu lớn hơn lợi ích có được từ “người dùng đã đăng ký”
  • Tôi đang vận hành một ứng dụng B2C nhỏ; người dùng đăng ký chỉ bằng địa chỉ email và hoàn toàn không có trường mật khẩu. Tài khoản được tạo và trên thiết bị đó họ được đăng nhập vô thời hạn
    Chỉ khi cần đăng nhập trên thiết bị khác mới có thể yêu cầu mật khẩu mới. Cách này giảm ma sát đăng ký và mật khẩu yếu. Phần lớn người dùng dù sao cũng hiếm khi cần đăng nhập trên thiết bị khác
  • Tôi đã triển khai kiểu đăng nhập này nhiều lần, và nó xuất phát từ kinh nghiệm phải gỡ bỏ rất nhiều giả định về việc “tài khoản người dùng” là gì. Trên thực tế, để funnel vận hành theo cách cả hai bên đều muốn, cần sự đơn giản hóa như vậy
    Nếu không phải lĩnh vực cần bảo toàn tính ẩn danh thì làm thế cũng được, rồi sau này tích hợp passkey. Nhược điểm là không thể chia sẻ mật khẩu, nên phải nghĩ sớm hơn về bài toán quản lý nhiều người dùng trên một tài khoản. Nhưng nếu xử lý có chủ ý, funnel hay trải nghiệm người dùng rốt cuộc sẽ tốt hơn. Ngoài ra, bảo mật sẽ bị ràng buộc bởi mức bảo mật trung bình của các nhà cung cấp email của người dùng, nhưng thường vẫn tốt hơn mức cần thiết. Mật khẩu có thể dùng sau này như yếu tố thứ hai khi cần, hoặc thêm yếu tố khác; nếu là B2B thì có thể đi thẳng sang SAML hoặc OIDC. Trong B2B hoặc D2C, cách này luôn hoạt động tốt, và các trường hợp ngoại lệ đáng để xử lý vì lợi ích thu được
  • Tôi từng thấy kiểu đăng nhập này rồi; sao không gửi trong email một liên kết đưa người dùng về trang chủ ứng dụng và đã ở trạng thái đăng nhập sẵn?
    Việc sao chép mã, tìm tab đang mở trang đăng nhập, rồi dán vào khá phiền
  • Tôi đã dùng cách này trong một ứng dụng CRUD nhỏ gần như chỉ có một biểu mẫu, và trong suốt chiến dịch, yêu cầu hỗ trợ gần như bằng 0 nên rất đáng giá

• Đến mức này thì chẳng phải chỉ cần gửi một liên kết URL dùng một lần tới địa chỉ email và cho đăng nhập bằng một cú nhấp là được sao? Cho nó hết hạn trong 10 phút và hủy sau một lần dùng là xong
  Tất nhiên bất kỳ ai có liên kết đầu tiên cũng có thể đăng nhập vào tài khoản, nhưng dù sao nó chỉ truy cập được từ email. Cảm giác bảo mật vượt quá tài khoản email thì coi như mất hết, nhưng thực tế đã đến mức đó rồi. Nếu dùng mẫu như “nhấp để xác thực đăng nhập: www.someurl.com?p=134234535” qua tin nhắn điện thoại, thì đó là xác thực hai bước không phải nhập mã một cách ngớ ngẩn

  • Nhiều web app đang dùng cách này, nhưng nó gây bối rối cho người dùng (“Sao mình đã có tài khoản rồi? Mình chưa từng đăng ký mà!”), tốn chi phí (gửi email không miễn phí), và cũng chậm
    Email có thể rơi vào spam, hoặc không đăng nhập được trong vài giờ vì greylisting, hoặc mất 1 phút mới tới mà như vậy đôi khi đã cảm thấy quá lâu. Tôi không chắc có nên khuyến nghị không
  • Tôi thật sự ghét những trang chỉ cung cấp cách này mà không gửi được email trong vòng 30 giây
    Với kiểu “nhấp để xác thực đăng nhập” gửi qua điện thoại, phải cung cấp cả mã lẫn liên kết. Không phải thiết bị dùng để đăng nhập lúc nào cũng là điện thoại, nên nên là “nhập 1234 hoặc nhấp”
  • Một số trang như Netdata làm như vậy
    Nhưng nó chậm hơn việc trình quản lý mật khẩu tự động điền cặp tên người dùng/mật khẩu, vì phải chờ email rồi nhấp liên kết
  • Tôi đang làm một web app với đúng quy trình đăng nhập này, và gặp vấn đề trên di động. Các ứng dụng như Gmail không cho sao chép liên kết sang trình duyệt nếu không có bản xem trước, và chính bản xem trước đó lại tiêu thụ liên kết (next.js auth)
    Tôi không muốn đăng nhập trong trình duyệt in-app của Gmail mà muốn đăng nhập trong trình duyệt thông thường, nên khá phiền
  • Nếu vậy thì thà đi đến cùng với single sign-on còn hơn. Dù sao 95% người dùng sẽ dùng một trong Gmail, Outlook hoặc Apple
    Nút “Đăng nhập bằng Google” tốt hơn “gửi liên kết qua email”, và cách nào thì cũng có thể theo dõi được

• Ý tưởng rằng con người sẽ tạo và nhớ mật khẩu cho mọi dịch vụ chẳng mấy quan trọng là không thực tế. Việc tạo thêm một hệ thống xác thực dựa trên mật khẩu gần như chỉ là một kiểu đóng vai
  Mật khẩu thường được dùng theo một trong hai cách: trình quản lý mật khẩu được bảo vệ bằng một mật khẩu thật, hoặc cùng một mật khẩu lặp lại cho từng dịch vụ. Vì hầu như mọi dịch vụ đều cung cấp khôi phục qua email, nên trên thực tế email chính là phương tiện xác thực. Email cá nhân thì hiếm khi đổi, không chia sẻ, và cũng không được tái sử dụng. Có lẽ bạn đã dùng email cá nhân lâu hơn cả số điện thoại. Trong thời gian dùng địa chỉ email hiện tại, số điện thoại đã đổi ít nhất năm lần, và những số đó giờ đang được người khác dùng

  • Cũng có loại mật khẩu phái sinh, một dạng lai. Có thể là mẫu mà con người nhớ, cũng có thể là công cụ quản lý tính toán theo từng domain
    Và chức năng quên mật khẩu ít nhất cũng thông báo mọi lần thử cho chủ sở hữu địa chỉ. Đăng nhập dựa trên mật khẩu không phải lúc nào cũng gửi email mỗi khi đăng nhập từ vị trí mới
  • Apple đã làm cho quy trình “không thể chỉ nhập mật khẩu 1Password/Keychain mà phải bị làm phiền qua email” tốt hơn rất nhiều. Ít nhất là khi nó nhận diện email hoặc tin nhắn và điền mã thay bạn

• Câu trả lời rất đơn giản. Thường liên quan đến sự bất tiện mà nhà cung cấp dịch vụ đã tạo ra cho người dùng. Trong trường hợp này thì có vẻ rõ ràng: phiên của nhà cung cấp email thường gần như không bao giờ kết thúc và vẫn đăng nhập trừ khi xóa cache trình duyệt
  Chỉ cần đặt token xác thực của dịch vụ mình có thời hạn ngang với Gmail, và cho phép đăng nhập bằng mật khẩu dùng một lần mỗi lần như một phương án thay thế. Nhưng phải dừng cái thông lệ báng bổ kiểu token xác thực 12 giờ. Khi đó người dùng sẽ không bao giờ đăng nhập bằng khôi phục mật khẩu nữa

  • Lý do thật sự có thể là các website đó đơn giản là không hoạt động đúng
    Trước đây tôi từng gặp vấn đề với tài khoản Epic và Spotify. Tạo tài khoản, dùng một tuần thì phiên hết hạn và Spotify đá tôi ra khỏi tài khoản. Khi đăng nhập lại thì báo mật khẩu sai, nhưng nó được lưu trong trình quản lý mật khẩu nên chuyện đó là không thể. Cuối cùng chỉ còn cách đặt lại qua email. Vài lần đầu, dù nhận email và đặt lại thì mô thức tương tự vẫn lặp lại; sau 3–4 lần thì thậm chí email cũng không tới, phải tạo tài khoản mới. Giờ tôi đăng nhập Spotify bằng tài khoản Google và vẫn chưa gặp vấn đề. Nhưng nếu dùng email thông thường thì hệ thống xác thực của họ đơn giản là không chạy
  • Tôi nghĩ đây là gợi ý gần với sự thật hơn. Gmail, Cloudflare và nhiều “tổ chức bảo mật cao” khác có phiên xác thực rất dài. Lý do là xác suất ai đó có quyền truy cập vào PC của người dùng các hệ thống này trong khi người dùng chưa đăng xuất thực tế rất thấp. Phần lớn vụ hack nhắm từ xa vào mật khẩu yếu
    Vấn đề là chúng ta thiếu một ngôn ngữ nhất quán để đo rủi ro và phán đoán “trang này có thật sự cần xác thực hai bước không?”, “thời gian phiên 30 phút có hợp lý không?”. Nếu có phần mềm diệt virus cập nhật, đa số sẽ muốn duy trì trạng thái đăng nhập. Bạn đã từng bị yêu cầu xóa toàn bộ cookie để sửa lỗi của một trang nào đó chưa? Câu trả lời của tôi luôn là từ chối. Tôi từng nghe câu “tài khoản là của bạn, và nếu bạn chấp nhận rủi ro bị hack để duy trì đăng nhập thì đó là rủi ro của bạn, không phải của đơn vị vận hành dịch vụ”, và tôi ngày càng đồng ý hơn. Nếu ai đó xóa hết EC2 instance khi laptop của bạn vẫn đăng nhập, đó là lỗi của bạn, không phải lỗi của AWS vì đã không đăng xuất bạn sớm hơn. AWS có thể làm vậy, nhưng tại sao phải làm? Không có lý do gì để làm phiền 1 triệu người chỉ để bảo vệ 1 người bất cẩn
  • Nói đúng. Tôi đã mệt vì các nền tảng hành xử như bảo mẫu bằng giới hạn phiên và bắt buộc xác thực hai bước. Chỉ cần đặt một nút bật/tắt trong phần cài đặt là được

• Tôi từng thấy các site bỏ bước quên mật khẩu, hoặc bỏ luôn mật khẩu. Email chính là xác thực
  Cách làm là nhập địa chỉ email, nhận email chứa mã, rồi nhập mã để đăng nhập. Tôi hiểu vì sao họ làm vậy, nhưng với người dùng nhiều email thì tôi khá ghét. Tôi đã phải đưa email và ghi chú vào trình quản lý mật khẩu để nhớ nên dùng email nào, và nó nằm lại như một mục không có mật khẩu

  • Ma sát khi dùng magic link lớn đến mức tôi từng không chi tiền cho những website như vậy và đi tìm lựa chọn thay thế
    Tôi nghĩ nếu họ còn không làm được hệ thống đăng nhập tử tế thì khả năng cao là họ cũng thiếu năng lực cung cấp các chức năng đã hứa. Magic link giờ không chỉ là phiền toái nữa mà đã trở thành một bộ lọc
  • Chúng tôi dùng cách này trong B2B SaaS. Người dùng cá nhân có khi 6 tháng mới đăng nhập một, hai lần, nên đăng nhập không mật khẩu có lợi
    Không có gánh nặng phải nhớ mật khẩu cho một dịch vụ không dùng thường xuyên, và onboarding trong công ty cũng dễ hơn. Công ty tải lên CSV người dùng, rồi người dùng có thể bắt đầu làm việc ngay mà không phải tạo mật khẩu, xác nhận và đáp ứng quy tắc. Tôi không thích liên kết email, vì phần xem trước của app điện thoại hoặc trình quét virus doanh nghiệp có thể “nhấp” vào liên kết
  • Một tỷ lệ đáng kể người tiêu dùng không chuyên về kỹ thuật sẽ không dùng trình quản lý mật khẩu. Nếu chỉ cung cấp đăng ký bằng mật khẩu mà không cung cấp magic link hoặc mã, tức là đang khiến cuộc sống của đa số người tiêu dùng khó khăn hơn
    Ngay cả khi cung cấp cả hai, nếu vừa yêu cầu mật khẩu vừa bắt xác nhận email, tôi nghĩ luồng đăng ký sẽ rơi rụng nhiều hơn. Hơn nữa, không phải xử lý cả mật khẩu lẫn nhiều luồng đăng nhập email nên code cũng đơn giản hơn nhiều
  • Một site “đăng nhập khách” để đổi voucher từng cung cấp cách này, và tôi nghĩ đó là use case hợp lệ cho những người có thể không muốn tạo tài khoản
    Vì voucher phải gắn với email, họ cần xác nhận quyền sở hữu bằng cách nhấp liên kết để phòng khi sau này phát sinh vấn đề hỗ trợ do mất voucher. Sau đó nếu tạo tài khoản thì cũng có thể xem các voucher đã nhận trước đây
  • Điều đó có nghĩa là site không lưu mật khẩu của tôi, nên có ít thứ phải lo hơn

• Chỉ sau khi đọc bài này tôi mới nhận ra mình đang dùng đúng cách này ở Best Buy
  Không phải cố ý. Vì mật khẩu được lưu trong 1Password nên tôi biết là đúng, nhưng mỗi lần định mua gì đó trên bestbuy.com thì lại có một cơ chế chống chiếm đoạt tài khoản nào đó chặn lại và nói dối rằng mật khẩu sai. Tôi hoàn toàn có thể tin rằng vấn đề nằm ở phía mình. Có thể là trình chặn quảng cáo hoặc chặn DNS cục bộ. Nhưng sau vài lần lặp lại, tôi mất hết động lực debug và chỉ đi theo con đường ít trở ngại nhất

  • Có khi nào là do không khớp độ dài tối đa không? Trường đổi mật khẩu và trang đăng nhập có maxlength khác nhau là chuyện rất phổ biến
    Ví dụ khi đổi mật khẩu bạn nhập mật khẩu 60 ký tự, nhưng trang đăng nhập có độ dài tối đa 40 ký tự, thì lúc đăng nhập sẽ thành “mật khẩu sai”. Vì vậy giờ tôi dùng chính sách lưu độ dài tối đa trong cấu hình ứng dụng để truyền xuống mọi trường mật khẩu. Kiểm tra thử thì thực sự có sự không khớp về độ dài. Form đặt mật khẩu có maxlength là 54, còn trang đăng nhập thì không có maxlength. Do đó nếu mật khẩu dài hơn 54 ký tự và 1Password không tự động cắt mật khẩu đã lưu xuống còn tối đa 54 ký tự, thì bạn sẽ không thể đăng nhập

• Với đa số mọi người, thao tác trên máy tính là thử đi thử lại một cách thô bạo cho đến khi đại khái chạy được. Phần mềm được tạo ra bởi những người hiểu chi tiết các hệ thống bên dưới, nhưng lại được làm cho những người không có sự hiểu biết đó
  Khi người dùng tìm thấy một mẫu thao tác chạy được một lần, họ sẽ ở lại với nó. Giờ nhiều trường học dùng máy tính bảng trong giáo dục nên xu hướng này còn tăng lên. Họ không nắm được cảm giác về cách máy tính hoạt động. Đa số không suy nghĩ sâu. Nó cứ ở đó, và vì họ đã quen với những thứ vốn hỏng sẵn, thêm vài cú nhấp chuột thì có gì to tát đâu

  • Trong số lập trình viên phần mềm, có lẽ chỉ khoảng 10% thực sự hiểu sâu việc mình đang làm. Ngược lại, chính vì các lập trình viên không hiểu đúng những gì mình làm nên người bình thường mới phải dùng phần mềm tệ hại bằng cách thử đi thử lại cho đến khi tạm được

• Nói phóng đại thì luồng đăng nhập là giống nhau
  A) Vào website, dùng trình quản lý mật khẩu để sao chép và dán một chuỗi ngẫu nhiên, rồi nhận yêu cầu TOTP qua email để xác minh danh tính. Hoặc B) vào website, bấm quên mật khẩu, nhận liên kết đăng nhập rồi nhập một chuỗi ngẫu nhiên. Trong nhiều trường hợp B thực sự nhanh hơn, và hầu như cũng không chậm hơn. Ô “ghi nhớ” chẳng có tác dụng gì

  • Ai lại sao chép rồi dán từ trình quản lý mật khẩu chứ?
    Tôi nghĩ luồng của mình tốt hơn cả hai. Vào trang web thì Safari đề xuất tự động điền, dùng TouchID/FaceID, rồi được yêu cầu mã bước hai. Nếu mã đến qua SMS hoặc email thì Safari đề xuất tự động điền. Ngay cả với TOTP, Safari cũng tự động điền. Rất dễ. Passkey còn dễ hơn vì không có bước thứ hai và không phải chờ SMS/email
  • TOTP không phải là thứ được gửi qua email. Điểm cốt lõi của TOTP là có thể tự tạo mã xác thực từ thời gian hiện tại và một bí mật đã chia sẻ trước
  • Nếu có greylisting, luồng B có thể mất khoảng 10 phút
  • Cách B có thể thực hiện ở bất cứ đâu có thể truy cập email, và không phụ thuộc vào việc ứng dụng hay điện thoại có nằm trong tay tôi hay không
  • Chẳng phải trình duyệt có nhớ mật khẩu sao?

• Động cơ thì hiểu ngay. Dùng “quên mật khẩu” thì không cần nhớ mật khẩu. Và bảo mật tài khoản cũng không yếu đi. Dù sao thì con đường đó vốn đã mở cho kẻ tấn công rồi
  Một số website lấy đây làm luồng mặc định, ngầm khẳng định rằng nếu có thể gửi nút đăng nhập cho ai đó qua email thì bản thân mật khẩu là vô nghĩa. Cá nhân tôi không thích. Tôi không tin email, và cũng không thích việc nó trở thành điểm lỗi đơn của hàng chục tài khoản. Nếu chỉ dùng yếu tố thứ hai mà đăng nhập được thì đó không phải xác thực hai bước. Tôi muốn đăng nhập bằng mật khẩu mà không có tùy chọn đặt lại, nhưng thực tế không như vậy

  • Nếu bảo vệ email bằng xác thực hai bước thì nó lại trở thành xác thực hai bước