Tạo xác thực mã hóa an toàn mã thông báo

Question

Bối cảnh:

Đây thực sự là một thực hành tốt nhất chung câu hỏi, nhưng một số cơ bản về tình hình cụ thể có thể hữu ích:

Chúng tôi đang phát triển một ứng dụng "kết nối" cho Iphone. Nó sẽ liên lạc với ứng dụng phụ trợ thông qua các dịch vụ REST. Để không phải nhắc người dùng nhập tên người dùng và mật khẩu mỗi khi họ khởi chạy ứng dụng, chúng tôi sẽ hiển thị dịch vụ "Đăng nhập" xác thực tên người dùng và mật khẩu của họ khi khởi chạy ban đầu và trả về mã thông báo xác thực có thể được sử dụng cho trang web sau này yêu cầu dịch vụ cho dữ liệu thực. Mã thông báo có thể có thời gian hết hạn sau đó chúng tôi sẽ yêu cầu họ xác thực lại bằng tên người dùng/mật khẩu của họ.

Các Câu hỏi:

gì đang thực tiễn tốt nhất để tạo ra loại này của thẻ được sử dụng để xác thực?

Ví dụ, chúng ta có thể ...

• Hash (SHA-256, vv) một chuỗi ngẫu nhiên và lưu nó trong cơ sở dữ liệu cho người sử dụng được cùng với ngày hết hạn. Thực hiện tra cứu đơn giản mã thông báo trên các yêu cầu tiếp theo để đảm bảo mã thông báo khớp với yêu cầu tiếp theo.
• Mã hóa id người dùng và một số thông tin bổ sung (dấu thời gian, v.v ...) bằng khóa bí mật. Giải mã mã thông báo trên các yêu cầu tiếp theo để đảm bảo mã thông báo được phát hành bởi chúng tôi.

Điều này có vẻ như nó phải là một vấn đề được giải quyết.

Answer 1

Dựa trên những phản hồi từ các câu trả lời khác cho câu hỏi này, nghiên cứu bổ sung, và ẩn các cuộc thảo luận, đây là những gì chúng tôi đã kết thúc làm ...

Nó được chỉ ra khá nhanh chóng rằng mô hình tương tác ở đây là chủ yếu chính xác giống như mô hình được sử dụng bởi Xác thực biểu mẫu trong ASP.NET khi hộp kiểm "nhớ tôi" được chọn. Nó không chỉ là một trình duyệt web thực hiện các yêu cầu HTTP. "Vé" của chúng tôi là tương đương với cookie mà bộ Mẫu xác thực. Xác thực biểu mẫu sử dụng về cơ bản là phương pháp "mã hóa một số dữ liệu với khóa bí mật" theo mặc định.

Trong dịch vụ web đăng nhập của chúng tôi, chúng tôi sử dụng mã này để tạo ra một vé:

string[] userData = new string[4]; 

// fill the userData array with the information we need for subsequent requests 
userData[0] = ...; // data we need 
userData[1] = ...; // other data, etc 

// create a Forms Auth ticket with the username and the user data. 
FormsAuthenticationTicket formsTicket = new FormsAuthenticationTicket(
    1, 
    username, 
    DateTime.Now, 
    DateTime.Now.AddMinutes(DefaultTimeout), 
    true, 
    string.Join(UserDataDelimiter, userData) 
    ); 

// encrypt the ticket 
string encryptedTicket = FormsAuthentication.Encrypt(formsTicket); 

Sau đó, chúng tôi có một thuộc tính hành vi hoạt động cho các dịch vụ WCF có thể thêm một IParameterInspector để kiểm tra cho một vé hợp lệ trong HTTP tiêu đề cho yêu cầu. Các nhà phát triển đặt thuộc tính hành vi hoạt động này vào các hoạt động yêu cầu xác thực.Sau đây là cách mã mà phân tích các vé:

// get the Forms Auth ticket object back from the encrypted Ticket 
FormsAuthenticationTicket formsTicket = FormsAuthentication.Decrypt(encryptedTicket); 

// split the user data back apart 
string[] userData = formsTicket.UserData.Split(new string[] { UserDataDelimiter }, StringSplitOptions.None); 

// verify that the username in the ticket matches the username that was sent with the request 
if (formsTicket.Name == expectedUsername) 
{ 
    // ticket is valid 
    ... 
} 

Answer 2

Điều này nghe có vẻ giống như số nhận dạng phiên với thời gian hết hạn dài. Các nguyên tắc tương tự được sử dụng cho điều này trong các ứng dụng web có thể áp dụng ở đây.

