it-swarm-vi.com

Mật khẩu HMAC-ed có an toàn hơn mật khẩu bcrypt-ed hoặc scrypt-ed không?

Đưa ra một tùy chọn, tôi nên chọn cái nào, một HMAC để lưu trữ mật khẩu an toàn hoặc thư viện bcrypt hoặc scrypt?

25
user917279

Để cung cấp cho bạn một ý tưởng đúng đắn về các vấn đề và sự tinh tế của băm mật khẩu máy tính, cũng như lý do tại sao HMAC không phù hợp với vấn đề này, tôi sẽ cung cấp một câu trả lời rộng hơn nhiều so với thực sự cần thiết để trả lời trực tiếp câu hỏi.

Thuật toán băm HMAC về cơ bản chỉ là một phiên bản có khóa của thuật toán băm thông thường. Nó thường được sử dụng để xác minh tính toàn vẹn và tính xác thực. Ký hiệu thông thường của cái này là H(m,k) = h, trong đó H là thuật toán băm HMAC, m là thông báo, k là khóa và h là hàm băm kết quả. Ý tưởng là hai bên có chung một bí mật k có thể xác minh rằng người kia là tác giả của m. Hơn nữa, kẻ tấn công không thể giả mạo hàm băm tin nhắn mà không biết k.

Điều này được thực hiện như sau:

  1. Cả Alice và Bob đều biết một khóa bí mật chung k.
  2. Alice viết một tin nhắn m và tính toán hàm băm HMAC của nó bằng cách sử dụng k, tức là H(m,k) = h.
  3. Alice gửi tin nhắn m và băm h cho Bob.
  4. Bob tính H(m,k) và so sánh nó với hàm băm h mà Alice đã gửi. Nếu giá trị băm khớp, anh ta biết rằng Alice đã gửi tin nhắn và nó không bị thay đổi sau khi cô băm nó.

Bây giờ bạn đã hiểu HMAC là gì, hãy chuyển sang những gì bạn thực sự muốn làm - lưu trữ mật khẩu trong cơ sở dữ liệu.

Nhiều năm trước, việc lưu trữ mật khẩu trong văn bản gốc trong cơ sở dữ liệu là thông lệ tiêu chuẩn. Đây là một ý tưởng tồi bởi vì, khi cơ sở dữ liệu bị xâm phạm, kẻ tấn công đã lấy được tất cả mật khẩu. Để chống lại điều này, chúng tôi đã bắt đầu băm mật khẩu trong cơ sở dữ liệu bằng thuật toán băm mật mã một chiều. MD5 trở nên phổ biến, nhưng điểm yếu (va chạm, tiền đề một phần, v.v.) được phát hiện trong đó có nghĩa là nó không còn được khuyến khích. Rất nhiều người chuyển sang SHA1, an toàn hơn.

Vấn đề với cách tiếp cận này là có thể xây dựng một bảng băm lớn và các bản rõ tương ứng của chúng. Chúng được gọi là bảng Rainbow . Họ làm việc dựa trên khái niệm rằng sẽ hiệu quả hơn khi tính toán một danh sách băm lớn cho tất cả các mật khẩu có thể (trong một bộ nhất định) và sau đó lưu trữ nó, vì vậy nó có thể được truy vấn nhanh chóng sau đó. Vì vậy, thay vì băm buộc các băm riêng lẻ, có thể chỉ cần truy vấn cơ sở dữ liệu để băm và trả lại văn bản gốc của nó ngay lập tức.

Để khắc phục điều này, mọt sách bảo mật đã phát minh ra muối. Muối là giá trị ngẫu nhiên lớn duy nhất được gắn vào mật khẩu trước khi chúng được băm. Muối này được lưu trữ với hàm băm, để nó có thể được tính lại sau. Vì vậy, chúng tôi tính toán H(m+s) = h, sau đó lưu trữ hs trong cơ sở dữ liệu. Điều này cung cấp đáng kể bảo vệ chống lại các bảng Rainbow vì về cơ bản nó yêu cầu một bảng Rainbow riêng biệt được tạo cho mỗi muối.

