Thiết kế xác thực cho API REST


11

Tôi đang xây dựng API cho dịch vụ REST mà tôi sẽ sản xuất và tiêu thụ. Tôi đã dành vài ngày qua để cố gắng tìm ra cách xử lý xác thực độc đáo và nghĩ rằng cuối cùng tôi đã nghĩ ra một cái gì đó.

Tôi sẽ đưa ra điều này dựa trên các sự kiện sau đây về ngăn xếp ứng dụng:

  1. Client & Server nằm trong .NET4 (Phần máy khách trong Hồ sơ khách hàng)
  2. Máy chủ hiển thị bằng WCF REST
  3. Tôi thực sự không muốn giữ tên người dùng và mật khẩu trong bộ nhớ trong ứng dụng

Từ 3, tôi muốn sử dụng một hình thức xác thực mã thông báo, để sau khi thông tin được xác thực bởi máy chủ, khách hàng sẽ nhận lại mã thông báo để sử dụng trong suốt phần còn lại của ứng dụng (điều này sẽ cho phép tôi làm những việc khác, chẳng hạn như hết thời gian người dùng, có thể di chuyển người dùng liền mạch giữa các phiên bản web và máy tính để bàn, v.v.). Sau khi tìm ra cách thực hiện các cuộc gọi phát lại và chống giả mạo, tôi đã đưa ra các cách sau:

  1. Trước khi máy khách cố gắng xác thực, nó sẽ tạo một cặp khóa Diffie-Hellman bằng cách sử dụng ECDiffieHellmanCnglớp.
  2. Nó sẽ gửi phần công khai của cặp khóa qua dây cùng với tên người dùng và mật khẩu (tất nhiên là qua HTTPS).
  3. Máy chủ xác thực kết hợp tên người dùng / mật khẩu, nếu thành công, thì nó sẽ thực hiện như sau:
    1. Tạo mã thông báo phiên duy nhất
    2. Tạo cặp khóa DH riêng và tính toán bí mật chung từ khóa chung do khách hàng cung cấp
    3. Ghi chú mã thông báo phiên, bí mật được chia sẻ, người dùng và thời gian "hành động cuối cùng" (được sử dụng cho cửa sổ hết hạn cuộn) trong cơ sở dữ liệu của nó
    4. Trả về mã thông báo phiên, khóa DH công khai của nó và thông báo thành công xác thực
  4. Khách hàng lấy khóa DH từ phản hồi, tính toán bí mật được chia sẻ và lưu trữ cả mã thông báo và bí mật trong bộ nhớ.

Từ thời điểm này, tổ hợp mã thông báo / bí mật phiên hoạt động giống như hầu hết các API REST khác, với yêu cầu được lấy dấu vân tay và dấu thời gian, và sau đó có một số loại HMAC được tạo. Bất cứ khi nào khách hàng thực hiện một hành động chống lại máy chủ, nó sẽ kiểm tra cặp mã thông báo / bí mật và cho phép hành động nếu nó hợp lệ và không hết hạn và cập nhật bản ghi hành động cuối cùng trong phiên.

Tôi không thấy bất kỳ sai sót rõ ràng nào, và có lẽ được thiết kế quá mức cho việc này, nhưng tôi cần học cách làm điều này vào một lúc nào đó. HMAC ngăn chặn các cuộc tấn công phát lại, đàm phán DH giúp ngăn chặn các cuộc tấn công MITM (Tôi không thể nghĩ về một cuộc tấn công khả thi ngoài đỉnh đầu giữa HMAC / DH).

Bất kỳ lỗ ai cũng có thể chọc vào này?


Tôi không thấy cách tạo các khóa DH thêm bất kỳ bảo mật nào so với việc sử dụng HTTPS ở mọi nơi và sử dụng cookie phiên cũ. Khi được sử dụng đúng cách, HTTPS đã bảo vệ chống lại các cuộc tấn công giữa chừng và phát lại.
Lie Ryan

Câu trả lời:


5

Thay vì phát minh ra của riêng bạn, bạn nên xem xét việc đọc API OpenAM và mượn nó.

http://forgerock.com/openam.html

OpenAM Wiki đặc biệt hữu ích

https://wikis.forgerock.org/confluence/display/openam/Home

Bạn không cần phải sử dụng các thành phần của chúng. Nhưng nếu bạn sử dụng API của họ, bạn sẽ thấy rằng cuộc sống của bạn sẽ đơn giản hơn về lâu dài.


Hmm, nó trông không tệ, một điều khiến tôi không thể sử dụng nó trong trường hợp này: Chúng tôi là một cửa hàng .Net. Thêm vào đó, không có nhiều về việc sử dụng nó với phía máy chủ WCF. Liên kết không spam mà tôi có thể tìm thấy trên google về nó liên kết với việc sử dụng WIF và WS-Liên kết.
Matt Sieker

1
@Matt Sieker: "Bạn không cần sử dụng các thành phần của chúng". Vui lòng đọc về API của họ thay vì phát minh ra của riêng bạn.
S.Lott

Ah, tôi nghĩ rằng tôi thấy những gì bạn có ý nghĩa, các công cụ gọi lại yêu cầu. Điều đó thật thú vị, tôi có thể xem xét thêm, nếu không phải cho dự án này, cho những dự án trong tương lai. Thay vì thực hiện auth như một đoạn nguyên tử, hãy phá vỡ nó một chút, để máy chủ có thể kiểm soát những gì nó cần từ máy khách ...
Matt Sieker

Chúng tôi đã tự lăn lộn ban đầu nhưng sau đó chuyển sang OpenAM vài năm trước tại IG Group. Rất hài lòng với sản phẩm nguồn mở.
Robert Morschel

2

Tôi đồng ý 100% với @ S.Lott rằng bạn không muốn tự quay. Tôi đề nghị xem xét một giải pháp thay thế khác: Dịch vụ kiểm soát truy cập Windows Azure (ACS). ACS tốn tiền, nhưng nó rất rẻ (10.000 giao dịch với 0,01 đô la) và một cơ sở hạ tầng tốt được xử lý. WIF được tận dụng trên máy khách.

Đây cũng là một giải pháp dựa trên tiêu chuẩn / dựa trên yêu cầu - đó là tất cả các cơn thịnh nộ. Kiểm tra bài viết này về việc sử dụng WCF và REST và ACS cùng nhau .

Nếu bạn đang nghĩ về tương lai, đây cũng là một cơ chế có thể phát triển cùng với bạn - vì bạn có các ứng dụng di động bên ngoài tường lửa, đối tác, v.v. Ngay cả khi bạn không muốn sử dụng nó vì nó thêm một phụ thuộc bên ngoài tường lửa của bạn, bạn có thể muốn kiểm tra ý tưởng đó. Rất lắt léo.

Chúc may mắn! -Hóa đơn

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.