Điểm:2

Hàm băm nào đủ tốt cho ID phiên?

lá cờ br

Lý lịch

Tôi đang xây dựng một công cụ rút ngắn URL và URL để rút ngắn có thể chứa một phiên Id.

Để trình rút ngắn URL không ảnh hưởng đến tính bảo mật của SessionId, tôi phải sử dụng chiến lược rút ngắn đáp ứng các yêu cầu tương tự như SessionId.

OWASP tuyên bố rằng:

  • Độ dài ID phiên ít nhất phải bằng 128 bit (16 byte) đây
  • Giá trị ID phiên phải cung cấp ít nhất 64 bit của entropy đây

Những gì tôi nghĩ về việc làm

  • Có kho lưu trữ khóa-giá trị, trong đó giá trị là URL dài (chưa được rút ngắn) và khóa là thành phần URL được rút ngắn.
  • Khi người dùng điều hướng đến một URL rút ngắn, URL dài sẽ được tra cứu trong kho lưu trữ khóa-giá trị và được trả lại cho người dùng, sau đó người dùng này sẽ được chuyển hướng.

Vì vậy, chìa khóa cần phải có ít nhất 128 bit (16 byte) dài, và cung cấp ít nhất 64 bit của entropy, để không ảnh hưởng đến SessionId.

Nếu khóa là hàm băm của giá trị, tôi có thể đảm bảo độ dài của khóa và biết entropy (dựa trên thuật toán băm được sử dụng).

Nhưng tôi nên sử dụng thuật toán băm nào?

Ví dụ: độ dài thông báo MD5 chính xác là 128 bit. Nhưng tôi không biết entropy tối thiểu là bao nhiêu.

Câu hỏi

Thuật toán băm nào tạo ra một bản tóm tắt ít nhất 128 bit, với ít nhất 64 bit entropy?

