Ghi chú:
Rất nhiều người dường như nhầm lẫn một URL "riêng tư" với xác thực. Ngoài ra, dường như có một số nhầm lẫn rằng việc gửi liên kết thông qua một thực thể đáng tin cậy là một nỗ lực xác thực hai yếu tố. Để rõ ràng, chúng ta đang nói về một tài nguyên có thể truy cập công khai, mặc dù tài nguyên đó đủ khó đoán.
Khi sử dụng URL riêng tư, bạn phải luôn cho rằng nó có thể bị xâm phạm - bạn nên thiết kế một URL như vậy để ngay cả khi nó bị xâm phạm, tài nguyên sẽ không rò rỉ thông tin cho kẻ tấn công.
URL riêng tư / khó đoán không tương đương với xác thực dựa trên mật khẩu. Về bản chất, các URL riêng tư hoàn toàn không riêng tư - chúng là các tài nguyên có thể truy cập công khai. Tôi nghĩ rằng thuật ngữ URL "riêng tư" là một cách viết sai, thay vào đó chúng là các URL "tối nghĩa".
Có một số trường hợp nhất định khi sử dụng URL "riêng tư" có thể được chấp nhận, nhưng chúng vốn kém an toàn hơn các phương thức xác thực truyền thống như xác thực mật khẩu hoặc xác thực dựa trên khóa.
Một số địa điểm tôi thường thấy URL "riêng tư" được sử dụng là:
- Mật khẩu đặt lại email
- Email tạo chứng chỉ
- Email xác nhận tài khoản / email
- Cung cấp nội dung đã mua (sách điện tử, v.v.)
- Những thứ linh tinh khác như làm thủ tục chuyến bay, in thẻ lên máy bay, sử dụng URL riêng ngoài xác thực truyền thống
Điểm chung ở đây là các URL ngẫu nhiên thường chỉ tốt cho các thao tác một lần. Ngoài ra, xác thực truyền thống và URL ngẫu nhiên không loại trừ lẫn nhau - thực sự, chúng có thể được sử dụng kết hợp với nhau để cung cấp bảo mật bổ sung khi phân phối tài nguyên.
Như Robert Harvey đã chỉ ra, cách duy nhất để sử dụng URL ngẫu nhiên / riêng tư một cách an toàn là tạo trang động và gửi URL cho người dùng theo cách mà người dùng có thể được coi là bán xác thực. Đây có thể là email, SMS, v.v.
Một URL riêng / được tạo ngẫu nhiên thường có một vài thuộc tính:
- Nó sẽ hết hạn sau một khoảng thời gian hợp lý
- Nó phải là một URL sử dụng một lần: IE nó sẽ hết hạn sau lần truy cập đầu tiên.
- Nó nên trì hoãn xác thực người dùng với một số thực thể khác mà họ tin tưởng để xác thực an toàn cho người dùng. (Bằng cách gửi liên kết qua email hoặc SMS, v.v.)
- Một máy tính hiện đại không thể buộc URL trong khung thời gian trước khi hết hạn - bằng cách giới hạn tốc độ API làm lộ tài nguyên hoặc bằng cách tạo một điểm cuối url với đủ entropy sao cho không thể đoán được.
- Nó không nên rò rỉ thông tin về người dùng. IE: Nếu trang là để đặt lại mật khẩu: trang sẽ không hiển thị thông tin tài khoản người yêu cầu. Nếu Alice yêu cầu một liên kết đặt lại mật khẩu và Bob bằng cách nào đó đoán URL, Bob sẽ không có cách nào để biết mật khẩu mà anh ta đang đặt lại.
- Nếu nó rò rỉ thông tin về người dùng, thì nó nên được sử dụng trên đầu xác thực truyền thống, ví dụ, một trang có thể xem xét người dùng được xác thực nếu họ có bộ cookie hoặc nếu session_id của họ vẫn hợp lệ.
Tài nguyên khác nhau đòi hỏi mức độ bảo mật khác nhau. Ví dụ, nếu bạn muốn chia sẻ một công thức bí mật với một số bạn bè, có thể chấp nhận sử dụng URL ngẫu nhiên / riêng tư để chia sẻ nó với họ. Tuy nhiên, nếu tài nguyên có thể được sử dụng để đánh cắp danh tính của ai đó hoặc xâm phạm tài khoản của họ với các nhà cung cấp dịch vụ khác, bạn có thể quan tâm nhiều hơn đến việc hạn chế quyền truy cập vào tài nguyên đó.