Làm thế nào để mật khẩu muối giúp chống lại một cuộc tấn công bảng cầu vồng?

Tôi gặp một số khó khăn khi hiểu mục đích của muối đối với mật khẩu. Theo hiểu biết của tôi, việc sử dụng chính là cản trở một cuộc tấn công bảng cầu vồng. Tuy nhiên, các phương pháp tôi đã thấy để thực hiện điều này dường như không thực sự làm cho vấn đề trở nên khó khăn hơn.

Tôi đã thấy nhiều hướng dẫn gợi ý rằng muối được sử dụng như sau:

$hash =  md5($salt.$password)

Lý do là băm bây giờ ánh xạ không phải mật khẩu ban đầu, mà là sự kết hợp của mật khẩu và muối. Nhưng nói $salt=foovà $password=barvà $hash=3858f62230ac3c915f300c664312c63f. Bây giờ ai đó với bảng cầu vồng có thể đảo ngược hàm băm và đưa ra "foobar" đầu vào. Sau đó, họ có thể thử tất cả các kết hợp mật khẩu (f, fo, foo, ... oobar, obar, bar, ar, ar). Có thể mất thêm vài mili giây để lấy mật khẩu, nhưng không nhiều.

Việc sử dụng khác tôi đã thấy là trên hệ thống linux của tôi. Trong / etc / bóng, mật khẩu băm thực sự được lưu trữ với muối. Ví dụ: một muối "foo" và mật khẩu của "bar" sẽ băm vào đây : $1$foo$te5SBM.7C25fFDu6bIRbX1. Nếu một hacker bằng cách nào đó có thể có được bàn tay của mình trong tập tin này, tôi sẽ không biết mục đích của muối là gì, vì hàm băm ngược te5SBM.7C25fFDu6bIRbXđược biết là có chứa "foo".

Cảm ơn cho bất kỳ ánh sáng bất cứ ai có thể làm sáng tỏ về điều này.

EDIT : Cảm ơn sự giúp đỡ. Để tóm tắt những gì tôi hiểu, muối làm cho mật khẩu băm phức tạp hơn, do đó làm cho nó ít có khả năng tồn tại trong một bảng cầu vồng được tính toán trước. Điều tôi đã hiểu lầm trước đây là tôi đã giả sử một bảng cầu vồng tồn tại cho TẤT CẢ băm.

Một muối công cộng sẽ không làm cho các cuộc tấn công từ điển khó hơn khi bẻ khóa một mật khẩu. Như bạn đã chỉ ra, kẻ tấn công có quyền truy cập vào cả mật khẩu băm và muối, vì vậy khi chạy tấn công từ điển, cô ấy chỉ cần sử dụng muối đã biết khi cố gắng bẻ khóa mật khẩu.

Một loại muối công cộng thực hiện hai điều: làm cho việc bẻ khóa một danh sách mật khẩu lớn và khiến cho việc sử dụng bảng cầu vồng trở nên không khả thi hơn.

Để hiểu cái đầu tiên, hãy tưởng tượng một tệp mật khẩu duy nhất chứa hàng trăm tên người dùng và mật khẩu. Nếu không có muối, tôi có thể tính "md5 (thử [0])", sau đó quét qua tệp để xem băm đó có xuất hiện ở bất cứ đâu không. Nếu có muối, thì tôi phải tính "md5 (salt [a]. Nỗ lực [0])", so sánh với mục A, sau đó "md5 (salt [b]. Nỗ lực [0])", so sánh với mục B , v.v ... Bây giờ tôi có nnhiều việc phải làm, nsố lượng tên người dùng và mật khẩu có trong tệp là bao nhiêu.

Để hiểu cái thứ hai, bạn phải hiểu bảng cầu vồng là gì. Bảng cầu vồng là một danh sách lớn các giá trị băm được tính toán trước cho các mật khẩu thường được sử dụng. Hãy tưởng tượng lại tập tin mật khẩu không có muối. Tất cả những gì tôi phải làm là đi qua từng dòng của tệp, rút ​​mật khẩu băm và tra cứu nó trong bảng cầu vồng. Tôi không bao giờ phải tính một hàm băm duy nhất. Nếu việc tra cứu nhanh hơn đáng kể so với hàm băm (có thể là như vậy), điều này sẽ tăng tốc đáng kể việc bẻ khóa tệp.

