Đặt mật khẩu trong cuộc gọi API REST

Giả sử tôi có API REST cũng được sử dụng để đặt / đặt lại mật khẩu. Chúng ta cũng giả sử rằng điều này hoạt động trên các kết nối HTTPS. Có lý do chính đáng nào để không đặt mật khẩu đó vào đường dẫn cuộc gọi không, hãy nói rằng tôi sẽ mã hóa nó trong BASE64?

Một ví dụ sẽ là đặt lại mật khẩu như thế này:

http://www.example.com/user/joe/resetpassword/OLDPASSWD/NEWPASSWD

Tôi hiểu BASE64 không có mã hóa, nhưng tôi chỉ muốn bảo vệ mật khẩu để lướt vai trong trường hợp này.

Một máy chủ tốt sẽ ghi lại tất cả các yêu cầu được gửi tới nó, bao gồm URL (thường, không có phần biến sau '?'), IP nguồn, thời gian thực hiện ... Bạn có thực sự muốn nhật ký này (có khả năng được đọc bởi một nhóm quản trị viên) thông tin cực kỳ an toàn như mật khẩu? Base64 không phải là một nút chặn đối với họ.

Những gì bạn đang đề xuất là không an toàn cũng không phải RESTful.

@Netch đã đề cập đến vấn đề với nhật ký, nhưng cũng có một vấn đề khác là bạn đang hiển thị mật khẩu được gửi bởi HTTP, khiến việc nắm bắt mật khẩu với bất kỳ loại tấn công sniffer hoặc trung gian nào cũng không đáng kể.

Khi bạn thực hiện một yêu cầu GET bằng REST, các yếu tố khác nhau trong URL đại diện cho các yếu tố hạt mịn hơn. URL của bạn đọc giống như bạn đang trả về một phần NEWPASSWD của OLDPASSWD, đó là một phần của mật khẩu đặt lại. Điều đó không làm cho bất kỳ ý nghĩa ngữ nghĩa. GET không nên được sử dụng để lưu dữ liệu.

Bạn nên làm một cái gì đó như thế này:

POST https://www.example.com/user/joe/resetpassword/
{oldpasswd:[data], newpasswd:[data]}

POST vì bạn đang viết dữ liệu và https vì bạn không muốn nó đánh hơi.

(Đây thực sự là bảo mật thanh thấp. Tối thiểu tuyệt đối bạn nên làm.)

Đề án đề xuất có vấn đề trong một số lĩnh vực.

Bảo vệ

Đường dẫn URL thường xuyên được ghi lại; Đặt mật khẩu chưa xóa trong đường dẫn là thực hành kém.

HTTP

Thông tin xác thực / ủy quyền sẽ xuất hiện trong tiêu đề Ủy quyền. Hoặc có khả năng, đối với các công cụ dựa trên trình duyệt, tiêu đề Cookie.

NGHỈ NGƠI

Các động từ như resetpasswordtrong URL của bạn nói chung là một dấu hiệu rõ ràng của mô hình chuyển trạng thái không đại diện. Một URL nên đại diện cho một tài nguyên. Có nghĩa là gì để NHẬN resetpassword? Hoặc XÓA?

API

Đề án này yêu cầu luôn luôn biết mật khẩu trước đó. Bạn có thể sẽ muốn cho phép nhiều trường hợp hơn; ví dụ mật khẩu bị mất

Bạn có thể sử dụng xác thực Cơ bản hoặc Tiêu hóa , đó là các sơ đồ được hiểu rõ.

PUT /user/joe/password HTTP/1.0
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Content-Type: text/plain
Host: www.example.com

NEWPASSWD

Nó không đưa thông tin cực kỳ nhạy cảm vào đường dẫn và nó tuân theo các quy ước HTTP và REST.

Nếu bạn cần cho phép một số chế độ ủy quyền khác (ví dụ: một số mã thông báo được gửi qua kênh được xác minh để đặt lại mật khẩu), bạn chỉ cần sử dụng tiêu đề Ủy quyền khác mà không phải thay đổi bất kỳ điều gì khác.

Ngoài bảo mật, vấn đề với điều này là nó không phải là một cách tiếp cận rất RESTful.

OLDPASSWDvà NEWPASSWDkhông đại diện cho bất cứ điều gì trong hệ thống phân cấp tài nguyên của bạn và thậm chí tệ hơn, hoạt động không phải là bình thường.

