Muối không ngẫu nhiên cho băm mật khẩu

CẬP NHẬT: Gần đây tôi đã học được từ câu hỏi này rằng trong toàn bộ cuộc thảo luận bên dưới, tôi (và tôi chắc chắn những người khác cũng vậy) hơi khó hiểu: Cái mà tôi vẫn gọi là bảng cầu vồng, trên thực tế được gọi là bảng băm. Bàn cầu vồng là những sinh vật phức tạp hơn và thực sự là một biến thể của Hellman Hash Chains. Mặc dù tôi tin rằng câu trả lời vẫn giống nhau (vì nó không liên quan đến phân tích mật mã), một số cuộc thảo luận có thể hơi sai lệch.
Câu hỏi: " Bảng cầu vồng là gì và chúng được sử dụng như thế nào? "

Thông thường, tôi luôn khuyên bạn nên sử dụng giá trị ngẫu nhiên mạnh về mặt mật mã dưới dạng muối, được sử dụng với các hàm băm (ví dụ: đối với mật khẩu), chẳng hạn như để bảo vệ khỏi các cuộc tấn công Rainbow Table.

Nhưng liệu nó có thực sự cần thiết về mặt mật mã để muối là ngẫu nhiên? Bất kỳ giá trị duy nhất nào (duy nhất cho mỗi người dùng, ví dụ: userId) có đủ về vấn đề này không? Trên thực tế, nó sẽ ngăn việc sử dụng một Bảng cầu vồng duy nhất để bẻ khóa tất cả (hoặc hầu hết) mật khẩu trong hệ thống ...
Nhưng liệu thiếu entropy có thực sự làm suy yếu sức mạnh mật mã của các hàm băm không?

Lưu ý, tôi không hỏi về lý do tại sao sử dụng muối, cách bảo vệ nó (không cần phải như vậy), sử dụng một hằng số băm (không) hoặc loại hàm băm nào để sử dụng.
Chỉ là muối có cần entropy hay không.

Cảm ơn tất cả các câu trả lời cho đến nay, nhưng tôi muốn tập trung vào các lĩnh vực tôi (một chút) ít quen thuộc hơn. Chủ yếu là ý nghĩa đối với phân tích mật mã - Tôi đánh giá cao nhất nếu bất kỳ ai có một số đầu vào từ PoV toán học tiền điện tử.
Ngoài ra, nếu có các vectơ bổ sung chưa được xem xét, thì đó cũng là đầu vào tuyệt vời (xem điểm @Dave Sherohman trên nhiều hệ thống).
Ngoài ra, nếu bạn có bất kỳ lý thuyết, ý tưởng hoặc phương pháp hay nhất nào - vui lòng sao lưu điều này bằng bằng chứng, kịch bản tấn công hoặc bằng chứng thực nghiệm. Hoặc thậm chí là những cân nhắc hợp lệ đối với những đánh đổi có thể chấp nhận được ... Tôi đã quen thuộc với Phương pháp hay nhất (viết hoa B vốn P) về chủ đề này, tôi muốn chứng minh điều này thực sự mang lại giá trị gì.

CHỈNH SỬA: Một số câu trả lời thực sự tốt ở đây, nhưng tôi nghĩ như @Dave nói, nó đi xuống Bảng Cầu vồng cho các tên người dùng phổ biến ... và các tên có thể ít phổ biến hơn. Tuy nhiên, điều gì sẽ xảy ra nếu tên người dùng của tôi là duy nhất trên toàn cầu? Không nhất thiết là duy nhất cho hệ thống của tôi, nhưng cho mỗi người dùng - ví dụ: địa chỉ email.
Sẽ không có động cơ để xây dựng RT cho một người dùng (như @Dave đã nhấn mạnh, muối không được giữ bí mật) và điều này sẽ vẫn ngăn chặn việc phân cụm. Chỉ có một vấn đề là tôi có thể có cùng một email và mật khẩu trên một trang web khác - nhưng dù sao thì Salt cũng không ngăn được điều đó.
Vì vậy, nó quay trở lại với phân tích mật mã - entropy có cần thiết hay không? (Suy nghĩ hiện tại của tôi là nó không cần thiết từ quan điểm phân tích mật mã, nhưng nó là từ những lý do thực tế khác.)

