it-swarm-vi.com

Chuyển gì? Mật khẩu hay hàm băm của nó?

Giả sử trong cơ sở dữ liệu của tôi, tôi lưu trữ mật khẩu được băm bằng muối với hàm băm khá đắt (tiền mã hóa, 1000 vòng SHA2, bất cứ thứ gì).

Khi đăng nhập, tôi nên chuyển gì qua mạng và tại sao? Mật khẩu hay hàm băm của nó?

Có thể bảo vệ đăng nhập như vậy trên một kênh không được mã hóa như HTTP?

40
Konrad Garus

Nếu bạn chuyển hàm băm từ máy khách, điều này sẽ không có lợi ích bảo mật và làm cho hàm băm trở nên vô nghĩa:
[.___.] Nếu người dùng có thể đăng nhập bằng cách gửi hàm băm đến máy chủ, thì hash thực sự là mật khẩu.

61
AviD

Nếu giao thức xác thực của bạn là về việc gửi đến máy chủ mật khẩu hoặc hàm băm của mật khẩu, với HTTP đơn giản, thì điều này vốn đã rất yếu, vì hai lý do:

  • Ai đó gián điệp trên đường dây có thể ghi lại những gì khách hàng gửi. Nếu chỉ gửi các byte cấp quyền truy cập, thì kẻ tấn công có thể chỉ cần gửi lại chúng. Đó là một phát lại tấn công . Vấn đề này là những gì @AviD ám chỉ trong câu trả lời của anh ấy. Không có số lượng băm sẽ khắc phục điều đó. Một số giao thức cố gắng khắc phục vấn đề này bằng cách bao gồm một "thách thức" từ máy chủ (một giá trị ngẫu nhiên, được tạo lại cho mỗi kết nối), để được băm cùng với mật khẩu trên máy khách; đó là những gì xác thực HTTP Digest là về.

  • Ngay cả khi xác thực hoạt động, đây vẫn là HTTP đơn giản, do đó, bất kỳ dữ liệu nào sẽ được gửi sau đó sẽ dễ bị nghe lén và thay đổi bởi những kẻ tấn công. Nếu phương tiện vận chuyển không được bảo vệ, thì xác thực sẽ chỉ ngăn chặn những kẻ tấn công không tinh vi nhất. Đây là nơi HTTP Digest thất bại.

Do đó, bạn thực sự cần SSL (còn gọi là HTTPS), không chỉ để truyền tải mật khẩu hoặc hàm băm mà còn cả phần còn lại của cuộc trò chuyện giữa máy khách và máy chủ .


Sau đây tôi giả sử rằng giao thức được chạy trong một đường hầm SSL. Bạn có quyền muốn sử dụng a băm chậm như bcrypt hoặc PBKDF2; lưu ý rằng a salt cũng cần thiết để ngăn chia sẻ chi phí (ví dụ: các bảng được tính toán trước). Băm chậm, muối được sử dụng để đối phó với sự yếu kém nội tại của mật khẩu. Bây giờ, bạn có thể muốn giảm tải một số nỗ lực băm trên máy khách. Điều này may công việc, nhưng nó đặt ra một số vấn đề thực tế:

  • Vì việc xử lý mật khẩu phải bao gồm một muối, một mật khẩu mới cho mỗi trường hợp mật khẩu, sau đó muối phải được chuyển đến máy khách, để khách hàng có thể đưa nó vào quá trình băm mà nó thực hiện. Điều này làm tăng độ phức tạp của giao thức: trước tiên khách hàng phải gửi tên người dùng đến máy chủ, sau đó máy chủ phải gửi lại muối và (chỉ sau đó) khách hàng mới có thể bắt đầu băm mật khẩu. Đây là một vòng tròn mạng nhiều hơn so với "gửi tên người dùng và mật khẩu thông thường là một POST yêu cầu".

  • Băm chậm là về việc chấp nhận chi nhiều CPU cho mỗi mật khẩu, do đó kẻ tấn công cũng vậy phải tiêu tốn rất nhiều CPU cho mỗi mật khẩu. Nhưng nếu CPU đã sử dụng cho máy khách, thì chúng ta không thể nâng nó nhiều như chúng ta muốn, bởi vì: 1) có những máy khách có rất ít CPU (ví dụ như một số điện thoại thông minh hoặc máy tính bảng giá rẻ) và 2) bối cảnh Web ngụ ý sử dụng Javascript và hiệu suất Javascript thực sự rất tệ khi băm (nói chậm hơn ít nhất 20 lần so với mã C).

Do đó sự khôn ngoan thông thường là việc tạo ra một phần của mật khẩu băm trên máy khách không đáng để bỏ công sức.

24
Thomas Pornin

Cả hai lựa chọn đều không an toàn.

Chuyển mật khẩu sẽ làm cho giao thức của bạn trở thành văn bản đơn giản. Chuyển hàm băm, sẽ khiến bạn dễ bị tấn công lại.

APOP là một triển khai đăng nhập cho giao thức POP. Điều này cho phép giao thức giữ mật khẩu riêng tư với bất kỳ người nghe nào trên mạng. Một nhược điểm của điều này là cả máy khách và máy chủ đều cần biết mật khẩu ở dạng văn bản đơn giản, vì đây là bí mật được chia sẻ. Trước giao thức cả máy khách và máy chủ đều có <password> Giao tiếp giao thức về cơ bản là như thế này:

  1. Máy khách kết nối với máy chủ và gửi mã thông báo ngẫu nhiên (T1)
  2. Máy chủ gửi mã thông báo ngẫu nhiên (T2)
  3. Máy khách gửi M = sha (T1 + T2 + <password: bản sao của khách hàng)) đến máy chủ
  4. Máy chủ kiểm tra xem sha (T1 + T2 + <password: bản sao của máy chủ>) có khớp với M (hàm băm vừa nhận được).

Tại đây, máy chủ biết cả ma thuật và mật khẩu và có thể xác định xem người dùng có biết mật khẩu chính xác hay không mà không tiết lộ cho bất kỳ người nghe nào.

Cách thực hành tốt nhất là lưu trữ băm trong cơ sở dữ liệu một cách an toàn và dựa vào các kênh được mã hóa.

4
Dog eat cat world