Điểm:2

Tôi có nên sử dụng HMAC để tạo mã thông báo HASH nhiều phần không

lá cờ jp

Tôi có một API web với hệ thống xác thực API tùy chỉnh mà mỗi người dùng có một Chìa khoá bí mật và công chúng Mã API. Sử dụng hai khóa này, máy khách (hoặc người dùng) có thể tạo mã thông báo để xác thực trên máy chủ.

Xem xét chức năng này tạo mã thông báo xác thực

chuỗi công khai GetToken(chuỗi apiKey, chuỗi secretKey, chuỗi hết hạn Dấu thời gian)
{
    sử dụng var hashAlgorithm = SHA256.Create();
    var byteValue = Encoding.UTF8.GetBytes(apiKey + secretKey + expireTimestamp)
    var byteHash = hashAlgorithm.ComputeHash(byteValue)
    trả lại Convert.ToBase64String(byteHash) + dấu thời gian hết hạn
}

Vì vậy, một mã thông báo là sự kết hợp của

$$token = SHA256(APIKey \mathbin\| SecretKey \mathbin\| expireTimestamp) \mathbin\| hết hạnDấu thời gian$$

Sử dụng mã thông báo này, chúng tôi có một hệ thống xác thực có thể hết hạn duy nhất cho các API của mình,

câu hỏi:

  1. Tôi có nên nối khóa+expTime hay tôi nên sử dụng thứ gì đó như HMAC? kịch bản này có dễ bị tấn công như cuộc tấn công mở rộng chiều dài không có HMAC?
  2. Lỗ hổng của hệ thống này (nếu có) là gì?
fgrieu avatar
lá cờ ng
Nhận xét không dành cho thảo luận mở rộng; họ đã được [chuyển sang trò chuyện](https://chat.stackexchange.com/rooms/132054/discussion-on-question-by-alireza-nên-i-use-hmac-to-create-a-multiple-part -ha).
Điểm:2
lá cờ in

sử dụng $$token = SHA256(APIKey \mathbin\| SecretKey \mathbin\| expireTimestamp) \mathbin\| hết hạnDấu thời gian$$

không an toàn vì nó có thể gây ra một cuộc tấn công kéo dài như;

$$token2 = SHA256(APIKey \mathbin\| SecretKey \mathbin\| expireTimestamp \| \color{red}{extension}) \mathbin\| (dấu thời gian hết hạn \| \color{red}{extension}) $$

Đây là một mã thông báo hợp lệ cho việc giả mạo.

NIST khi gọi tới các ứng cử viên SHA3 bắt buộc phải là chống kéo dài tấn công. Keccak hiện đã đặt tên SHA3 là người chiến thắng và Blake2 vẫn là một lựa chọn thay thế tốt trong cuộc thi. Cả hai đều có khả năng chống lại các cuộc tấn công mở rộng chiều dài, Keccak bằng cách sử dụng năng lực và Blake2 đang sử dụng HAIFA xây dựng, an toàn cho các cuộc tấn công mở rộng kéo dài.

Để giảm thiểu, người ta có thể sử dụng HMAC;

$$token = \operatorname{HMAC-SHA256}(privateKey, publicKey \mathbin\| expireTimestamp) \mathbin\| hết hạnDấu thời gian$$ Lưu ý rằng điều này sẽ gọi SHA-256 ít nhất hai lần ( ba lần nếu khóa dài hơn kích thước khối của hàm băm, 512-bit cho SHA-256).

Thay vì HMAC, chúng ta có thể sử dụng BLAKE2. BLAKE2 rất nhanh và thậm chí chúng tôi còn có phiên bản song song BLACK3 và sử dụng

$$token = \operatorname{BLAKE2}( publicKey \mathbin\| privateKey \mathbin\|expireTimestamp) \mathbin\| hết hạnDấu thời gian$$ an toàn.

NIST cũng chuẩn hóa MAC cho SHA3 có tên KMAC( hoặc đây).

Cả BLAKE2 và KMAC đều thích hợp hơn HMAC.

Nếu bạn khăng khăng sử dụng SHA2 với kích thước đầu ra 256 bit thì hãy sử dụng SHA-512/256, đây là phiên bản rút gọn của SHA-512/256 với các giá trị ban đầu khác nhau để phân tách các miền. SHA-512/256 miễn nhiễm với các cuộc tấn công mở rộng độ dài và nó thân thiện với CPU 64 bit theo thiết kế.

AliReza Sabouri avatar
lá cờ jp
cảm ơn bạn @kelalaka, điều này thực sự hữu ích. ví dụ của bạn với `phần mở rộng` đã tạo ra một câu hỏi khác cho tôi, Điều gì sẽ xảy ra nếu cả 3 phần luôn có độ dài cố định. ví dụ: (apikey=36, privateKey=44, expireTime=10). SHA256 có dễ bị tổn thương trong trường hợp này hay không. vì `expireTime` có độ dài cố định nên không ai có thể thêm phần mở rộng cho nó
kelalaka avatar
lá cờ in
Nếu bạn biết kích thước và kiểm tra chúng, thì sẽ không còn tấn công mở rộng miễn là kẻ tấn công không lừa phần đó nữa. Tôi sẽ thực hiện một cuộc tấn công mở rộng an toàn để loại bỏ các bề mặt tấn công.
kelalaka avatar
lá cờ in
Ghi chú; Tôi đã cập nhật câu trả lời để bao gồm SHA-512/256 mà bạn có thể muốn sử dụng.

Đă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.