Salt theo truyền thống được lưu trữ dưới dạng tiền tố cho mật khẩu được băm. Điều này đã khiến bất kỳ kẻ tấn công nào có quyền truy cập vào băm mật khẩu đều biết. Sử dụng tên người dùng như muối hay không không ảnh hưởng đến kiến ​​thức đó và do đó, nó sẽ không ảnh hưởng đến bảo mật hệ thống đơn.

Tuy nhiên, việc sử dụng tên người dùng hoặc bất kỳ giá trị nào khác do người dùng kiểm soát dưới dạng muối sẽ làm giảm tính bảo mật trên toàn hệ thống, vì người dùng có cùng tên người dùng và mật khẩu trên nhiều hệ thống sử dụng cùng một thuật toán băm mật khẩu sẽ kết thúc với cùng một hàm băm mật khẩu. mỗi hệ thống đó. Tôi không coi đây là một trách nhiệm pháp lý đáng kể vì tôi, với tư cách là một kẻ tấn công, sẽ thử mật khẩu mà một tài khoản mục tiêu được biết là đã sử dụng trên các hệ thống khác trước khi thử bất kỳ phương thức nào khác để xâm phạm tài khoản. Các hàm băm giống hệt nhau sẽ chỉ cho tôi biết trước rằng mật khẩu đã biết sẽ hoạt động, chúng sẽ không làm cho cuộc tấn công thực sự dễ dàng hơn. (Tuy nhiên, lưu ý rằng so sánh nhanh các cơ sở dữ liệu tài khoản sẽ cung cấp danh sách các mục tiêu có mức độ ưu tiên cao hơn, vì nó sẽ cho tôi biết ai là ai và ai không sử dụng lại mật khẩu.)

Mối nguy lớn hơn từ ý tưởng này là tên người dùng thường được sử dụng lại - chẳng hạn như bất kỳ trang web nào bạn muốn truy cập sẽ có tài khoản người dùng tên là "Dave", và "quản trị viên" hoặc "người chủ" thậm chí còn phổ biến hơn - điều này sẽ khiến xây dựng bảng cầu vồng nhắm mục tiêu người dùng với những tên thông thường đó dễ dàng và hiệu quả hơn nhiều.

Cả hai lỗi này đều có thể được giải quyết hiệu quả bằng cách thêm giá trị muối thứ hai (cố định và ẩn hoặc lộ ra như muối tiêu chuẩn) vào mật khẩu trước khi băm nó, nhưng tại thời điểm đó, bạn cũng có thể chỉ sử dụng muối entropic tiêu chuẩn để thay thế làm việc tên người dùng vào nó.

Đã chỉnh sửa để Thêm: Rất nhiều người đang nói về entropy và liệu entropy trong muối có quan trọng không. Đó là, nhưng không phải vì lý do mà hầu hết các bình luận về nó dường như nghĩ.

Suy nghĩ chung dường như cho rằng entropy là quan trọng nên muối sẽ khó đoán đối với kẻ tấn công. Điều này không chính xác và trên thực tế, hoàn toàn không liên quan. Như đã được chỉ ra một vài lần bởi nhiều người, các cuộc tấn công sẽ bị ảnh hưởng bởi muối chỉ có thể được thực hiện bởi ai đó có cơ sở dữ liệu mật khẩu và người có cơ sở dữ liệu mật khẩu chỉ có thể xem xét muối của từng tài khoản. Nó có thể đoán được hay không không quan trọng khi bạn có thể tra cứu nó một cách tinh tế.

Lý do mà entropy là quan trọng là để tránh tập hợp các giá trị muối. Nếu muối dựa trên tên người dùng và bạn biết rằng hầu hết các hệ thống sẽ có tài khoản có tên "root" hoặc "admin", thì bạn có thể tạo một bảng cầu vồng cho hai muối đó và nó sẽ bẻ khóa hầu hết các hệ thống. Mặt khác, nếu sử dụng một muối 16-bit ngẫu nhiên và các giá trị ngẫu nhiên có phân phối gần như đồng đều, thì bạn cần một bảng cầu vồng cho tất cả 2 ^ 16 muối có thể có.

