it-swarm-vi.com

Số lần lặp được đề xuất khi sử dụng PKBDF2-SHA256?

Tôi tò mò liệu có ai có bất kỳ lời khuyên hay điểm tham chiếu nào khi xác định có bao nhiêu lần lặp là 'đủ tốt' khi sử dụng PBKDF2 (cụ thể là với SHA-256). Chắc chắn, "đủ tốt" là chủ quan và khó xác định, thay đổi theo hồ sơ ứng dụng và rủi ro, và "đủ tốt" hôm nay có thể không "đủ tốt" vào ngày mai ...

Nhưng câu hỏi vẫn còn, ngành công nghiệp hiện đang nghĩ 'đủ tốt' là gì? Những điểm tham chiếu có sẵn để so sánh?

Một số tài liệu tham khảo tôi đã định vị:

  • Tháng 9 năm 2000 - 1000+ vòng được đề xuất (nguồn: RFC 2898)
  • Tháng 2 năm 2005 - AES trong Kerberos 5 'mặc định' tới 4096 vòng SHA-1. (nguồn: RFC 3962)
  • Tháng 9 năm 2010 - ElcomSoft tuyên bố iOS 3.x sử dụng 2.000 lần lặp, iOS 4.x sử dụng 10.000 lần lặp, cho thấy BlackBerry sử dụng 1 (thuật toán băm chính xác không được nêu) (nguồn: ElcomSoft )
  • Tháng 5 năm 2011 - LastPass sử dụng 100.000 lần lặp SHA-256 (nguồn: LastPass )
  • Tháng 6 năm 2015 - StableBit sử dụng 200.000 lần lặp SHA-512 (nguồn: StableBit CloudDrive Nuts & Bolts )
  • Tháng 8 năm 2015 - Cloud tweet sử dụng 1.000 lần lặp SHA-1 (nguồn: Xem xét bảo mật trong phòng thí nghiệm của Cloud BlackBerry (pdf) )

Tôi đánh giá cao bất kỳ tài liệu tham khảo hoặc phản hồi bổ sung nào về cách bạn xác định số lần lặp là "đủ tốt" cho ứng dụng của bạn.

Là nền tảng bổ sung, tôi đang xem xét PBKDF2-SHA256 là phương pháp được sử dụng để băm mật khẩu người dùng để lưu trữ cho một trang web có ý thức bảo mật. Muối PBKDF2 theo kế hoạch của tôi là: một loại muối ngẫu nhiên cho mỗi người dùng (được lưu trữ rõ ràng với mỗi hồ sơ người dùng) XOR'ed với một loại muối toàn cầu. Mục tiêu là để tăng chi phí cho việc bắt buộc mật khẩu và tránh tiết lộ các cặp người dùng có mật khẩu giống hệt nhau.

Người giới thiệu:

  • RFC 2898: PKCS # 5: Đặc tả mật mã dựa trên mật khẩu v2.0
  • RFC 3962: Mã hóa tiêu chuẩn mã hóa nâng cao (AES) cho Kerberos 5
  • PBKDF2: Hàm dẫn xuất khóa dựa trên mật khẩu v2
195
Tails

Bạn nên sử dụng số lượng vòng tối đa có thể chấp nhận được, hiệu suất khôn ngoan, trong ứng dụng của bạn. Số lượng vòng là một yếu tố làm chậm, mà bạn sử dụng trên cơ sở rằng trong điều kiện sử dụng bình thường, sự chậm lại như vậy có tác động không đáng kể đối với bạn (người dùng sẽ không thấy điều đó, chi phí CPU thêm không có nghĩa là mua một máy chủ lớn hơn và Sớm). Điều này phụ thuộc rất nhiều vào bối cảnh hoạt động: máy móc có liên quan gì, có bao nhiêu xác thực người dùng mỗi giây ... vì vậy không có phản hồi một kích cỡ phù hợp với tất cả.

