FormsAuthentication: Có an toàn không?

Question

Sử dụng FormsAuthentication xây dựng vào asp.net nó rất nhanh chóng và dễ dàng để tạo ra một hệ thống đăng nhập mà tạo ra một cookie cho người dùng xác thực:

FormsAuthentication.SetAuthCookie(uniqueUsername, false); 

ghép với một số mã trong Web.Config tập tin :

<authentication mode="Forms"> 
    <forms loginUrl="Login.aspx" timeout="30" defaultUrl="Dashboard.aspx" protection="All" /> 
</authentication> 
<authorization> 
    <deny users="?" /> 
</authorization> 

này sẽ bị trả tất cả các yêu cầu về Login.aspx đến khi người dùng được phê duyệt và cookie được tạo bằng cách sử dụng cuộc gọi phương thức SetAuthCookie().

Tính năng này có đủ an toàn không?
Quy tắc chung mà tôi sử dụng là tôi không lưu trữ bất kỳ dữ liệu nào trên máy khách mà họ đã không gửi cho tôi. Vì vậy, những gì tôi đã làm trong quá khứ là giữ tên người dùng và mật khẩu được sử dụng trong một cookie, sau đó xác thực lại điều này với mọi yêu cầu.

Có thêm chi phí để xác thực lại mọi lúc bằng phương pháp này, nhưng điều đó cũng có nghĩa là tôi không lưu trữ bất kỳ dữ liệu máy chủ nào trên máy khách.

lo lắng của tôi
mối quan tâm của tôi là bằng SetAuthCookie() gọi phương pháp, mà tên người dùng được lưu trữ trên máy client. Là nó sau đó có thể cho một ai đó để phá vỡ mã hóa đang được sử dụng và thay thế tên người dùng được lưu trữ cho người khác?

Tôi nghĩ mình quá hoang tưởng và loại và mức độ mã hóa đang được sử dụng là đủ, nhưng tôi nghĩ tôi sẽ có được một số chuyên gia đầu vào về chủ đề này.

Answer 1

Vì vậy, những gì tôi đã làm trong quá khứ là giữ tên người dùng và mật khẩu được sử dụng trong một cookie, sau đó tái xác thực điều này với mọi yêu cầu.

Bạn nên không sử dụng phương pháp này. Mật khẩu nên không được lưu trữ trong một vé xác thực. Lý do là nếu vé xác thực bị xâm phạm thì kẻ tấn công có mật khẩu của người dùng.Nguy cơ này có thể được giảm thiểu bằng cách mã hóa cookie vé xác thực, nhưng tôi cho rằng bạn đã lưu trữ cookie ở dạng văn bản thuần túy.

Mối quan tâm của tôi là bằng cách sử dụng cuộc gọi phương thức SetAuthCookie(), tên người dùng đó đang được lưu trữ trên máy khách. Là nó sau đó có thể cho một ai đó để phá vỡ mã hóa đang được sử dụng và thay thế tên người dùng được lưu trữ cho người khác?

Như Shiraz đã lưu ý, cookie chỉ được lưu trên máy khách nếu bạn tạo cookie liên tục. (Một trong các tham số để SetAuthCookie cho biết có tạo cookie như vậy hay không)

Ngay cả khi ai đó đã phá vỡ lược đồ mã hóa để sửa đổi cookie để cung cấp tên người dùng khác mà họ gặp phải sự cố. đã ký, nghĩa là ASP.NET có thể phát hiện nếu nội dung của cookie đã được sửa đổi. Để giả mạo chữ ký số, kẻ tấn công sẽ cần biết muối được máy chủ sử dụng và nếu người dùng có thể hiểu được điều đó, điều đó ngụ ý rằng anh ta có quyền truy cập vào

Một điều cần hiểu là vé xác thực đã hết hạn, đặt một thời hạn hữu hạn về tính hợp lệ của vé. Vì vậy, ngay cả khi có ai đó ăn cắp của người dùng cookie, thời gian kẻ tấn công sẽ phải sử dụng vé bị đánh cắp đó sẽ bị giới hạn dựa trên giá trị timeout mà bạn chỉ định cho hệ thống xác thực biểu mẫu (30 phút theo mặc định).