Nhưng nếu tệp mật khẩu được muối, thì bảng cầu vồng sẽ phải chứa "muối. Mật khẩu" được băm trước. Nếu muối là đủ ngẫu nhiên, điều này rất khó xảy ra. Có lẽ tôi sẽ có những thứ như "xin chào" và "foobar" và "qwerty" trong danh sách mật khẩu được sử dụng trước, được băm trước (bảng cầu vồng), nhưng tôi sẽ không có những thứ như "jX95psDZhello" hoặc "LPgB0sdgxfoobar" hoặc "dZVUABJtqwerty" được tính toán trước. Điều đó sẽ làm cho bàn cầu vồng lớn một cách nghiêm ngặt.

Vì vậy, muối làm giảm kẻ tấn công trở lại một lần tính toán trên mỗi hàng cho mỗi lần thử, khi được kết hợp với một mật khẩu đủ dài, đủ ngẫu nhiên, nói chung là không thể bẻ khóa được.

Các câu trả lời khác dường như không giải quyết được những hiểu lầm của bạn về chủ đề này, vì vậy, đây là:

Hai công dụng khác nhau của muối

Tôi đã thấy nhiều hướng dẫn gợi ý rằng muối được sử dụng như sau:

$hash = md5($salt.$password)

[...]

Việc sử dụng khác tôi đã thấy là trên hệ thống linux của tôi. Trong / etc / bóng, mật khẩu băm thực sự được lưu trữ với muối.

Bạn luôn phải lưu trữ muối với mật khẩu, vì để xác thực những gì người dùng đã nhập vào cơ sở dữ liệu mật khẩu của bạn, bạn phải kết hợp đầu vào với muối, băm và so sánh với băm được lưu trữ.

Bảo mật của hàm băm

Bây giờ ai đó với bảng cầu vồng có thể đảo ngược hàm băm và đưa ra "foobar" đầu vào.

[...]

vì hàm băm ngược của te5SBM.7C25fFDu6bIRbX được biết là có chứa "foo".

Không thể đảo ngược hàm băm như vậy (về lý thuyết, ít nhất). Hàm băm của "foo" và hàm băm của "saltfoo" không có gì chung. Thay đổi ngay cả một bit trong đầu vào của hàm băm mật mã sẽ thay đổi hoàn toàn đầu ra.

Điều này có nghĩa là bạn không thể xây dựng một bảng cầu vồng với các mật khẩu phổ biến và sau đó "cập nhật" nó với một chút muối. Bạn phải đưa muối vào tài khoản ngay từ đầu.

Đây là toàn bộ lý do tại sao bạn cần một bàn cầu vồng ở nơi đầu tiên. Vì bạn không thể lấy mật khẩu từ hàm băm, nên bạn tính toán trước tất cả các giá trị băm của mật khẩu được sử dụng nhiều nhất và sau đó so sánh giá trị băm của bạn với giá trị băm của chúng.

Chất lượng muối

Nhưng nói $salt=foo

"foo" sẽ là một lựa chọn cực kỳ nghèo nàn về muối. Thông thường bạn sẽ sử dụng một giá trị ngẫu nhiên, được mã hóa trong ASCII.

Ngoài ra, mỗi mật khẩu đều có muối riêng, khác nhau (hy vọng) từ tất cả các loại muối khác trên hệ thống. Điều này có nghĩa là, kẻ tấn công phải tấn công từng mật khẩu riêng lẻ thay vì hy vọng rằng một trong các giá trị băm khớp với một trong các giá trị trong cơ sở dữ liệu của cô.

Cuộc tấn công

Nếu một hacker nào đó có thể có được bàn tay của mình trong tập tin này, thì tôi không thấy mục đích của muối phục vụ là gì,

Một cuộc tấn công bảng cầu vồng luôn cần /etc/passwd(hoặc bất kỳ cơ sở dữ liệu mật khẩu nào được sử dụng), hoặc nếu không bạn sẽ so sánh các giá trị băm trong bảng cầu vồng với giá trị băm của mật khẩu thực tế như thế nào?