Bức tranh rộng như vậy:

  • Thời gian để xác minh một mật khẩu duy nhất là v trên hệ thống của bạn. Bạn có thể điều chỉnh thời gian này bằng cách chọn số vòng trong PBKDF2.
  • Kẻ tấn công tiềm năng có thể thu thập f nhiều lần sức mạnh CPU hơn bạn (ví dụ: bạn có một máy chủ và kẻ tấn công có 100 PC lớn, mỗi máy tính nhanh hơn hai lần so với máy chủ của bạn: điều này dẫn đến f = 200).
  • Người dùng trung bình có mật khẩu entropy n bit (điều này có nghĩa là cố gắng đoán mật khẩu người dùng, với một từ điển "mật khẩu hợp lý", sẽ lấy trung bình 2n-1 cố gắng).
  • Kẻ tấn công sẽ thấy hệ thống của bạn đáng bị tấn công nếu mật khẩu trung bình có thể bị bẻ khóa kịp thời ít hơn p (đó là "sự kiên nhẫn" của kẻ tấn công).

Mục tiêu của bạn là làm cho chi phí trung bình để phá vỡ một mật khẩu vượt quá sự kiên nhẫn của kẻ tấn công, để anh ta thậm chí không thử, và tiếp tục tập trung vào một mục tiêu khác dễ dàng hơn. Với các ký hiệu chi tiết ở trên, điều này có nghĩa là bạn muốn:

v · 2n-1 > f · p

p nằm ngoài tầm kiểm soát của bạn; nó có thể được ước tính liên quan đến value của dữ liệu và hệ thống được bảo vệ bởi mật khẩu người dùng. Giả sử p là một tháng (nếu mất hơn một tháng, kẻ tấn công sẽ không buồn cố gắng). Bạn có thể tạo f nhỏ hơn bằng cách mua máy chủ lớn hơn; mặt khác, kẻ tấn công sẽ cố gắng thực hiện f lớn hơn bằng cách mua các máy lớn hơn. Một điểm trầm trọng hơn là việc bẻ khóa mật khẩu là một nhiệm vụ lúng túng song song , vì vậy kẻ tấn công sẽ nhận được một sự thúc đẩy lớn bằng cách sử dụng GPU hỗ trợ lập trình chung ; vì vậy, một f sẽ vẫn nằm trong khoảng vài trăm.

n liên quan đến chất lượng của mật khẩu, bằng cách nào đó bạn có thể ảnh hưởng thông qua chính sách chọn mật khẩu nghiêm ngặt, nhưng thực tế bạn sẽ khó có được giá trị n ngoài, giả sử, 32 bit. Nếu bạn cố gắng thực thi mật khẩu mạnh hơn, người dùng sẽ bắt đầu chủ động chống lại bạn, với các cách giải quyết như sử dụng lại mật khẩu từ nơi khác, viết mật khẩu vào ghi chú dán, v.v.

Vậy tham số còn lại là v. Với f = 200 (kẻ tấn công có hàng tá GPU tốt), kiên nhẫn trong một tháng và n = 32, bạn cần v để có ít nhất 241 mili giây (lưu ý: Ban đầu tôi đã viết "8 mili giây" ở đây, điều này là sai - đây là con số cho sự kiên nhẫn của một ngày thay vì một tháng). Vì vậy, bạn nên đặt số vòng trong PBKDF2 sao cho việc tính toán nó qua một mật khẩu sẽ mất ít nhất thời gian đó trên máy chủ của bạn. Bạn vẫn có thể xác minh bốn mật khẩu mỗi giây với một lõi, do đó tác động của CPU có thể không đáng kể (*). Trên thực tế, an toàn hơn khi sử dụng nhiều vòng hơn thế, bởi vì, hãy đối mặt với nó, nhận được entropy trị giá 32 bit từ mật khẩu người dùng trung bình là một chút lạc quan; mặt khác, không có nhiều cuộc tấn công sẽ dành hàng tá PC trong một tháng cho nhiệm vụ bẻ khóa một mật khẩu, do đó, có thể "sự kiên nhẫn của kẻ tấn công" trong một ngày là thực tế hơn, dẫn đến chi phí xác minh mật khẩu là 8 mili giây.