Vì vậy, những kẻ xấu đã quay trở lại các cuộc tấn công từ điển và bẻ khóa vũ phu. Với sự ra đời của điện toán GPU, người ta có thể tính toán hàng tỷ băm mỗi giây trên một card đồ họa mạnh vừa phải. Trên thực tế, mọi người đã xây dựng các máy tính có thể tính toán gần 50 tỷ băm MD5 mỗi giây - khá ấn tượng/đáng sợ. Lý do GPU có khả năng này là vì chúng được thiết kế để thực hiện một số lượng lớn các hoạt động vô hướng song song. Các phép toán vô hướng là các phép toán và logic không liên quan đến các nhánh - tức là chúng không cần thực hiện nhiều/bất kỳ "nếu x thì làm y". Các thuật toán băm mật mã có xu hướng phù hợp với mô hình này.

Để làm cho điều này trở nên khó khăn, chúng ta phải làm cho hoạt động băm đủ chậm để làm cho vũ phu buộc không thể thực hiện được. Các thuật toán băm thông thường (ví dụ: SHA1) được thiết kế nhanh, khiến chúng không phù hợp với mục đích này. HMAC thêm rất ít chi phí và không có giới hạn bảo mật bổ sung, vì vậy nó cũng không được sử dụng nhiều ở đây.

Tạo một thuật toán băm mật mã chậm thì nói dễ hơn làm - rất khó để đưa ra một thuật toán chậm, không thể thực hiện được (tức là không thể tối ưu hóa ngoài trạng thái hiện tại) và an toàn. Có ba hàm băm phổ biến có thể làm điều này: PBKDF2 , bcryptscrypt . Chúng được gọi là các hàm dẫn xuất khóa thích ứng, bởi vì chúng chấp nhận một giá trị yếu tố công việc cùng với bản rõ và muối. Yếu tố công việc thay đổi lượng thời gian cần thiết để tính toán hàm băm và được thiết kế để bảo vệ chống lại các cải tiến phần cứng trong tương lai.

Vì vậy, đối với thuật toán phái sinh khóa thích ứng H, chúng tôi tính H(m,s,w) = h, trong đó m là thông điệp (mật khẩu), s là muối và w là yếu tố công việc. Kết quả h thường chứa sw, để sau đó một hàm xác minh có thể tính toán cùng một hàm băm bằng cách sử dụng cùng một tham số. Yếu tố công việc thường kiểm soát số lần lặp được thực hiện của một nguyên thủy mã hóa nội bộ. Mục tiêu là làm cho việc tính toán mất nhiều thời gian để khiến việc bẻ khóa trở nên không khả thi, nhưng không vượt quá các tài nguyên mà chúng ta có.

Để cung cấp bảo mật hơn đối với việc bẻ khóa dựa trên phần cứng chuyên dụng, scrypt đảm bảo rằng tính toán băm là cả CPU và cứng bộ nhớ, tức là nó đòi hỏi tài nguyên CPU và bộ nhớ đáng kể để tạo ra giá trị băm. Điều này rất quan trọng, bởi vì FPGA thường có quyền truy cập vào rất ít bộ nhớ tức thời.

Bây giờ, câu hỏi rõ ràng được đặt ra: nếu tôi thiết lập trang web của mình để sử dụng bcrypt, điều đó có nghĩa là máy chủ của tôi phải tính băm nhiều CPU không? Chà, nếu bạn chạy chúng trên máy chủ của mình, thì đúng vậy, đó là điều cần xem xét. Một giải pháp tốt hơn là để khách hàng tính toán hàm băm, sau đó gửi nó đến máy chủ qua SSL. Sau đó, máy chủ có thể so sánh nó với giá trị trong cơ sở dữ liệu. Điều này đảm bảo rằng hàm băm mật khẩu có thể dễ dàng bị bẻ khóa nếu bị đánh cắp (ví dụ: thông qua thỏa hiệp cơ sở dữ liệu) và máy chủ của bạn không bị quá tải bởi tính toán băm mật khẩu. Đối với các trang web, bạn có thể sử dụng jsBcrypt .  Cập nhật: Phương pháp này đã được chỉ ra là thiếu sót bởi một người bình luận bên dưới. Đừng sử dụng nó.

Hy vọng rằng điều này cung cấp cho bạn một cái nhìn tổng quan tốt về tình huống này và tại sao HMAC không phù hợp với loại sử dụng này.

37
Polynomial