Về mục đích: giả sử kẻ tấn công muốn xây dựng một bảng cầu vồng cho 100.000 từ tiếng Anh thông dụng và mật khẩu thông thường (nghĩ là "bí mật"). Nếu không có muối, cô sẽ phải tính toán trước 100.000 lần băm. Ngay cả với muối UNIX truyền thống gồm 2 ký tự (mỗi ký tự là một trong 64 lựa chọn [a–zA–Z0–9./]:) cô sẽ phải tính toán và lưu trữ 4.096.000.000 băm ... khá là cải tiến.

Ý tưởng với muối là làm cho nó khó đoán hơn nhiều với mật khẩu so với mật khẩu dựa trên ký tự bình thường. Các bảng cầu vồng thường được xây dựng với một ký tự đặc biệt được đặt ra và không phải lúc nào cũng bao gồm tất cả các kết hợp có thể (mặc dù chúng có thể).

Vì vậy, giá trị muối tốt sẽ là số nguyên ngẫu nhiên 128 bit hoặc dài hơn. Đây là những gì làm cho các cuộc tấn công bảng cầu vồng thất bại. Bằng cách sử dụng một giá trị muối khác nhau cho mỗi mật khẩu được lưu trữ, bạn cũng đảm bảo rằng bảng cầu vồng được tạo cho một giá trị muối cụ thể (có thể là trường hợp nếu bạn là một hệ thống phổ biến có một giá trị muối duy nhất) không cung cấp cho bạn quyền truy cập vào tất cả mật khẩu cùng một lúc.

Một câu hỏi tuyệt vời khác, với nhiều câu trả lời rất chu đáo - +1 cho SO!

Một điểm nhỏ mà tôi chưa thấy đề cập rõ ràng là, bằng cách thêm một loại muối ngẫu nhiên vào mỗi mật khẩu, bạn gần như đảm bảo rằng hai người dùng tình cờ chọn cùng một mật khẩu sẽ tạo ra các giá trị băm khác nhau.

Tại sao nó lại quan trọng?

Hãy tưởng tượng cơ sở dữ liệu mật khẩu tại một công ty phần mềm lớn ở tây bắc Hoa Kỳ. Giả sử nó chứa 30.000 mục, trong đó 500 có màn hình blues mật khẩu . Giả sử thêm rằng một hacker quản lý để có được mật khẩu này, hãy nói bằng cách đọc nó trong một email từ người dùng đến bộ phận CNTT. Nếu mật khẩu không được đánh dấu, tin tặc có thể tìm thấy giá trị băm trong cơ sở dữ liệu, sau đó chỉ cần khớp mẫu với nó để có quyền truy cập vào 499 tài khoản khác.

Việc xử lý mật khẩu đảm bảo rằng mỗi trong số 500 tài khoản có một mật khẩu (muối + mật khẩu) duy nhất, tạo ra một hàm băm khác nhau cho mỗi tài khoản và do đó giảm vi phạm vào một tài khoản. Và hãy hy vọng, chống lại tất cả các khả năng, rằng bất kỳ người dùng nào đủ ngây thơ để viết mật khẩu văn bản gốc trong thư email sẽ không có quyền truy cập vào API không có giấy tờ cho HĐH tiếp theo.

Tôi đã tìm kiếm một phương pháp tốt để áp dụng muối và tìm thấy bài viết xuất sắc này với mã mẫu:

http://crackstation.net/hashing-security.htmlm

Tác giả khuyến nghị sử dụng muối ngẫu nhiên trên mỗi người dùng, do đó, việc truy cập vào muối sẽ không khiến toàn bộ danh sách băm dễ bị bẻ khóa.

Để lưu mật khẩu:

• Tạo một muối ngẫu nhiên dài bằng CSPRNG.
• Chuẩn bị muối vào mật khẩu và băm nó với hàm băm mật mã tiêu chuẩn như SHA256.
• Lưu cả muối và hàm băm trong bản ghi cơ sở dữ liệu của người dùng.

Để xác thực mật khẩu:

• Lấy muối và băm của người dùng từ cơ sở dữ liệu.
• Chuẩn bị muối cho mật khẩu đã cho và băm nó bằng cách sử dụng cùng hàm băm.
• So sánh hàm băm của mật khẩu đã cho với hàm băm từ cơ sở dữ liệu. Nếu chúng khớp, mật khẩu là chính xác. Nếu không, mật khẩu không chính xác.

Lý do một muối có thể làm cho một cuộc tấn công bảng cầu vồng thất bại là vì đối với n-bit của muối, bảng cầu vồng phải lớn hơn 2 lần so với kích thước bảng mà không có muối.

Ví dụ của bạn về việc sử dụng 'foo' làm muối có thể làm cho bàn cầu vồng lớn hơn 16 triệu lần.

Lấy ví dụ của Carl về muối 128 bit, điều này làm cho bảng lớn gấp 2 ^ 128 lần - bây giờ là lớn - hoặc đặt một cách khác, bao lâu trước khi ai đó có bộ lưu trữ di động lớn như vậy?

Hầu hết các phương pháp phá mã hóa dựa trên hàm băm đều dựa vào các cuộc tấn công vũ phu. Một cuộc tấn công cầu vồng về cơ bản là một cuộc tấn công từ điển hiệu quả hơn, nó được thiết kế để sử dụng chi phí lưu trữ kỹ thuật số thấp để cho phép tạo bản đồ của một tập hợp con đáng kể các mật khẩu có thể để băm và tạo điều kiện cho ánh xạ ngược. Kiểu tấn công này hoạt động vì nhiều mật khẩu có xu hướng khá ngắn hoặc sử dụng một trong một vài mẫu định dạng dựa trên từ.

Các cuộc tấn công như vậy là không hiệu quả trong trường hợp mật khẩu chứa nhiều ký tự hơn và không tuân theo các định dạng dựa trên từ phổ biến. Người dùng có mật khẩu mạnh để bắt đầu sẽ không dễ bị tấn công theo kiểu này. Thật không may, nhiều người không chọn mật khẩu tốt. Nhưng có một thỏa hiệp, bạn có thể cải thiện mật khẩu của người dùng bằng cách thêm rác ngẫu nhiên vào đó. Vì vậy, bây giờ, thay vì "hunter2", mật khẩu của họ có thể trở thành "hunter2908! Fld2R75 {R7 /; 508PEzoz ^ U430", đây là mật khẩu mạnh hơn nhiều. Tuy nhiên, vì bây giờ bạn phải lưu trữ thành phần mật khẩu bổ sung này, điều này làm giảm hiệu quả của mật khẩu hỗn hợp mạnh hơn. Hóa ra, vẫn có một lợi ích ròng cho một lược đồ như vậy kể từ bây giờ mỗi mật khẩu, ngay cả những mật khẩu yếu, không còn dễ bị tổn thương với cùng bảng băm / cầu vồng được tính toán trước. Thay vào đó, mỗi mục băm mật khẩu chỉ dễ bị tổn thương đối với một bảng băm duy nhất.

Giả sử bạn có một trang web có yêu cầu về độ mạnh của mật khẩu yếu. Nếu bạn không sử dụng muối mật khẩu, tất cả các bảng băm của bạn đều dễ bị tấn công bởi các bảng băm được tính toán trước, do đó ai đó có quyền truy cập vào bảng băm của bạn sẽ có quyền truy cập vào mật khẩu cho một tỷ lệ lớn người dùng của bạn (tuy nhiên nhiều mật khẩu dễ bị sử dụng, sẽ là một tỷ lệ đáng kể). Nếu bạn sử dụng muối mật khẩu không đổi thì các bảng băm được tính toán trước không còn giá trị nữa, vì vậy ai đó sẽ phải dành thời gian để tính toán bảng băm tùy chỉnh cho muối đó, mặc dù vậy, các bảng tính toán bao gồm các hoán vị lớn hơn của không gian vấn đề. Các mật khẩu dễ bị tổn thương nhất (ví dụ mật khẩu dựa trên từ đơn giản, mật khẩu chữ và số rất ngắn) sẽ bị bẻ khóa trong vài giờ hoặc vài ngày, mật khẩu ít bị tổn thương hơn sẽ bị bẻ khóa sau vài tuần hoặc vài tháng. Khi thời gian trôi qua, kẻ tấn công sẽ có quyền truy cập vào mật khẩu cho tỷ lệ người dùng của bạn ngày càng tăng. Nếu bạn sử dụng một loại muối duy nhất cho mỗi mật khẩu thì sẽ mất vài ngày hoặc vài tháng để có quyền truy cập vào từng mật khẩu dễ bị tấn công đó.

