Nhập người dùng mà không cần đặt lại mật khẩu

Mọi hướng dẫn di chuyển danh tính rồi cũng đến cùng một đoạn văn, và nó luôn nghe có chút áy náy: "người dùng sẽ phải đặt lại mật khẩu." Người ta coi đó như một quy luật tự nhiên. Không phải vậy. Đó là một lựa chọn, thường bị ép buộc bởi một công cụ không chịu làm việc khó hơn.

Việc khó hơn là xác minh tại chỗ các hash mật khẩu hiện có của người dùng, để sau khi chuyển đổi họ đăng nhập đúng bằng thông tin xác thực họ đã có từ trước và không hề nhận ra có chuyện gì xảy ra. Bạn có làm được hay không tựu trung lại ở một câu hỏi: bạn có lấy được các hash cũ không, và hệ thống mới có xác minh được chúng không?

Hash mật khẩu dễ mang theo hơn nhiều người vẫn nghĩ

Một hash mật khẩu không phải là một thuật toán bí mật. bcrypt là bcrypt. Một hash bcrypt mang theo hệ số chi phí và salt của chính nó ngay bên trong chuỗi, nên bất cứ thứ gì triển khai bcrypt đều có thể xác minh một hash do bất kỳ hệ thống bcrypt nào khác tạo ra. Định dạng PBKDF2 mà ASP.NET Identity dùng cũng vậy: có tài liệu, có phiên bản, tự mô tả. Nếu bạn biết mình đang cầm thứ gì, bạn có thể kiểm tra một mật khẩu dựa trên nó mà không bao giờ cần biết mật khẩu là gì.

Vì thế một cuộc di chuyển giữ nguyên việc đăng nhập không cần văn bản gốc (chẳng ai có) và cũng không cần băm lại mọi người ngay từ đầu. Nó cần lấy các hash đã lưu và xác minh dựa trên chúng khi đăng nhập, lặng lẽ nâng từng cái lên định dạng riêng của nó trong lần đầu người dùng đăng nhập. Phần cuối đó chính là di chuyển kiểu lười: mang theo hash cũ, xác minh một lần, thay thế một cách trong suốt. Qua vài tuần đăng nhập bình thường, bảng người dùng của bạn tự băm lại và các định dạng cũ dần biến mất, không một lần đặt lại và không một phiếu hỗ trợ nào.

Phần hai đường song song

Điểm vướng là các nguồn khác nhau đưa cho bạn các định dạng khác nhau, và một bộ nhập tốt sẽ xác minh cả hai:

• Từ Duende / ASP.NET Identity tự lưu trữ: các hash V3 PBKDF2 (và mọi bcrypt cũ) xác minh được nguyên bản và được băm lại trong lần đăng nhập đầu tiên. Đây là trường hợp dễ, vì nó chính là cơ chế mà điểm đến vốn đã dùng. Hầu hết các đội đều ngạc nhiên vì nó gọn gàng đến vậy.
• Từ Auth0: các hash bcrypt xác minh được y nguyên. Vướng mắc không nằm ở định dạng, mà ở việc lấy được chúng.

Khi bạn thực sự không thể

Management API của Auth0 không bao giờ trả về hash mật khẩu. Đó là một chính sách có chủ đích, không phải lỗ hổng trong bộ công cụ của bất kỳ ai, và bạn nên nghi ngờ mọi quảng cáo "xuất Auth0 chỉ với một cú nhấp" tuyên bố kèm theo mật khẩu mà không cần đến nó. Con đường được hỗ trợ là một bản xuất hàng loạt có hỗ trợ từ bộ phận support: một tệp NDJSON chứa hash bcrypt của từng người dùng. Lấy được tệp đó thì các hash được nhập y nguyên, kèm cả di chuyển kiểu lười, và cuộc chuyển đổi vẫn vô hình.

Nếu không thể chờ được, phương án dự phòng là phiên bản trung thực của đoạn văn áy náy kia: người dùng đặt một mật khẩu mới trong lần đăng nhập đầu tiên. Chẳng có gì bị mất, vì vốn không có hash nào để mang theo. Khác biệt là bạn chủ động chọn điều đó, chứ không phải vì công cụ không thể làm tốt hơn.

Vì sao điều này quan trọng hơn vẻ ngoài của nó

Một lần đặt lại bắt buộc là điều dễ thấy nhất và đáng báo động nhất bạn có thể giáng xuống một cộng đồng người dùng giữa lúc di chuyển. Nó tạo ra tải hỗ trợ, nó tập cho người dùng quen với việc trông đợi một email kiểu lừa đảo "nhấp vào đây để đặt lại", và đó là khoảnh khắc một thay đổi hạ tầng âm thầm trở thành vấn đề của tất cả mọi người. Tránh được nó là phần lớn cái làm cho một cuộc di chuyển có cảm giác như chẳng có gì xảy ra, và đó chính là cảm giác mà một cuộc di chuyển nên có.

Vậy nên trước khi chấp nhận "mọi người đều đặt lại", hãy đặt hai câu hỏi kia. Với hầu hết các cuộc chuyển đổi, câu trả lời đều là có cho cả hai, và đoạn văn áy náy ấy chưa bao giờ là cần thiết.

Xem một lần nhập sẽ mang theo những gì: bản xem trước chỉ ở chế độ đọc và cho bạn thấy mọi thứ trước khi bất cứ điều gì được ghi.