Tôi đã đọc rằng khi băm mật khẩu, nhiều lập trình viên khuyên bạn nên sử dụng thuật toán BCrypt.
Tôi đang lập trình trong C # và tự hỏi liệu có ai biết triển khai tốt cho BCrypt không? Tôi tìm thấy trang này , nhưng tôi không thực sự biết nó có phải là không có thật hay không.
Tôi cần lưu ý điều gì khi chọn sơ đồ băm mật khẩu? BCrypt có phải là một triển khai 'tốt' không?
Câu trả lời:
Đầu tiên, một số thuật ngữ quan trọng:
Băm - Hành động lấy một chuỗi và tạo ra một chuỗi các ký tự không thể được hoàn nguyên về chuỗi ban đầu.
Mã hóa đối xứng - (Thường chỉ được gọi là 'mã hóa') - Hành động lấy một chuỗi và tạo ra một chuỗi các ký tự có thể được giải mã thành chuỗi gốc thông qua việc sử dụng cùng một khóa mã hóa đã mã hóa nó.
Bảng cầu vồng - một bảng tra cứu có chứa tất cả các biến thể của các ký tự được băm trong một thuật toán băm cụ thể.
Muối - một chuỗi ngẫu nhiên đã biết được nối vào chuỗi gốc trước khi nó được băm.
Đối với .NET Framework, Bcrypt chưa có triển khai tham chiếu đã được xác minh . Điều này rất quan trọng vì không có cách nào để biết liệu có những sai sót nghiêm trọng trong việc triển khai hiện có hay không. Bạn có thể nhận được một triển khai BCrypt cho .NET tại đây . Tôi không biết đủ về mật mã để nói liệu đó là một triển khai tốt hay xấu. Mật mã học là một lĩnh vực rất sâu sắc. Đừng cố gắng xây dựng thuật toán mã hóa của riêng bạn . Nghiêm túc.
Nếu bạn định thực hiện bảo mật mật khẩu của riêng mình (thở dài), thì bạn cần phải làm một số điều:
Thật không may, ngay cả khi bạn làm tất cả những điều này, một hacker quyết tâm vẫn có khả năng tìm ra mật khẩu, nó sẽ khiến anh ta mất một thời gian rất dài. Đó là kẻ thù chính của bạn: Thời gian .
Các thuật toán bcrypt làm việc vì phải mất lăm bậc độ lớn thời gian để băm mật khẩu hơn MD5 ; (và vẫn dài hơn AES hoặc SHA-512). Nó buộc tin tặc phải mất nhiều thời gian hơn để tạo một bảng cầu vồng để tra cứu mật khẩu của bạn, khiến cho khả năng mật khẩu của bạn sẽ có nguy cơ bị hack cao hơn rất nhiều.
Nếu bạn đang muối và băm mật khẩu của mình và mỗi loại muối khác nhau, thì một hacker tiềm năng sẽ phải tạo một bảng cầu vồng cho mỗi biến thể của muối , chỉ cần có một bảng cầu vồng cho một mật khẩu được băm + băm. Điều đó có nghĩa là nếu bạn có 1 triệu người dùng, một hacker phải tạo ra 1 triệu bảng cầu vồng. Nếu bạn đang sử dụng cùng một loại muối cho mọi người dùng, thì hacker chỉ phải tạo 1 bảng cầu vồng để hack thành công hệ thống của bạn.
Nếu bạn không muối mật khẩu của mình, thì tất cả kẻ tấn công phải làm là kéo lên một bảng Rainbow hiện có cho mọi triển khai ngoài đó (AES, SHA-512, MD5) và chỉ xem liệu có khớp với hàm băm không. Điều này đã được thực hiện , kẻ tấn công không cần phải tự tính toán các bảng Rainbow này .
Ngay cả với tất cả điều này, bạn đã được sử dụng các thực hành bảo mật tốt . Nếu họ có thể sử dụng thành công một vectơ tấn công khác (XSS, SQL Injection, CSRF và cộng sự ) trên trang web của bạn, bảo mật mật khẩu tốt không thành vấn đề. Nghe có vẻ như là một tuyên bố gây tranh cãi, nhưng hãy nghĩ về nó: Nếu tôi có thể lấy tất cả thông tin người dùng của bạn thông qua một cuộc tấn công SQL, hoặc tôi có thể khiến người dùng của bạn đưa cho tôi cookie của họ thông qua XSS, thì vấn đề là mật khẩu của bạn tốt đến mức nào an ninh là thế .
Các nguồn lực khác:
Lưu ý: Vui lòng giới thiệu các tài nguyên tốt khác. Tôi đã phải đọc hàng tá bài viết của hàng tá tác giả, nhưng ít người viết đơn giản về chủ đề như Jeff. Vui lòng chỉnh sửa trong các bài viết khi bạn tìm thấy chúng.
Bạn không được sử dụng BCrypt trong .NET. Bạn phải sử dụng PBKDF2 như với triển khai .NET framework tích hợp. Đây là triển khai được xác minh bằng mật mã có sẵn miễn phí trong .NET cùng với thuật toán được NIST đề xuất .
StackId trước đây đã sử dụng BCrypt và chuyển sang PBKDF2 vì lý do này:
Đối với những người tò mò, chúng tôi đang băm mật khẩu bằng PBKDF2. Mã liên quan có ở đây ( http://code.google.com.vn/p/stackid/source/browse/OpenIdProvider/Cản.cs#1135 ), thông qua một vài lớp cảm ứng. Trong một lần lặp lại trước đó, chúng tôi đã sử dụng BCrypt; nhưng đã chuyển sang PBKDF2 vì nó được tích hợp vào khung .NET, trong khi BCrypt sẽ yêu cầu chúng tôi xác minh việc triển khai (cam kết không nhỏ).
Kevin Montrose, ngày 27 tháng 5 năm 2011
(Liên kết cập nhật trên GitHub)
Biên tập: Ý nghĩa của việc xác minh bằng thuật ngữ mã hóa dường như không dễ hiểu, một triển khai được xác minh có nghĩa là nó đã được chứng minh bằng mật mã để được thực hiện mà không có lỗi. Chi phí này có thể dễ dàng đạt 20.000 USD hoặc cao hơn. Tôi nhớ lại điều này khi tôi đang nghiên cứu về OpenSSL và đọc nơi họ tuyên bố họ chưa hoàn thành toàn bộ quy trình xác minh nhưng nếu bạn cần xác minh đầy đủ rằng họ có thể chỉ cho bạn con đường đúng cho nó và đề cập đến chi phí liên quan. Một số yêu cầu của chính phủ bao gồm các nhiệm vụ cho các thuật toán mã hóa được xác minh.
Việc triển khai bcrypt trong .NET chưa được xác minh. Sử dụng triển khai mã hóa chưa được xác minh, bạn không thể hoàn toàn chắc chắn rằng không có lỗi độc hại cố ý nào trong đó như cho phép cửa hậu vào những lỗi được mã hóa hoặc vô ý thực hiện dẫn đến dữ liệu không an toàn về mật mã.
Chỉnh sửa năm 2014: Đối với bất kỳ ai đặt câu hỏi về tính không hoàn hảo của việc sử dụng thuật toán mã hóa đã được xác minh, hãy nhìn vào sự tàn phá đã bị tấn công bởi vụ hack đau lòng được khai thác trong OpenSSL. Đó là chi phí của việc sử dụng một thực hiện chưa được xác minh. Nó an toàn .... cho đến khi bạn phát hiện ra rằng bất kỳ người nào cũng có thể đọc toàn bộ nội dung bộ nhớ của máy chủ của bạn.
Tác giả của sự thay đổi đã giới thiệu Heartbleed, Robin Seggelmann, tuyên bố rằng ông "đã bỏ lỡ việc xác thực một biến có chứa độ dài" và từ chối mọi ý định gửi một triển khai thiếu sót. Theo tiết lộ của Heartbleed, Seggelmann đề nghị tập trung vào khía cạnh thứ hai, nói rằng OpenSSL không được xem xét bởi đủ người.
Đây là định nghĩa của một thực hiện chưa được xác minh. Ngay cả lỗi nhỏ nhất cũng có thể dẫn đến làm tê liệt toàn bộ bảo mật.
Chỉnh sửa 2015: Đã xóa ngôn ngữ dựa trên đề xuất và thay thế bằng tuyệt đối. Kevin Montrose bình luận gốc cho hậu thế.