Thay vì mã hóa thông tin, số nhận dạng phiên được chọn ngẫu nhiên từ một không gian rất lớn (128 bit). Máy chủ giữ một bản ghi liên kết mã định danh phiên với người dùng và các thông tin mong muốn khác như thời gian hết hạn. Khách hàng trình bày mã định danh phiên trên một kênh bảo mật với mỗi yêu cầu.

Bảo mật dựa trên tính không thể đoán trước của số nhận dạng phiên. Tạo chúng với một RNG mật mã, từ một không gian rất lớn.

Answer 3

Xây dựng hệ thống xác thực của riêng bạn luôn là "thực hành tồi tệ nhất". Đó là loại điều tốt nhất còn lại cho các chuyên gia chuyên về các hệ thống xác thực.

Nếu bạn muốn xây dựng kiến ​​trúc "vé hết hạn từ dịch vụ đăng nhập" của riêng mình thay vì sử dụng lại kiến ​​trúc hiện tại, có thể bạn nên ít nhất làm quen với các vấn đề thúc đẩy thiết kế tương tự hệ thống, như Kerberos. Một giới thiệu nhẹ nhàng là ở đây:

http://web.mit.edu/kerberos/dialogue.html

Nó cũng sẽ là một ý tưởng tốt để có một cái nhìn vào những gì lỗ hổng bảo mật đã được tìm thấy trong Kerberos (và các hệ thống tương tự) trong vòng 20 năm trở lại đây và chắc chắn rằng bạn don không sao chép chúng.Kerberos được xây dựng bởi các chuyên gia an ninh và xem xét kỹ lưỡng trong nhiều thập kỷ, và vẫn còn lỗ hổng thuật toán nghiêm trọng đang được tìm thấy trong nó, như thế này:

http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2003-004-krb4.txt

Đó là tốt hơn rất nhiều để học hỏi từ những sai lầm của họ hơn là của riêng bạn.

Answer 4

Amazon.com sử dụng số HMAC SHA-1 message token để xác thực và ủy quyền yêu cầu. Họ sử dụng điều này cho một dịch vụ thương mại khá lớn, vì vậy tôi phải chịu trách nhiệm tin tưởng các quyết định kỹ thuật của họ. Google xuất bản các OpenSocial API mà là hơi tương tự. Dựa trên Google và Amazon.com sử dụng các cách tiếp cận tương tự và công khai được công bố để bảo mật các yêu cầu web, tôi nghi ngờ đây có lẽ là những cách tốt để đi.

Answer 5

Vì bạn đang sử dụng WCF, bạn có một loạt các lựa chọn nếu sử dụng CFNetwork - ví dụ NTLM hoặc Digest Authentication:

http://developer.apple.com/documentation/Networking/Conceptual/CFNetwork/Concepts/Concepts.html#//apple_ref/doc/uid/TP30001132-CH4-SW7

Tôi biết điều này không trả lời câu hỏi cụ thể của bạn, nhưng Tôi cũng đã phải đối mặt với vấn đề này (iPhone - Tomcat) và quyết định sử dụng các dịch vụ xác thực trên máy chủ web càng nhiều càng tốt. Không có hình phạt đáng kể cho việc bao gồm thông tin xác thực với mỗi yêu cầu trong hầu hết các trường hợp. Google nhanh chóng đăng tải nhiều bài đăng trên blog về các dịch vụ WCF và RESTful (và một số câu hỏi có liên quan trên StackOverflow).

Hy vọng điều này sẽ hữu ích!

Answer 6

Một trong hai câu trả lời bạn đã cung cấp sẽ là đủ. Bạn có thể tìm thấy các khuôn khổ ngoài kia để làm điều này cho bạn, nhưng sự thật là nó không khó để xây dựng. (Mỗi công ty tôi đã làm việc cho đã cuộn riêng của họ.) Việc lựa chọn mã thông báo được lưu trữ cơ sở dữ liệu được mã hóa "cookies" là một quyết định kiến ​​trúc - bạn có muốn tìm kiếm cơ sở dữ liệu trên mỗi lần xem trang hay không nhai CPU với giải mã cookie? Trong hầu hết các ứng dụng, việc sử dụng cookie được mã hóa sẽ mang lại hiệu suất chiến thắng trên quy mô lớn (nếu đó là mối quan ngại). Nếu không thì đó chỉ là vấn đề về hương vị.

Answer 7

Bạn nên thực hiện:

1. OAuth2 Implicit Grant - cho các ứng dụng của bên thứ ba http://tools.ietf.org/html/rfc6749#section-1.3.2
2. OAuth2 Resource Chủ Credentials Mật khẩu - cho các ứng dụng điện thoại di động của riêng bạn http://tools.ietf.org/html/rfc6749#section-1.3.3

chính xác là quy trình công việc, từ OAuth2, mà bạn đang tìm kiếm. Đừng sáng tạo lại bánh xe.