Như bạn có thể thấy, khi bạn bước lên từ không có muối thành một loại muối không đổi thành một loại muối duy nhất, bạn sẽ áp đặt một số đơn đặt hàng tăng cường độ trong nỗ lực bẻ khóa mật khẩu dễ bị tổn thương ở mỗi bước. Nếu không có muối, mật khẩu yếu nhất của người dùng của bạn có thể truy cập được một cách tầm thường, với muối liên tục, những mật khẩu yếu có thể truy cập được đối với kẻ tấn công xác định, với một loại muối duy nhất, chi phí truy cập mật khẩu tăng cao đến mức chỉ kẻ tấn công kiên quyết nhất mới có thể truy cập đến một tập hợp nhỏ các mật khẩu dễ bị tổn thương, và sau đó chỉ với chi phí lớn.

Đó chính xác là tình huống hiện tại. Bạn không bao giờ có thể bảo vệ người dùng hoàn toàn khỏi sự lựa chọn mật khẩu kém, nhưng bạn có thể tăng chi phí cho việc thỏa hiệp mật khẩu của người dùng của mình đến một mức độ khiến việc xâm phạm ngay cả một mật khẩu của người dùng trở nên đắt đỏ.

Một mục đích của muối là đánh bại các bảng băm được tính toán trước. Nếu ai đó có một danh sách hàng triệu băm được tính toán trước, họ sẽ không thể tra cứu $ 1 $ foo $ te5SBM.7C25fFDu6bIRbX1 trong bảng của họ mặc dù họ biết băm và muối. Họ sẽ vẫn phải vũ phu.

Một mục đích khác, như Carl S đề cập là làm cho vũ phu buộc một danh sách băm đắt hơn. (cung cấp cho họ tất cả các loại muối khác nhau)

Cả hai mục tiêu này vẫn được hoàn thành ngay cả khi muối được công khai.

Theo tôi biết, muối có mục đích làm cho các cuộc tấn công từ điển khó hơn.

Một thực tế đã biết rằng nhiều người sẽ sử dụng các từ phổ biến cho mật khẩu thay vì các chuỗi dường như ngẫu nhiên.

Vì vậy, một hacker có thể sử dụng điều này cho lợi thế của mình thay vì chỉ sử dụng vũ lực. Anh ta sẽ không tìm mật khẩu như aaa, aab, aac ... mà thay vào đó sử dụng các từ và mật khẩu phổ biến (như tên của chúa tể của những chiếc nhẫn!))

Vì vậy, nếu mật khẩu của tôi là Legolas, một hacker có thể thử nó và đoán nó với một vài lần thử. Tuy nhiên, nếu chúng tôi muối mật khẩu và nó trở thành fooLegolas thì hàm băm sẽ khác, do đó cuộc tấn công từ điển sẽ không thành công.

Mong rằng sẽ giúp!

Tôi giả sử rằng bạn đang sử dụng hàm PHP --- md5 () và các biến có trước $ --- sau đó, bạn có thể thử xem bài viết này Shadow Password HOWTO Đặc biệt đoạn thứ 11.

Ngoài ra, bạn sợ sử dụng các thuật toán tiêu hóa thông điệp, bạn có thể thử các thuật toán mật mã thực, chẳng hạn như các thuật toán được cung cấp bởi mô-đun mcrypt hoặc các thuật toán tiêu hóa thông điệp mạnh hơn, chẳng hạn như các thuật toán cung cấp mô-đun mhash (sha1, sha256 và khác).

Tôi nghĩ rằng thuật toán tiêu hóa thông điệp mạnh mẽ hơn là phải. Được biết, MD5 và SHA1 đang gặp sự cố va chạm.