Mã hóa (MD5) nhiều lần có thể cải thiện bảo mật?

Question

Tôi thấy một số người mã hóa mật khẩu người dùng nhiều lần với MD5 để cải thiện bảo mật. Tôi không chắc chắn nếu điều này hoạt động nhưng nó không nhìn tốt. Vì vậy, nó có ý nghĩa?

Answer 1

Giả sử hàm băm bạn sử dụng sẽ là một hàm một chiều hoàn hảo. Sau đó, bạn có thể xem kết quả đầu ra của nó giống như của một "random oracle", giá trị đầu ra của nó nằm trong một phạm vi giá trị hữu hạn (2^128 cho MD5).

Điều gì sẽ xảy ra nếu bạn áp dụng hàm băm nhiều lần? Đầu ra sẽ vẫn ở trong cùng một phạm vi (2^128). Nó giống như bạn nói "Đoán số ngẫu nhiên của tôi!" hai mươi lần, mỗi lần suy nghĩ về một số mới - điều đó không làm cho việc đoán khó hơn hoặc dễ dàng hơn. Không có bất kỳ "ngẫu nhiên" hơn ngẫu nhiên. Đó không phải là một sự tương tự hoàn hảo, nhưng tôi nghĩ nó giúp minh họa cho vấn đề.

Xem xét việc giả mạo mật khẩu, chương trình của bạn không thêm bất kỳ bảo mật nào. Thậm chí tệ hơn, điều duy nhất bạn có thể "hoàn thành" là làm suy yếu an ninh bằng cách giới thiệu một số khả năng khai thác ứng dụng lặp lại của hàm băm. Nó không chắc, nhưng ít nhất nó được đảm bảo rằng bạn chắc chắn sẽ không giành chiến thắng bất cứ điều gì.