HMAC là một mã xác thực tin nhắn ; nó sử dụng một chìa khóa. Bcrypt không. Như vậy, sự lựa chọn không phải là trung lập; bạn không thể nghĩ về tất cả mọi thứ bằng nhau, bởi vì chúng không phải là.

Mặc dù trên danh nghĩa để kiểm tra tính toàn vẹn, nhưng thực tế là HMAC (khi được sử dụng với hàm băm an toàn hợp lý, ví dụ: SHA-256 hoặc thậm chí SHA-1) hoạt động theo cách nào đó giống như "hàm băm có khóa". Đây không phải là thuộc tính chung của thuật toán MAC, nhưng nó hoạt động với HMAC (đó là lý do tại sao nó có thể được sử dụng làm cơ sở cho một trình tạo ngẫu nhiên có tên Hmac_DRBG ). Điều này làm cho HMAC trở thành một lựa chọn tiềm năng cho việc băm mật khẩu.

Nếu bạn "băm" mật khẩu của mình bằng HMAC và kẻ tấn công có thể lấy tệp/cơ sở dữ liệu mật khẩu băm của bạn nhưng không phải là khóa HMAC , thì kẻ tấn công sẽ không thể bẻ khóa mật khẩu. Trong kịch bản đó, HMAC "tốt hơn" bcrypt/scrypt. Tuy nhiên, đây là một trường hợp Edge. Chúng tôi băm mật khẩu vì chúng tôi lo lắng về các tình huống bên lề trong đó kẻ tấn công could vi phạm bảo mật đủ để có được một chỉ đọc truy cập vào một phần của tệp máy chủ, nhưng không a đọc-ghi truy cập. Phương thức băm với HMAC dành cho kịch bản bình phương, trong đó kẻ tấn công chỉ đọc có thể lấy mật khẩu băm nhưng không phải là khóa, dù sao cũng được lưu trữ trên cùng một máy chủ.

Nếu kẻ tấn công có thể lấy được khóa, thì HMAC chỉ trở thành một hàm băm đơn giản cho anh ta, và trong trường hợp đó, HMAC tệ hơn nhiều so với bcrypt, bởi vì nó là không được bảo vệ quá chết tiệt nhanh. Nó giống như nếu mật khẩu được băm bằng một cặp lệnh SHA-1. Kịch bản đó không ít khả năng xảy ra so với trước đó và do đó chúng ta phải xem xét việc sử dụng HMAC một mình là quá rủi ro .


Để có kết quả tốt nhất của cả hai thế giới , hãy áp dụng HMAC trên mật khẩu người dùng, và sau đó xử lý đầu ra HMAC thông qua - bcrypt ; bạn sẽ lưu trữ đầu ra của bcrypt. Vì việc triển khai bcrypt mong muốn mật khẩu là a chuỗi ký tự, nên bạn sẽ phải mã hóa đầu ra HMAC (hexadecimal, Base64 ...).

Điều này phức tạp hơn bcrypt một mình, vì sử dụng hai chức năng thay vì một và vì khóa (điều này mang đến toàn bộ vấn đề nhức nhối của quản lý khóa: tạo, lưu trữ, sao lưu ...). Vì sự phức tạp là xấu, tôi sẽ khuyên bạn nên chống lại nó; chỉ cần sử dụng bcrypt một mình và không thêm HMAC. Tuy nhiên, đây là cuộc gọi của bạn; nếu bạn thực sự muốn HMAC, hãy sử dụng nó ngoài bcrypt, không thay vì bcrypt.

(Lưu ý: đó là bcrypt trên đầu ra HMAC, không phải theo cách khác, sẽ không hoạt động vì muối được bao gồm trong đầu ra bcrypt.)

9
Thomas Pornin

HMAC được thiết kế rất nhanh và trong bối cảnh này là một cách tốt để thêm muối vào mật khẩu thay vì chỉ thêm nó. Bcrypt chậm hơn nhiều do khởi tạo chậm, trong khi tiền điện tử thậm chí còn chậm hơn Bcrypt vì nó được thiết kế có chủ ý theo cách như vậy. Scrypt được thiết kế để làm cho vũ phu buộc nó rất tốn kém về mặt tính toán. Nó tiêu tốn rất nhiều CPU, bộ nhớ và cũng chậm sử dụng trên GPU.

Tìm hiểu thêm về tiền điện tử

2
Matrix