Có tốt hơn khi tạo chuỗi băm an toàn không?

Question

Tôi không thực sự mạnh về mật mã, do đó, có câu hỏi của tôi.

Ứng dụng - diễn đàn của chúng tôi - gửi thông báo cho người dùng của chúng tôi về tin nhắn mới, nếu họ đã chọn. Trong email nên có một liên kết để hủy đăng ký nhận tin nhắn này. Bây giờ, tôi muốn liên kết đó hoạt động, ngay cả khi người dùng hiện không được xác thực tại dịch vụ của chúng tôi (không có cookie).

Để làm điều đó, tôi quyết định chỉ cần đăng theo yêu cầu với SHA1, như thế này:

http://example.com/unsubscribe?u=234&s=52342&h=0b071440146545eaf3f00ef9cdeb1d47d006dfff

đây u là ID của người sử dụng, ai muốn bỏ đăng ký, s là một số muối ngẫu nhiên, h là băm an toàn được tính bằng cách nối tên của hành động (hủy đăng ký), tham số và giá trị của chúng (u = 234s = 52342) và một số chuỗi bí mật, được chỉ định trong cấu hình dịch vụ của chúng tôi và tính toán hàm băm SHA1 của chuỗi kết quả:

sha1('unsubscribeu=234s=52342supersecret')

Câu hỏi của tôi là về tham số này s, được tạo ngẫu nhiên mỗi lần. Liệu nó có thêm vào an ninh ở đây hay không? Có thực sự cần thiết?

Nếu tôi sử dụng mã hóa thay vào đó, bạn có nên thêm loại muối này vào dữ liệu đang được mã hóa không?

Đây là một câu hỏi lý thuyết, vì rất khó có ai đó muốn đoán rằng "supersecret" tại dịch vụ của chúng tôi chỉ để prank-unsubscribe một loạt người dùng, nhưng vẫn thú vị.

Answer 1

Việc sử dụng chính cho muối là để tránh so sánh các giá trị băm khác nhau để phân tích; ví dụ: để xem liệu có hai người dùng nào có cùng mật khẩu hay không bằng cách so sánh giá trị băm của mật khẩu của họ. Nếu muối ngẫu nhiên được thêm vào, thì không thể so sánh (trừ khi cả hai mật khẩu và các muối đều bằng nhau - điều này không nên xảy ra vì một muối phải là ngẫu nhiên)

Trong trường hợp của bạn, tôi không nghĩ có bất kỳ lợi ích nào từ giá trị muối trừ khi bạn cũng lưu trữ các muối đó vào cuối máy chủ và 'hết hạn' chúng khi được sử dụng, để liên kết hủy đăng ký nhất định - với giá trị muối của nó - không thể 'phát lại' sau.

Answer 2

Tôi không phải là chuyên gia bảo mật nhưng tôi nghĩ tôi có thể để lại 2 xu.

Thông số "S" (nghĩa là "muối" như bạn gọi) là mã bảo mật và đó là biện pháp bảo mật chính của bạn. Hàm băm có sẵn để làm cho việc điều chỉnh các thông số URL khó hơn (hoặc thậm chí không thể), để người dùng cuối không thể kích hoạt các hành động với một mã thông báo khác trên một cuộc gọi tương tự.

Bạn có thể lưu trữ mã thông báo cùng với yêu cầu hủy đăng ký người dùng và kiểm tra sự bình đẳng trong cuộc gọi xác nhận tiếp theo (xác thực hành động hủy đăng ký người dùng). Sau khi kiểm tra giá trị băm của thông số URL, tất nhiên (xác thực nếu yêu cầu không được thao tác)

Answer 3

Điều bạn muốn không phải là muối, mà là một số nonce. Bằng cách sử dụng một nonce, và ghi lại một thực tế rằng nó đã được sử dụng, bạn có thể hạn chế nguy cơ tiếp xúc của các URL bí mật sẽ phải chịu.

Ngoài ra, thay vì ghép nối bí mật của bạn với chuỗi băm, hãy sử dụng HMAC.