Tóm lại, hệ thống xác thực mẫu ASP.NET chính thức sẽ an toàn hơn nhiều so với thứ mà một nhà phát triển duy nhất có thể thực hiện. Nhà phát triển nên cố gắng sử dụng hệ thống xác thực mẫu thay vì cuộn giải pháp của riêng họ vì vô số lý do, bao gồm bảo mật tốt hơn, không phải phát minh lại bánh xe, áp dụng các thực hành tiêu chuẩn để các nhà phát triển khác tham gia nhóm không có học tập lớn đường cong để tăng tốc, v.v.

Để biết thêm chi tiết về gritty về hệ thống xác thực biểu mẫu và cách bảo mật vé, cách cài đặt cấu hình <forms> khác nhau, v.v., xem: Forms Authentication Configuration and Advanced Topics.

Answer 2

Nếu bạn đặt thuộc tính DisplayRememberMe thành sai, cookie sẽ không được lưu lại trên máy khách. Sau đó nó sẽ được lưu trữ trong bộ nhớ.

Nếu bạn sử dụng HTTPS/SSL, nó sẽ được bảo vệ trên đường đến máy khách.

Có thì chỉ có khả năng lý thuyết trái:

• Phá vỡ các mã hóa SSL
• Steal cookie từ bộ nhớ của máy client

Tiếp theo bằng cách phá vỡ các mã hóa trên cookie.

Có thể có một số cách dễ dàng hơn để tấn công hệ thống của bạn.

http://msdn.microsoft.com/en-us/library/ms998310.aspx

Answer 3

Chỉ cần một số báo cáo ngẫu nhiên về quá trình suy nghĩ của bạn, nhưng liên quan đến

Vì vậy, những gì tôi đã làm trong quá khứ là giữ tên người dùng và mật khẩu được sử dụng trong một cookie , sau đó tái xác thực này với mọi yêu cầu.

@Scott Mitchell đã đưa ra điều này và thảo luận lý do để không thực hiện điều này do những tác động bảo mật của điều này.

Tôi cảm thấy nó sẽ là giá trị chỉ ra lý do tại sao điều này sẽ không có ý nghĩa (thậm chí bỏ qua các tác động an ninh của thông tin rò rỉ). Lý do bạn tạo ra một vé xác thực biểu mẫu (cookie) là bạn cho phép ASP.NET đóng dấu trình duyệt người dùng này với vé đó cho phép bạn thừa nhận đây là người dùng được chỉ định đã được xác thực.

Bằng cách cấp cho họ vé mà bạn đang thực hiện để ngụ ý rằng họ không cần phải được xác thực như trước đây.

Tương tự tốt với điều này là bạn goto một thanh, trên con đường của bạn trong bạn nhận được id của bạn quét bởi bouncer để đảm bảo id của bạn là hợp pháp và rằng bạn trên 21. Sau khi xác nhận điều này, họ cung cấp cho bạn một ban nhạc cổ tay là một màu sắc/thiết kế nhất định.

Với ban nhạc cổ tay, bạn có thể rời khỏi tòa nhà để hút thuốc và quay trở lại bên trong việc phá vỡ đường dây và nhu cầu quét id của bạn cho phép bạn quay trở lại ngày hôm đó. Bây giờ bạn nên về nhà, nhưng không lấy dây đeo cổ tay khi bạn goto giường (như rời khỏi trình duyệt mở qua đêm) bạn trở lại quầy bar vào ngày hôm sau và cố gắng để hiển thị ban nhạc cổ tay của bạn để bỏ qua dòng. Tại thời điểm này, bạn bị từ chối bởi vì bạn có ban nhạc cổ tay đêm qua và được yêu cầu phải nhận được vào mặt sau của dòng và được ủy quyền một lần nữa.