Vì vậy, bạn cần phải làm cho một vài điểm chuẩn. Ngoài ra, phần trên hoạt động miễn là việc triển khai PBKDF2/SHA-256 của bạn nhanh. Chẳng hạn, nếu bạn sử dụng triển khai hoàn toàn dựa trên C #/Java, bạn sẽ nhận được hệ số làm chậm 2 đến 3 điển hình (so với C hoặc hội) cho các tác vụ thâm dụng CPU; trong các ký hiệu ở trên, điều này tương đương với nhân f với 2 hoặc 3. Như một đường cơ sở so sánh, CPU Core2 2,4 GHz có thể thực hiện khoảng 2,3 triệu phép tính SHA-256 cơ bản mỗi giây (với một lõi đơn), do đó, điều này sẽ ngụ ý, trên CPU đó, khoảng 20000 vòng để đạt được mục tiêu "8 mili giây".


(*) Cẩn thận rằng việc xác minh mật khẩu đắt hơn cũng khiến máy chủ của bạn dễ bị tấn công hơn Tấn công từ chối dịch vụ . Bạn nên áp dụng một số biện pháp đối phó cơ bản, chẳng hạn như tạm thời liệt kê các địa chỉ IP của máy khách gửi quá nhiều yêu cầu mỗi giây. Dù sao thì bạn cũng cần phải làm điều đó, để ngăn chặn trực tuyến tấn công từ điển.

230
Thomas Pornin

Chạy openssl speed trên dòng lệnh để có được ý tưởng về chức năng tiêu hóa thư nhanh như thế nào. Tôi có thể tính toán khoảng 1,6 triệu sha256 băm một giây hoặc khoảng 145 Tỷ dự đoán mỗi ngày trên cầu Sandy 2.2ghz lõi tứ của tôi. Nếu ai đó có mật khẩu trong từ điển tiếng Anh và sử dụng một vòng sha256 thì sẽ mất nhiều thời gian hơn để tải danh sách Word ra khỏi đĩa hơn là lặp lại danh sách để phá vỡ hàm băm. Nếu bạn đã thực hiện PKBDF2-SHA256 với vài trăm nghìn vòng thì sẽ mất vài phút để phá vỡ. Thực thi chính sách mật khẩu mạnh sẽ giúp, rất nhiề.

Câu trả lời thực sự: Bạn phải đốt bao nhiêu thời gian?

32
rook

Câu trả lời của Thomas cung cấp một mô hình cơ sở và dữ liệu hữu ích. Nhưng mục tiêu mà anh ấy đặt ra không có ý nghĩa với tôi. Một kẻ tấn công thông thường sẽ không biết số lần lặp của bạn cho đến khi thực sự hack trang web và lấy cơ sở dữ liệu băm. Làm xong việc đó, họ sẽ không tiến lên chỉ vì bạn sử dụng số lần lặp lớn. Họ sẽ cố gắng bẻ khóa càng nhiều càng tốt, và hoàn toàn có thể công khai băm để những người khác sẽ tiếp tục cố gắng bẻ khóa chúng trong nhiều năm để đi kèm với phần cứng ngày càng mạnh hơn. Vì vậy, "p" và "f" sẽ tiếp tục tăng lâu sau vụ hack.

Ngoài ra, mật khẩu người dùng thực không được mô hình hóa tốt bằng một biện pháp phức tạp như 32 bit của entropy. Bài viết Bảo mật tái sử dụng: Tài liệu mới về số liệu bảo mật mật khẩ rất hữu ích trong vấn đề này và là tài liệu mà chúng ta đã biết từ lâu: nhiều người dùng chọn mật khẩu dễ đoán và có một cái đuôi dài. Điều này cũng có nghĩa là những kẻ tấn công sẽ luôn tìm thấy một số nếu họ cố gắng hết sức.

