Hashing Mật khẩu Với ASP.NET MVC 3

Question

Tôi hiện đang trong quá trình cố gắng tìm ra cách tốt nhất để băm mật khẩu cho ứng dụng ASP.NET MVC 3 của tôi. Từ những gì tôi nghe được, tốt nhất là sử dụng mật khẩu đã cho và một muối ngẫu nhiên và sau đó lưu trữ mật khẩu băm và muối với nhau. Câu hỏi của tôi sẽ không làm cho muối ngẫu nhiên vô nghĩa? Ý tôi là lý do băm mật khẩu là vì nếu ai đó vào cơ sở dữ liệu của bạn, họ không có mật khẩu đơn giản và muối làm cho nó khó hơn nhiều để đảo ngược mã băm để lấy mật khẩu nhưng nếu tôi lưu trữ băm bằng mật khẩu, điểm muối là gì (kiến thức của tôi về băm là hạn chế nên tôi có thể hoàn toàn rời khỏi cơ sở với suy nghĩ của mình).

Câu hỏi thứ hai của tôi là phương pháp băm nào là phương pháp tốt nhất để sử dụng? Tôi đọc rằng MD5 (đó là những gì tôi đã luôn luôn được sử dụng) là rất đơn giản để crack. Tôi nghe bcrypt/sha512 khá tốt. Nên sử dụng cái nào? Tôi biết rằng C# theo mặc định đi kèm với băm sha512. Từ những gì tôi có thể thấy, bcrypt không được bao gồm trong thư viện .NET, có thư viện nào tốt cho C# và bcrypt không?

Answer 1

SHA512 là một lựa chọn tốt cho băm trong .net và nếu bạn lưu trữ muối bằng mật khẩu thì hơi vô nghĩa (nhưng "giải mã" vẫn cần thời gian dài hơn), nhưng bạn có thể lưu trữ muối ở đâu đó khác, vì vậy DB không phải là enought:

• cửa hàng muối chỉ ở một nơi khác
• sử dụng lúc nào cũng là muối cùng và ví dụ mã hóa nó trong mã hoặc lưu mã đó trong cài đặt ứng dụng
• tạo ra muối cho mọi người dùng từ một số thông tin khác, ví dụ: MD5 của người sử dụng-id
• tạo ra muối cho tất cả người dùng từ một số thiết lập hệ thống như hostname hoặc tương tự

UPDATE:
Như Mike đã nói tôi sai với tuyên bố "vô nghĩa" ở trên. Ngay cả khi muối được biết, nó sẽ làm cho Rainbow Table Tấn công vô ích (hoặc rất khó xảy ra), vì vậy bạn nên luôn sử dụng muối ngay cả khi lưu trữ muối ngay bên cạnh hàm băm (ví dụ: linux lưu trữ mật khẩu người dùng trong shadow file trong một dạng "$ id $ salt $ hashed")!

Answer 2

Giảm giá sẽ tăng sức đề kháng đối với cuộc tấn công từ điển/cầu vồng. Một vài khai thác bảo mật đã xảy ra trong năm nay là do cơ sở dữ liệu của ứng dụng web chứa mật khẩu không có muối và chúng được thực hiện với md5. Vì vậy, một cuộc tấn công cầu vồng đơn giản tạo ra mật khẩu trong vài giây cho một vài người dùng sử dụng mật khẩu khủng khiếp.

Để cung cấp xác thực người dùng với MVC 3, bạn thực sự nên sử dụng khung làm việc cho loại điều này. Đến với nhà cung cấp xác thực tùy chỉnh của riêng bạn có thể gây ra vấn đề nếu bạn không làm đúng.

Hãy xem http://msdn.microsoft.com/en-us/library/ff398049%28v=VS.98%29.aspx và http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx. Nếu bạn sử dụng hệ thống thành viên .NET, bạn không cần phải thực hiện bất kỳ cơ sở dữ liệu cấp thấp hoặc quản lý mật khẩu nào. Bạn chỉ cần đặt các thẻ [Ủy quyền] xung quanh các hành động của bộ điều khiển cần được xác thực và thực hiện xong.

Answer 3

Dưới đây là một tốt đẹp C# thực hiện bcrypt:

http://bcrypt.codeplex.com/

Answer 4

Tôi đã allways sử dụng các phương pháp sau đây để lưu trữ mật khẩu

public static string MD5Hash(string value) 
{ 
    return Convert.ToBase64String(new MD5CryptoServiceProvider().ComputeHash(new UTF8Encoding().GetBytes(value))); 
} 

Nó chưa bao giờ được một câu hỏi nếu có thể để khôi phục băm như vậy để mật khẩu ban đầu.

Answer 5

không cần phải lưu trữ muối ở một vị trí khác, bạn nên luôn luôn giả định muối được biết bởi kẻ tấn công và mục đích của nó không phải là mật khẩu phụ !!!!

Trong NET API này sẽ làm tất cả mọi thứ bạn cần, nó sẽ tạo ra muối lớn crypto ngẫu nhiên cũng như HMACSHA512 băm và chìa khóa kéo dài qua byte trao đổi trước mỗi AES mã hóa qua :)

http://sourceforge.net/projects/pwdtknet/

Answer 6

Nếu họ tấn công vào cơ sở dữ liệu bảo mật của bạn để ăn cắp mật khẩu băm của mọi người, sau đó không chắc họ sẽ thực sự cần mật khẩu tại thời điểm đó. Họ đã có quyền truy cập vào tất cả các dữ liệu trong cơ sở dữ liệu rất có thể. Một băm MD5 có lẽ là tốt cho các trang web trung bình nếu nó là một cái gì đó đơn giản với dữ liệu không có giá trị. Các phương pháp băm khó khăn hơn sẽ tốt cho dữ liệu có nhiều khả năng có giá trị hơn.