(bài đăng x từ StackOverflow: https://stackoverflow.com/q/71224441/6517320)

kelalaka avatar
lá cờ in
Bạn có thể duy trì một bản sao câu hỏi của mình không? Vui lòng xem [Đăng chéo một câu hỏi trên nhiều trang web Stack Exchange có được phép không nếu câu hỏi thuộc chủ đề cho từng trang web?](https://meta.stackexchange.com/q/64068/403350) để biết chi tiết.
kelalaka avatar
lá cờ in
Lưu ý rằng entropy không phải là thuộc tính của giá trị/dữ liệu mà nó là thuộc tính của nguồn.Nhận ngẫu nhiên thống nhất về kích thước 64-bit và băm nó và cắt bớt thành 128-bit. Sử dụng BLAKE2 làm hàm băm mật mã nhanh nhất mặc dù bạn không cần...
Điểm:5
lá cờ cn

Câu trả lời ngắn gọn cho câu hỏi băm của bạn là "sử dụng SHA-256." Đó là câu trả lời cho hầu hết mọi vấn đề về băm an toàn, trừ khi câu trả lời là "sử dụng SHA-512." Nếu bạn muốn hàm băm 128 bit, thì bạn có thể cắt bớt SHA-256 (lấy 128 lần cắn đầu tiên hoặc cuối cùng). Tất cả các bit trong SHA-256 đều độc lập, vì vậy bạn có thể trích xuất 128 bit bất kỳ dưới dạng hàm băm.

Điều đó nói rằng, IMO bạn đang nghĩ về vấn đề này không chính xác. Vấn đề không phải là bảo vệ SessionId một cách cụ thể.Vấn đề là các URL có thể chứa thông tin nhạy cảm, trong đó SessionId chỉ là một ví dụ (nếu nó được lưu trữ trong URL). Nếu ai đó đã biết URL rút gọn, họ có thể yêu cầu hệ thống của bạn cung cấp URL đầy đủ, vì vậy, đây là tất cả về việc ngăn chặn những kẻ tấn công tìm khóa bằng cách đoán. Bạn cần làm cho không gian khóa của mình trở nên thưa thớt, nghĩa là "lớn hơn rất nhiều so với số lượng khóa thực sự được lưu trữ."

Bạn đang duy trì cơ sở dữ liệu khóa/giá trị, vì vậy không cần sử dụng hàm băm nào cả. Bạn chỉ có thể tạo một khóa ngẫu nhiên cho mỗi URL. Điều này tốt hơn hàm băm vì hoàn toàn không có kết nối nào giữa khóa và giá trị.

Với thiết kế của bạn, kẻ tấn công không thể tìm kiếm ngoại tuyến. Họ phải liên hệ với máy chủ của bạn. Giả sử bạn có thể phân phát 1.000 yêu cầu/giây và bạn mở rộng tổng không gian khóa của mình lớn hơn một nghìn tỷ lần so với số lượng URL dự kiến. Điều đó sẽ khiến kẻ tấn công mất khoảng 15.000 năm (~ 1/2 không gian được tìm kiếm) để tìm một URL duy nhất nếu chúng có thể sử dụng tất cả băng thông có sẵn của bạn (điều mà tôi mong bạn có thể nhận thấy....). Chỉ với một chút giới hạn tốc độ cho mỗi địa chỉ IP, bạn có thể làm phức tạp cuộc tấn công này một cách đáng kể.

Với những điều trên, nếu bạn muốn lưu trữ một tỷ URL trong hệ thống của mình, bạn cần có một không gian khóa là:

log2(1 tỷ URL * 1 nghìn tỷ hệ số) = 80 bit

Trong Base58 (mà tôi thích cho loại vấn đề này vì nó thân thiện với con người), nó sẽ mất khoảng 14 ký tự. Tinh chỉnh các giá trị trên để giới hạn tốc độ, thời gian tấn công bạn muốn bảo vệ và số lượng URL được lưu trữ, bạn có thể chọn thời lượng khóa của mình.

Nói chung, bạn có thể tính toán các giá trị ngẫu nhiên trên thang đo này mà không phải lo lắng về xung đột (điều này tốt cho hiệu suất). Vì lý do tương tự mà kẻ tấn công cực kỳ khó tìm thấy một vụ va chạm, nên việc bạn vô tình gặp phải một vụ va chạm là điều cực kỳ khó xảy ra. Nhưng nếu bạn muốn kiểm tra lại chỉ thế nào không chắc, nhìn vào tấn công sinh nhật. Các tính toán cho "khả năng xảy ra xung đột của bất kỳ giá trị nào" khác với "kẻ tấn công sẽ mất bao lâu để tìm thấy xung đột" và trong một số trường hợp sẽ buộc bạn phải sử dụng các phím dài hơn.

IMO không cần băm. Nhưng nếu bạn cần một cái, hãy sử dụng SHA-256, được cắt bớt thành bất kỳ số lượng bit nào bạn muốn.

Ivan Rubinson avatar
lá cờ br
Làm thế nào điều này đảm bảo ít nhất 64 bit entropy?
lá cờ cn
Điều đó phụ thuộc vào PRNG của bạn. Trên các hệ thống Linux, nếu bạn sử dụng/dev/ngẫu nhiên, tôi tin rằng nó sẽ chặn nếu hệ thống giảm xuống dưới 160 bit entropy khả dụng, vì vậy bạn phải luôn ổn trên loại hệ thống đó. Tôi mong đợi bất kỳ hệ thống nào bạn sử dụng PRNG mật mã sẽ vượt quá 64 bit cho mọi giá trị, nhưng bạn sẽ phải kiểm tra tài liệu của mình để chắc chắn. Ví dụ: trên một số (nhưng không phải tất cả) hệ thống /dev/urandom sẽ trả về giá trị entropy thấp.
lá cờ cn
Nhưng không có hàm băm nào có thể làm tăng entropy và nếu chúng có khả năng chống va chạm trong không gian được đề cập, thì chúng sẽ không (hiệu quả) làm giảm entropy. Entropy từ SessionId ban đầu sẽ được lưu giữ bởi bất kỳ hàm băm mật mã nào. Nếu ban đầu nó có ít hơn 64 bit thì hàm băm cũng vậy và nếu nó có nhiều hơn 64 bit thì hàm băm cũng vậy (trừ đi một chút). Để tăng entropy, bạn phải thêm một loại muối ngẫu nhiên, nghĩa là bạn bị ràng buộc với entropy của PRNG (giống như sử dụng khóa ngẫu nhiên). https://crypto.stackexchange.com/questions/12505/what-happens-to-entropy-after-hashing
Ivan Rubinson avatar
lá cờ br
Vì vậy, entropy của hàm băm = entropy của bản rõ. Do đó để đảm bảo đủ entropy, bản rõ cần phải có entropy cao. URL dài có entropy thấp, trái ngược với chuỗi byte giả ngẫu nhiên mạnh về mặt mật mã; đó là lý do tại sao bạn đề xuất khóa không phải là hàm băm của URL dài.
lá cờ cn
Đóng, nhưng entropy của hàm băm không bao giờ lớn hơn entropy của văn bản gốc. Băm chống va chạm chỉ làm giảm entropy ít hơn (thường là một lượng không quan trọng). Phần còn lại của nhận xét của bạn là chính xác.
Ivan Rubinson avatar
lá cờ br
Thứ lỗi cho ký hiệu khó hiểu. Nếu `A = B` thì `A > B` là không thể. Bởi vì băm không thể tăng entropy, nhưng có thể làm giảm entropy, chúng tôi không thể kiếm được từ băm, mà chỉ mất
SAI Peregrinus avatar
lá cờ si
"Trên các hệ thống Linux, nếu bạn sử dụng/dev/ngẫu nhiên, tôi tin rằng nó sẽ chặn nếu hệ thống giảm xuống dưới 160 bit entropy khả dụng" Điều đó đã không đúng trong một thời gian. Điều đó không quan trọng, nhưng nó chỉ chặn khi khởi động sớm và sau đó không bao giờ nữa. Entropy không "được sử dụng hết", vì vậy việc chặn sau khi gieo hạt không bao giờ giúp được gì.
lá cờ cn
Cảm ơn @SAIPeregrinus. Lâu rồi em không làm sysadmin cho Linux :D Bác nào có link về tình hình hiện tại của Linux để em học hỏi thêm được không? (Bộ não mật mã của tôi hoàn toàn hiểu ý của bạn; tôi chỉ muốn phía quản trị hệ thống của mình hiểu điều gì xảy ra trong thực tế.)
kelalaka avatar
lá cờ in
[Có vấn đề gì khi sử dụng /dev/urandom của Linux để tạo khóa mật mã?](https://crypto.stackexchange.com/q/85533/18298)
SAI Peregrinus avatar
lá cờ si
Ngoài ra, hãy xem [bài viết LWN này](https://lwn.net/SubscriberLink/884875/650dde925be055a1/) về bản vá được đề xuất để thống nhất hành vi của /dev/random và /dev/urandom và getrandom(flags=0).
Ivan Rubinson avatar
lá cờ br
Đó là nói nhiều về cách Linux xử lý CSPRNG. Còn Windows thì sao?

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.