Làm thế nào bcrypt có thể tích hợp muối?

Bài viết "Cách lưu trữ mật khẩu an toàn" của Coda Hale tuyên bố rằng:

bcrypt có muối tích hợp để ngăn chặn các cuộc tấn công bảng cầu vồng.

Ông trích dẫn bài báo này , trong đó nói rằng trong triển khai OpenBSD về bcrypt:

OpenBSD tạo ra muối bcrypt 128 bit từ luồng khóa arcfour (arc4random (3)), được gieo bằng dữ liệu ngẫu nhiên mà nhân thu thập từ thời gian của thiết bị.

Tôi không hiểu làm thế nào điều này có thể làm việc. Theo quan niệm của tôi về một loại muối:

• Nó cần phải khác nhau cho mỗi mật khẩu được lưu trữ, để tạo một bảng cầu vồng riêng biệt cho mỗi mật khẩu
• Nó cần được lưu trữ ở một nơi nào đó để có thể lặp lại: khi người dùng cố gắng đăng nhập, chúng tôi sẽ thử mật khẩu của họ, lặp lại quy trình muối và băm giống như khi chúng tôi lưu trữ mật khẩu ban đầu và so sánh

Khi tôi đang sử dụng Devise (trình quản lý đăng nhập Rails) với bcrypt, không có cột muối trong cơ sở dữ liệu, vì vậy tôi bối rối. Nếu muối là ngẫu nhiên và không được lưu trữ ở bất cứ đâu, làm thế nào chúng ta có thể lặp lại đáng tin cậy quá trình băm?

Nói tóm lại, làm thế nào bcrypt có thể tích hợp muối ?

Đây là bcrypt:

Tạo ra một muối ngẫu nhiên. Một yếu tố "chi phí" đã được cấu hình sẵn. Thu thập mật khẩu.

Lấy khóa mã hóa từ mật khẩu bằng cách sử dụng hệ số muối và chi phí. Sử dụng nó để mã hóa một chuỗi nổi tiếng. Lưu trữ chi phí, muối và văn bản mật mã. Bởi vì ba yếu tố này có độ dài đã biết, thật dễ dàng để ghép chúng và lưu trữ chúng trong một trường duy nhất, nhưng vẫn có thể tách chúng ra sau đó.

Khi ai đó cố gắng xác thực, lấy lại chi phí lưu trữ và muối. Lấy một khóa từ mật khẩu đầu vào, chi phí và muối. Mã hóa cùng một chuỗi nổi tiếng. Nếu văn bản mật mã được tạo khớp với văn bản mật mã được lưu trữ, mật khẩu sẽ khớp.

Bcrypt hoạt động theo cách rất giống với các sơ đồ truyền thống hơn dựa trên các thuật toán như PBKDF2. Sự khác biệt chính là việc sử dụng khóa dẫn xuất để mã hóa văn bản thuần túy đã biết; các lược đồ khác (một cách hợp lý) cho rằng hàm dẫn xuất khóa là không thể đảo ngược và lưu trữ khóa dẫn xuất trực tiếp.

Được lưu trữ trong cơ sở dữ liệu, một bcrypt"hàm băm" có thể trông giống như thế này:

$ 2a $ 10 $ vI8aWBnW3fID.ZQ4 / zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa

Đây thực sự là ba trường, được giới hạn bởi "$":

• 2axác định bcryptphiên bản thuật toán đã được sử dụng.
• 10là yếu tố chi phí; 2 ¹⁰ lần lặp của hàm phái sinh chính được sử dụng (bằng cách này là không đủ. Tôi muốn giới thiệu chi phí từ 12 trở lên.)
• vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTalà muối và văn bản mật mã, được nối và mã hóa trong Base-64 được sửa đổi. 22 ký tự đầu tiên giải mã thành giá trị 16 byte cho muối. Các ký tự còn lại là văn bản mật mã được so sánh để xác thực.

Ví dụ này được lấy từ tài liệu để thực hiện viên ruby ​​của Coda Hale.

Tôi tin rằng cụm từ đó nên được diễn đạt như sau:

bcrypt có muối được tích hợp trong các bảng băm được tạo để ngăn chặn các cuộc tấn công bảng cầu vồng.

Các bcrypttiện ích tự nó không xuất hiện để duy trì một danh sách các muối. Thay vào đó, các muối được tạo ngẫu nhiên và gắn vào đầu ra của hàm để chúng được ghi nhớ sau này (theo cách triển khai Javabcrypt ). Nói cách khác, "băm" được tạo ra bcryptkhông chỉ là hàm băm. Thay vào đó, nó là băm và muối kết hợp.

Để làm cho mọi thứ rõ ràng hơn,

Đăng ký / Hướng đăng nhập ->

Mật khẩu + muối được mã hóa bằng một khóa được tạo từ: chi phí, muối và mật khẩu. chúng tôi gọi đó là giá trị mã hóa cipher text. sau đó chúng ta gắn muối vào giá trị này và mã hóa nó bằng base64. đính kèm chi phí cho nó và đây là chuỗi được sản xuất từ bcrypt:

$2a$COST$BASE64

Giá trị này được lưu trữ cuối cùng.

Kẻ tấn công sẽ cần phải làm gì để tìm mật khẩu? (hướng khác <-)

Trong trường hợp kẻ tấn công có quyền kiểm soát DB, kẻ tấn công sẽ giải mã dễ dàng giá trị base64, và sau đó anh ta sẽ có thể nhìn thấy muối. Muối không bí mật. mặc dù nó là ngẫu nhiên Sau đó, anh ta sẽ cần phải giải mã cipher text.

Điều quan trọng hơn: Không có băm trong quá trình này, thay vào đó là mã hóa đắt tiền CPU - giải mã. do đó bảng cầu vồng ít liên quan ở đây.

Đây là từ tài liệu giao diện PasswordEncoder từ Spring Security,

 * @param rawPassword the raw password to encode and match
 * @param encodedPassword the encoded password from storage to compare with
 * @return true if the raw password, after encoding, matches the encoded password from
 * storage
 */
boolean matches(CharSequence rawPassword, String encodedPassword);

Điều đó có nghĩa là, người ta sẽ cần khớp với rawPassword mà người dùng sẽ nhập lại vào lần đăng nhập tiếp theo và khớp với mật khẩu được mã hóa Bcrypt lưu trữ trong cơ sở dữ liệu trong lần đăng nhập / đăng ký trước đó.