Vậy tại sao vẫn không bị mất theo phương pháp này? Đó là vì quan điểm mà những người khác thực hiện liên quan đến việc có hàng ngàn lần lặp thay vì chỉ hai mươi lần. Tại sao đây là một điều tốt, làm chậm thuật toán xuống? Đó là vì hầu hết những kẻ tấn công sẽ cố truy cập bằng cách sử dụng từ điển (hoặc rainbow table sử dụng mật khẩu thường được sử dụng, hy vọng rằng một trong những người dùng của bạn đã cẩu thả đủ để sử dụng một trong số đó (tôi có lỗi, ít nhất là Ubuntu đã nói với tôi khi cài đặt). Nhưng mặt khác, người dùng không cần phải nhớ 30 ký tự ngẫu nhiên:

Đó là lý do tại sao chúng ta cần một số hình thức đánh đổi giữa các mật khẩu dễ nhớ nhưng đồng thời làm cho nó khó có thể Có hai phương pháp phổ biến, salts và làm chậm quá trình xuống bằng cách áp dụng nhiều lần lặp của một số chức năng thay vì một lần lặp lại duy nhất PKCS#5 là một ví dụ tốt để xem xét.Trong trường hợp của bạn áp dụng MD5 20000 thay vì 20 lần sẽ làm chậm kẻ tấn công bằng cách sử dụng một từ điển đáng kể, bởi vì mỗi mật khẩu đầu vào của họ sẽ phải trải qua thủ tục bình thường bị băm 20000 lần để vẫn hữu ích như một tấn công. Lưu ý rằng quy trình này thực hiện không phải ảnh hưởng đến việc ép buộc như minh họa ở trên.

Nhưng tại sao việc sử dụng muối vẫn tốt hơn? Bởi vì ngay cả khi bạn áp dụng giá trị băm 20000 lần, kẻ tấn công tài nguyên có thể tính toán trước một cơ sở dữ liệu mật khẩu lớn, băm nhỏ mỗi lần 20000 lần, tạo ra một bảng cầu vồng tùy chỉnh được nhắm mục tiêu cụ thể vào ứng dụng của bạn. Sau khi thực hiện điều này, họ có thể dễ dàng tấn công ứng dụng của bạn hoặc bất kỳ ứng dụng nào khác bằng cách sử dụng lược đồ của bạn. Đó là lý do tại sao bạn cũng cần phải tạo ra một chi phí cao cho mỗi mật khẩu, để làm cho các bảng cầu vồng như vậy không thực tế để sử dụng.

Nếu bạn muốn ở bên thực sự an toàn, hãy sử dụng thứ gì đó như PBKDF2 được minh họa trong PKCS # 5.

Answer 2

không, nó không phải là một thực hành tốt, bạn phải sử dụng $ muối để mã hóa của bạn bởi vì mật khẩu CAND được nứt với những bảng cầu vồng

Answer 3

Băm mật khẩu không phải là mã hóa. Nó là một quá trình một chiều.

Kiểm tra security.stackexchange.com và các câu hỏi liên quan đến mật khẩu. Chúng rất phổ biến, chúng tôi đặt cùng nhau this blog post đặc biệt để giúp các cá nhân tìm thấy câu hỏi và câu trả lời hữu ích.

This question thảo luận cụ thể bằng cách sử dụng md5 20 lần liên tiếp - xem câu trả lời của Thomas Pornin. Những điểm mấu chốt trong câu trả lời của mình:

• 20 là quá thấp, nó phải là 20000 hoặc nhiều hơn - chế biến mật khẩu vẫn còn quá nhanh
• Không có muối: một kẻ tấn công có thể tấn công mật khẩu với rất thấp chi phí cho mỗi mật khẩu , ví dụ các bảng cầu vồng - có thể được tạo cho bất kỳ số lượng md5 chu kỳ
• Vì không có kiểm tra chắc chắn để biết liệu thuật toán đã cho có an toàn hay không, việc phát minh ra mật mã của bạn thường là một công thức cho thảm họa. Đừng làm điều đó

Answer 4

Có một câu hỏi trên crypto.SE nhưng hiện KHÔNG công khai. Câu trả lời bởi Paŭlo Ebermann là:

Đối với mật khẩu băm, bạn không nên sử dụng một băm mật mã bình thường, nhưng cái gì làm đặc biệt để bảo vệ mật khẩu, như bcrypt.

Xem How to safely store a password để biết chi tiết.

Điểm quan trọng là bánh mật khẩu không phải bruteforce không gian đầu ra băm (2 cho SHA-1), nhưng chỉ có không gian mật khẩu, mà là nhiều nhỏ hơn nhiều (tùy thuộc vào mật khẩu của bạn quy tắc - và thường giúp từ điển). Do đó, chúng tôi không muốn hàm số băm nhanh nhưng chậm. Bcrypt và bạn bè được thiết kế cho điều này.

Và tương tự như câu hỏi có những câu trả lời: Câu hỏi đặt ra là "Bảo vệ chống lại những bước đột phá cryptanalytic: kết hợp nhiều chức năng băm" trả lời bởi Thomas Pornin:

Kết hợp là gì SSL/TLS làm với MD5 và SHA-1 , trong định nghĩa nội bộ của nó "PRF" (thực ra là một số Key Derivation Function). Đối với hàm băm đã cho, TLS định nghĩa một KDF mà dựa vào HMAC dựa vào hàm băm. Sau đó, KDF là được gọi hai lần, một lần với MD5 và một lần với SHA-1 và kết quả là XORed cùng nhau. Ý tưởng là để chống lại vi phạm phân tích trong hoặc MD5 hoặc SHA-1. Lưu ý rằng XORing kết quả đầu ra của hai hàm băm dựa trên các giả định tinh tế. Ví dụ, nếu tôi xác định SHB-256 (m) = SHA-256 (m) XOR C, đối với một cố định liên tục C, sau đó SHB-256 là như tốt một hàm băm như SHA -256; nhưng XOR của cả hai luôn mang lại C, điều này hoàn toàn không tốt cho mục đích băm. Do đó, việc xây dựng trong TLS không thực sự bị xử phạt bởi thẩm quyền của khoa học (nó chỉ xảy ra không bị hỏng).TLS-1.2 không không sử dụng kết hợp đó nữa; nó dựa trên KDF với một hàm băm đơn lẻ, có thể cấu hình, thường là SHA-256 (nghĩa là, vào năm 2011, một sự lựa chọn thông minh ).

Khi @PulpSpy chỉ ra, việc ghép nối không phải là cách tổng quát tốt của các hàm băm xây dựng . Điều này đã được Joux xuất bản vào năm 2004 và sau đó là được tổng quát hóa bởi Hoch and Shamir in 2006, đối với một lớp lớn gồm xây dựng liên quan đến lặp lại và ghép nối. Nhưng hãy chú ý đến bản in số : điều này không thực sự về những điểm yếu còn tồn tại trong hàm băm , nhưng về việc kiếm tiền của bạn đáng giá. Cụ thể là, nếu bạn lấy hàm băm với đầu ra 128 bit và đầu ra khác với đầu ra 160 bit, và nối các kết quả, thì kháng va chạm sẽ không bị tồi tệ hơn mức mạnh nhất trong hai; những gì Joux cho thấy là nó sẽ cũng không tốt hơn nhiều. Với 128 + 160 = 288 bit đầu ra, bạn có thể nhắm đến 2 kháng, nhưng kết quả của Joux ngụ ý rằng bạn sẽ không vượt quá khoảng 2 .

Vậy câu hỏi trở thành: có cách nào, nếu có thể một hiệu quả cách, để kết hợp hai hàm băm như vậy mà kết quả là như va chạm chịu như mạnh nhất trong hai, nhưng mà không bị sự mở rộng đầu ra của nối? Năm 2006, Boneh and Boyen đã xuất bản kết quả chỉ đơn giản tuyên bố rằng câu trả lời là không, tùy thuộc vào điều kiện đánh giá từng hàm băm chỉ một lần. Chỉnh sửa:Pietrzak dỡ bỏ điều kiện sau trong năm 2007 (tức là gọi mỗi hàm băm nhiều lần không có tác dụng).

Và bởi PulpSpy:

Tôi chắc chắn @Thomas sẽ cho một câu trả lời thấu đáo. Trong nội bộ, tôi sẽ chỉ chỉ ra rằng điện trở va chạm của công trình đầu tiên của bạn, H1 (m) || H2 (M) đáng ngạc nhiên là không tốt hơn nhiều so với chỉ H1 (M). Xem phần 4 của bài viết này:

http://web.cecs.pdx.edu/~teshrim/spring06/papers/general-attacks/multi-joux.pdf