Tôi muốn nói rằng một mục tiêu có nhiều khả năng sẽ là bảo vệ càng nhiều phần trăm người dùng của bạn càng tốt khỏi việc mật khẩu của họ bị bẻ khóa. Ví dụ. bảng 4.2.1 của PDF cho thấy rằng nếu bạn quản lý để hạn chế kẻ tấn công của mình trong một số chiến dịch tấn công từ trung bình 1 triệu lần thử mỗi lần băm xuống còn 500.000 lần , bạn có thể bảo vệ mật khẩu của 5% người dùng của mình (giả sử hỗn hợp có nhiều mật khẩu 7 ký tự hơn 8+ mật khẩu, do đó giảm tỷ lệ bẻ khóa từ 35% xuống 30%). Tất nhiên hình dạng chính xác của đường cong và vị trí của chúng trên đó sẽ rất khác nhau.

Vì vậy, tôi chỉ cần tính số lần lặp tối đa mà bạn có thể lập ngân sách, miễn là nó không trì hoãn người dùng thực sự đăng nhập bình thường. Và bạn nên tăng giá trị khi khả năng tính toán của bạn tăng lên qua các năm.

17
nealmcb

Một cỗ máy hiện đại được tạo ra với 8 GPU thế hệ hiện tại sẽ tính toán theo thứ tự 9 tỷ băm SHA-256 mỗi giây, hoặc khoảng 777 tỷ băm mỗi ngày và những GPU đó có thể thực hiện các cuộc tấn công từ điển dựa trên quy tắc.

0
ModernMachine

Hãy coi đây là một nhận xét rất dài. Tôi tò mò về việc các công cụ chạy trên máy tính xách tay cá nhân của tôi nhanh như thế nào (Thinkpad T460p, Intel i7-6700HQ ). Tôi biết rằng để bẻ khóa mật khẩu muối, có những thiết bị đặc biệt, nhưng nếu bạn có một dịch vụ web, bạn có thể không có phần cứng đặc biệt cho điều đó.

Những kết quả đánh giá

Mặc định của werkzeug.security.generate_password_hash hiện tại (2019-06-01) là pbkdf2:sha256:150000.

Như bạn có thể thấy, thời gian thực hiện tăng tuyến tính với số vòng/lần lặp. Điều này có nghĩa là mặc định mất khoảng 281ms trong máy của tôi.

enter image description here

enter image description here

sha512,     1 iteration : min:   67.1μs, mean:    72.2μs, max:   310.9μs
sha512, 15000 iteration: min: 38462.8μs, mean: 40291.2μs, max: 44842.4μs
sha256, 15000 iteration: min: 27167.6μs, mean: 28118.0μs, max: 30826.0μs
sha512,  1000 iteration: min:  2636.7μs, mean:  2694.3μs, max:  3579.0μs
sha256,  1000 iteration: min:  1870.7μs, mean:  1888.8μs, max:  2477.0μs
md5,    15000 iteration: min: 21126.2μs, mean: 21864.8μs, max: 23799.3μs
sha512,     1 iteration : min:   23.4μs, mean:    26.9μs, max:    40.6μs
sha512,  1000 iteration: min:  2586.7μs, mean:  2761.1μs, max:  3120.6μs
sha256,  1000 iteration: min:  1823.3μs, mean:  1834.6μs, max:  2008.5μs
sha512, 15000 iteration: min: 38507.9μs, mean: 40210.8μs, max: 47430.3μs
sha256, 15000 iteration: min: 27257.1μs, mean: 28454.0μs, max: 31213.5μs
md5,    15000 iteration: min: 21219.9μs, mean: 21842.4μs, max: 24305.0μs

0
Martin Thoma