Nó không phải là ngăn chặn kẻ tấn công biết muối của tài khoản cá nhân là gì, mà là không cho chúng mục tiêu lớn, béo của một loại muối duy nhất sẽ được sử dụng trên một tỷ lệ đáng kể các mục tiêu tiềm năng.

Việc sử dụng muối entropy cao là hoàn toàn cần thiết để lưu trữ mật khẩu một cách an toàn.

Lấy tên người dùng 'gs' của tôi và thêm nó vào mật khẩu của tôi 'MyPassword' cung cấp cho gsMyPassword. Điều này dễ dàng bị phá vỡ bằng cách sử dụng bảng cầu vồng vì nếu tên người dùng không có đủ entropy thì có thể giá trị này đã được lưu trữ trong bảng cầu vồng, đặc biệt nếu tên người dùng ngắn.

Một vấn đề khác là các cuộc tấn công mà bạn biết rằng một người dùng tham gia vào hai hoặc nhiều dịch vụ. Có rất nhiều tên người dùng phổ biến, có lẽ những tên quan trọng nhất là admin và root. Nếu ai đó tạo một bảng cầu vồng có muối với những tên người dùng phổ biến nhất, anh ta có thể sử dụng chúng để xâm phạm tài khoản.

Họ từng có muối 12-bit . 12 bit là 4096 kết hợp khác nhau. Điều đó không đủ an toàn vì ngày nay có thể dễ dàng lưu trữ nhiều thông tin . Điều tương tự cũng áp dụng cho 4096 tên người dùng được sử dụng nhiều nhất. Có khả năng một số người dùng của bạn sẽ chọn tên người dùng thuộc về những tên người dùng phổ biến nhất.

Tôi đã tìm thấy công cụ kiểm tra mật khẩu này, công cụ này sẽ tìm ra entropy của mật khẩu của bạn. Việc có entropy nhỏ hơn trong mật khẩu (như bằng cách sử dụng tên người dùng) giúp bảng cầu vồng dễ dàng hơn nhiều vì chúng cố gắng che ít nhất tất cả các mật khẩu có entropy thấp, vì chúng có nhiều khả năng xảy ra hơn.

Đúng là chỉ riêng tên người dùng có thể có vấn đề vì mọi người có thể chia sẻ tên người dùng giữa các trang web khác nhau. Nhưng sẽ không có vấn đề gì nếu người dùng có một tên khác nhau trên mỗi trang web. Vì vậy, tại sao không chỉ làm cho nó duy nhất trên mỗi trang web. Băm mật khẩu giống như thế này

hàm băm ("www.yourpage.com /" + tên người dùng + "/" + mật khẩu)

Điều này sẽ giải quyết vấn đề. Tôi không phải là bậc thầy về phân tích mật mã, nhưng tôi chắc chắn nghi ngờ rằng việc chúng ta không sử dụng entropy cao sẽ khiến hàm băm yếu hơn.

Tôi thích sử dụng cả hai: một muối ngẫu nhiên có entropy cao cho mỗi bản ghi, cộng với ID duy nhất của chính bản ghi.

Mặc dù điều này không bổ sung nhiều vào bảo mật chống lại các cuộc tấn công từ điển, v.v., nhưng nó sẽ loại bỏ trường hợp rìa khi ai đó sao chép muối và băm của họ sang một bản ghi khác với ý định thay thế mật khẩu bằng mật khẩu của chính họ.

(Phải thừa nhận rằng thật khó để nghĩ ra một trường hợp áp dụng điều này, nhưng tôi có thể thấy rằng đai và niềng răng không có hại gì khi nói đến vấn đề an ninh.)

Nếu muối đã biết hoặc dễ đoán, bạn đã không làm tăng độ khó của một cuộc tấn công từ điển. Thậm chí có thể tạo một bảng cầu vồng sửa đổi có tính đến muối "không đổi".

Sử dụng các loại muối độc đáo làm tăng độ khó của các cuộc tấn công từ điển BULK.

Có giá trị muối mạnh về mặt mật mã, duy nhất sẽ là lý tưởng.

