Có thể để muối và hoặc băm mật khẩu HOTP/TOTP trên máy chủ không?

Question

Tôi đang xây dựng hệ thống xác thực hai yếu tố dựa trên TOTP/HOTP. Để xác minh otp cả máy chủ và thiết bị otp phải biết bí mật được chia sẻ.

Vì mật khẩu HOTP khá giống với mật khẩu của người dùng, tôi cho rằng các phương pháp hay nhất tương tự nên được áp dụng. Cụ thể là nó rất cao nên không bao giờ lưu trữ mật khẩu không được mã hóa, chỉ giữ một băm muối của mật khẩu.

Cả RFC và triển khai python của HOTP/TOTP đều không bao gồm khía cạnh này.

Có cách nào để sử dụng mã hóa một chiều của bí mật được chia sẻ OTP hay là một ý tưởng ngu ngốc?

Answer 1

Có cách nào để sử dụng mã hóa một chiều của bí mật được chia sẻ OTP ...?

Không thực sự. Bạn có thể sử dụng một cơ chế mã hóa đảo ngược, nhưng có lẽ không có nhiều điểm.

Bạn chỉ có thể băm một khóa HMAC trên máy chủ nếu máy khách xác thực bằng cách gửi khóa HMAC chưa hoàn chỉnh trên mạng, thường là cách xác thực dựa trên mật khẩu, nhưng sẽ dễ bị tấn công phát lại. chính xác những gì HOTP/TOTP được thiết kế để tránh.

tại sao chúng tôi áp dụng chức năng 1 chiều cho mật khẩu trước khi lưu trữ (muối + băm) ...?

Đó thực sự là một câu hỏi hay.

Tôi nghĩ rằng nó bắt nguồn từ thực tế là các phiên bản đầu của hệ điều hành Unix lưu trữ tất cả thông tin mật khẩu của nó trong một tệp 'có thể đọc được' /etc/passwd trên thế giới, vì vậy rõ ràng chúng phải bị làm mờ theo một cách nào đó. đã xảy ra là phương pháp mà họ đã chọn.

Ngày nay, người ta thường không làm cho tệp mật khẩu của họ tự do sẵn có, vì vậy có thể cho là không cần phải băm chúng.

Tuy nhiên, có một lý do khác để làm xáo trộn chúng, đó là mật khẩu thường được con người chọn, vì vậy, để thuận tiện, chúng thường chọn cùng một mật khẩu cho nhiều hệ thống. Tôi nghi ngờ điều này cũng đúng đối với các khóa HMAC, đó là (hy vọng) được chọn bằng cách sử dụng một cơ chế mã hóa mạnh hơn.

Vì vậy, lý do chính để băm mật khẩu ngày nay, không phải là quá nhiều để tăng tính bảo mật cho hệ thống của bạn, nhưng để giảm nguy cơ xâm phạm bảo mật của người dùng của bạn trên các hệ thống khác. .

Nếu kẻ tấn công có thể đọc mật khẩu văn bản thuần tuý từ hệ thống của bạn, nó có thể không được sử dụng nhiều đối với họ, bởi vì họ cũng có thể đọc mọi thứ khác trên hệ thống.

Nhưng, nếu cùng một mật khẩu cũng được sử dụng trên một hệ thống khác, thì bạn cũng có khả năng cho kẻ tấn công phương tiện xâm phạm hệ thống đó.

Nếu con người có thể tin cậy không sử dụng cùng một mật khẩu cho nhiều hệ thống, thì có lẽ không cần phải băm chúng chút nào, nhưng tôi nghĩ có phần lạc quan để cho rằng điều đó có khả năng xảy ra.:-)

Answer 2

Định nghĩa: HOTP(K,C) = Truncate(HMAC(K,C)) & 0x7FFFFFFF - trong đó K là khóa bí mật và C là bộ đếm. Nó được thiết kế sao cho tin tặc không thể có được K và C nếu chúng có chuỗi HOTP vì HMAC là băm một chiều (không mã hóa hai chiều).

K & C cần được bảo vệ vì bị mất sẽ làm tổn hại toàn bộ hệ thống OTP. Có nói rằng, nếu tìm thấy K trong từ điển và chúng tôi biết C (ví dụ: giờ hiện tại), chúng tôi có thể tạo toàn bộ từ điển của HOTP/TOTP và tìm ra K.

Áp dụng mã hóa một chiều cho HOTP/TOTP (ví dụ: mã hóa kép) sẽ khó giải mã hơn, mặc dù nó không ngăn các dạng tấn công khác (ví dụ: ghi bàn phím) hoặc áp dụng cùng mã hóa cho từ điển danh sách HOTP/TOTP.

Bản chất của con người là tái sử dụng cùng một bộ mật khẩu dễ nhớ cho mọi thứ và do đó cần phải ẩn mật khẩu này trên các thiết bị kỹ thuật số hoặc khi truyền qua internet.

Thực hiện thủ tục hoặc giao thức bảo mật cũng rất quan trọng, giống như chọn mật khẩu tốt K nhưng để nó nằm quanh bàn cho mọi người hoặc máy chủ đang giữ K (dành cho HMAC) không nằm trong mạng riêng được bảo vệ bởi vài lớp tường lửa.