Vì vậy, bạn chỉ có thể sử dụng POSTlàm động từ của mình và bạn không nên bao gồm hai mật khẩu trong đường dẫn tài nguyên của mình.

Vấn đề là để tránh mật khẩu văn bản đơn giản trong yêu cầu của bạn. Có hai tùy chọn để đáp ứng các yêu cầu dịch vụ web yên tĩnh.

1. Băm phía khách hàng

• Tôi đoán bạn đang lưu trữ mật khẩu của mình, ví dụ như hàm băm (mật khẩu + muối)
• Bạn có thể băm mật khẩu mới với một muối ở phía máy khách
• Điều đó có nghĩa là: Tạo một muối mới ở phía máy khách, tạo hàm băm, ví dụ: hàm băm (newPassword + newSalt)
• Gửi hàm băm mới tạo cộng với muối vào dịch vụ web yên tĩnh của bạn
• Gửi mật khẩu cũ cũng dưới dạng băm (oldPassword + oldSalt)

2. Mã hóa

• Tạo tài nguyên "khóa một lần" (otk) cho người dùng như / otk / john
• Tài nguyên này trả về khóa một lần duy nhất ngẫu nhiên an toàn, ví dụ: kbDlJbmNmQ0Y0SmRHZC9GaWtRMW0ycVJpYzhMcVNZTWlMUXN6ZWxLdTZESFRs và ID duy nhất, ví dụ: 9561515
• Dịch vụ web yên tĩnh của bạn phải lưu trữ otk ngẫu nhiên này để liên lạc an toàn tiếp theo với ID 95636115125
• Mã hóa mật khẩu mới và cũ của bạn bằng otk, ví dụ AES (vì lý do bảo mật, bạn nên sử dụng hai otks riêng cho mật khẩu cũ và mới)
• Gửi mật khẩu được mã hóa đến tài nguyên mật khẩu thay đổi của bạn với ID 95636115125
• Một kết hợp otk và ID chỉ được phép hoạt động một lần, vì vậy bạn phải xóa kết hợp đó sau khi nhập mật khẩu
• Tùy chọn tốt hơn có thể: Gửi mật khẩu hiện tại / cũ bằng Basic-Auth.

Lưu ý: HTTPS là bắt buộc cho cả hai tùy chọn!

Các tính năng của một hoạt động thiết lập lại mật khẩu là gì?

1. Nó thay đổi một cái gì đó.
2. Có một giá trị mà nó được đặt thành.
3. Chỉ một số người được phép làm điều đó (người dùng, quản trị viên hoặc có thể với các quy tắc khác nhau về cách có thể làm như vậy).

Điểm 1 ở đây có nghĩa là bạn không thể sử dụng GET, bạn phải POST một cái gì đó đại diện cho hoạt động thay đổi mật khẩu thành URI đại diện cho tài nguyên xử lý các thay đổi mật khẩu hoặc PUT một cái gì đó thể hiện mật khẩu mới cho URI đại diện cho mật khẩu hoặc đại diện cho một cái gì đó (ví dụ: người dùng) trong đó mật khẩu là một tính năng.

Nói chung, chúng tôi sẽ ĐĂNG, không chỉ vì nó có thể gây khó xử khi PUT một cái gì đó mà sau này chúng tôi không thể NHẬN được và tất nhiên chúng tôi không thể NHẬN mật khẩu.

Do đó, Điểm 2 sẽ là dữ liệu đại diện cho mật khẩu mới, trong những gì được POST.

Điểm 3 có nghĩa là chúng tôi sẽ cần phải ủy quyền cho yêu cầu, điều đó có nghĩa là nếu người dùng là người dùng hiện tại, chúng tôi sẽ cần chứng minh mật khẩu hiện tại cho chúng tôi (mặc dù không nhất thiết phải nhận mật khẩu hiện tại, ví dụ như thử thách dựa trên hàm băm đã được sử dụng để chứng minh kiến ​​thức về nó mà không gửi nó).

Do đó, URI phải là một cái gì đó như <http://example.net/changeCurrentUserPassword>hoặc <http://example.net/users/joe/changePassword>.

Chúng tôi có thể quyết định rằng chúng tôi muốn nhận mật khẩu hiện tại trong dữ liệu POST cũng như trong cơ chế ủy quyền chung đang được sử dụng.