Tôi sẽ nói rằng miễn là muối khác nhau cho mỗi mật khẩu, bạn có thể sẽ ổn. Điểm mấu chốt là bạn không thể sử dụng bảng cầu vồng tiêu chuẩn để giải mọi mật khẩu trong cơ sở dữ liệu. Vì vậy, nếu bạn áp dụng một muối khác nhau cho mọi mật khẩu (ngay cả khi nó không phải là ngẫu nhiên), về cơ bản kẻ tấn công sẽ phải tính toán một bảng cầu vồng mới cho mỗi mật khẩu, vì mỗi mật khẩu sử dụng một muối khác nhau.

Việc sử dụng một muối có nhiều entropy hơn không giúp ích được nhiều, bởi vì kẻ tấn công trong trường hợp này được cho là đã có cơ sở dữ liệu. Vì bạn cần có thể tạo lại băm, nên bạn phải biết muối là gì. Vì vậy, bạn phải lưu trữ muối hoặc các giá trị tạo nên muối trong tệp của bạn. Trong các hệ thống như Linux, phương pháp lấy muối đã được biết đến, vì vậy việc có muối bí mật sẽ không có ích gì. Bạn phải giả định rằng kẻ tấn công có giá trị băm của bạn, có thể cũng biết giá trị muối của bạn.

Độ mạnh của một hàm băm không được xác định bởi đầu vào của nó!

Sử dụng một muối mà kẻ tấn công biết rõ ràng làm cho việc xây dựng bảng cầu vồng (đặc biệt đối với tên người dùng được mã hóa cứng như root ) hấp dẫn hơn, nhưng nó không làm suy yếu hàm băm . Sử dụng một loại muối mà kẻ tấn công không rõ sẽ làm cho hệ thống khó bị tấn công hơn.

Việc nối tên người dùng và mật khẩu vẫn có thể cung cấp một mục nhập cho một bảng cầu vồng thông minh, do đó, sử dụng muối của một chuỗi ký tự giả ngẫu nhiên, được lưu trữ bằng mật khẩu băm có lẽ là một ý tưởng tốt hơn. Như một minh họa, nếu tôi có tên người dùng "khoai tây" và mật khẩu "bia", thì đầu vào được nối cho hàm băm của bạn là "khoai tây chiên", đây là một mục nhập hợp lý cho bảng cầu vồng.

Thay đổi muối mỗi khi người dùng thay đổi mật khẩu của họ có thể giúp đánh bại các cuộc tấn công kéo dài, cũng như việc thực thi chính sách mật khẩu hợp lý, ví dụ: chữ hoa, dấu câu, độ dài tối thiểu, thay đổi sau n tuần.

Tuy nhiên, tôi muốn nói rằng lựa chọn thuật toán thông báo của bạn quan trọng hơn. Ví dụ, việc sử dụng SHA-512 sẽ gây khó khăn cho người tạo bảng cầu vồng hơn MD5.

Salt phải có càng nhiều entropy càng tốt để đảm bảo rằng nếu một giá trị đầu vào nhất định được băm nhiều lần, giá trị băm kết quả sẽ luôn khác nhau càng gần càng tốt.

Sử dụng các giá trị muối luôn thay đổi với càng nhiều entropy trong muối càng tốt sẽ đảm bảo rằng khả năng băm (giả sử, mật khẩu + muối) sẽ tạo ra các giá trị băm hoàn toàn khác nhau.

Càng ít entropy trong muối, bạn càng có nhiều cơ hội tạo ra cùng một giá trị muối, vì vậy bạn càng có nhiều cơ hội tạo ra cùng một giá trị băm.

Bản chất của giá trị băm là "không đổi" khi đầu vào đã biết và "không đổi" cho phép các cuộc tấn công từ điển hoặc bảng cầu vồng trở nên hiệu quả như vậy. Bằng cách thay đổi giá trị băm kết quả càng nhiều càng tốt (bằng cách sử dụng giá trị muối entropy cao) đảm bảo rằng việc băm cùng một đầu vào + muối ngẫu nhiên sẽ tạo ra nhiều kết quả giá trị băm khác nhau, do đó đánh bại (hoặc ít nhất là làm giảm đáng kể hiệu quả của) bảng cầu vồng các cuộc tấn công.

Entropy là điểm của giá trị Salt.

Nếu có một số "toán học" đơn giản và có thể tái tạo đằng sau muối, thì nó giống như muối không có ở đó. Chỉ cần thêm giá trị thời gian sẽ ổn.