it-swarm-vi.com

Việc sử dụng của một khách hàng nonce là gì?

Sau khi đọc Phần I của cuốn sách của Ross Anderson, Kỹ thuật bảo mật và làm rõ một số chủ đề trên Wikipedia, tôi đã nảy ra ý tưởng về Client Nonce (cnonce). Ross không bao giờ đề cập đến nó trong cuốn sách của mình và tôi đang đấu tranh để hiểu mục đích mà nó phục vụ trong xác thực người dùng.

Một nonce bình thường được sử dụng để tránh phát lại các cuộc tấn công liên quan đến việc sử dụng phản hồi đã hết hạn để giành quyền. Máy chủ cung cấp cho khách hàng một số nonce (Số được sử dụng ONCE) mà máy khách buộc phải sử dụng để băm phản hồi của nó, sau đó máy chủ sẽ băm phản hồi mà nó mong đợi với số không được cung cấp và nếu hàm băm của máy khách khớp với hàm băm của máy chủ sau đó máy chủ có thể xác minh rằng yêu cầu là hợp lệ và mới. Đây là tất cả những gì nó xác minh; hợp lệ và mới .

Tuy nhiên, những lời giải thích mà tôi đã tìm thấy cho một khách hàng nonce tuy nhiên ít thẳng thắn và đáng nghi ngờ hơn. Trang Wikipedia về xác thực truy cập kỹ thuật số và một số phản hồi ở đây trên Stackoverflow dường như gợi ý rằng một nonce client được sử dụng để tránh các cuộc tấn công bằng văn bản được chọn. Tôi có một số vấn đề với ý tưởng này:

  • Nếu một người có thể đánh hơi và chèn các gói tin, lỗ hổng lớn nhất là một cuộc tấn công trung gian mà cả một người không phải cũng không phải là một cnonce có thể vượt qua, do đó làm cho cả hai đều vô nghĩa.
  • Giả sử trong một giây rằng kẻ tấn công không muốn tham gia vào một cuộc tấn công trung gian và muốn khôi phục các chi tiết xác thực, làm thế nào một cnonce cung cấp bảo vệ bổ sung? Nếu kẻ tấn công chặn giao tiếp và trả lời một yêu cầu bằng chính nonce của nó, thì phản hồi từ máy khách sẽ là một hàm băm của nonce, dữ liệu và cnonce ngoài cnonce ở dạng không được mã hóa. Bây giờ kẻ tấn công đã truy cập vào nonce, cnonce và hash. Kẻ tấn công bây giờ có thể băm các bảng Rainbow của nó với nonce và cnonce và tìm một kết quả khớp. Do đó, cnonce cung cấp bảo vệ bổ sung bằng không.

Vì vậy, mục đích của một cnonce là gì?

Tôi giả sử có một phần của phương trình tôi không hiểu nhưng tôi chưa tìm thấy lời giải thích cho phần đó là gì.

CHỈNH SỬA Một số câu trả lời đã gợi ý rằng khách hàng có thể cung cấp thông tin và nó sẽ phục vụ cùng một mục đích. Điều này phá vỡ mô hình phản ứng thách thức, tuy nhiên, ý nghĩa của việc này là gì?

85
user2014

A nonce là một giá trị duy nhất được chọn bởi một thực thể trong giao thức và nó được sử dụng để bảo vệ thực thể đó trước các cuộc tấn công nằm dưới chiếc ô rất lớn của "phát lại".

Ví dụ, hãy xem xét một giao thức xác thực dựa trên mật khẩu như sau:

  • máy chủ gửi "thử thách" (giá trị được cho là ngẫu nhiên c ) cho khách hàng
  • khách hàng sẽ trả lời bằng cách gửi h (c || p) trong đó h là hàm băm an toàn (ví dụ: SHA-256), p là mật khẩu người dùng và ' || 'biểu thị sự ghép
  • máy chủ tra cứu mật khẩu trong cơ sở dữ liệu của chính nó, tính toán lại phản hồi của khách hàng dự kiến ​​và xem liệu nó có khớp với những gì khách hàng đã gửi không

Mật khẩu là những giá trị bí mật phù hợp với bộ não con người; như vậy, chúng không thể rất phức tạp và có thể xây dựng một từ điển lớn chứa mật khẩu người dùng với xác suất cao. "Lớn" ý tôi là "có thể được liệt kê với một cụm quy mô trung bình trong một vài tuần". Đối với các cuộc thảo luận hiện tại, chúng tôi chấp nhận hơn một kẻ tấn công sẽ có thể phá vỡ một mật khẩu bằng cách dành một vài tuần tính toán; đây là mức độ bảo mật mà chúng tôi muốn đạt được.

Hãy tưởng tượng một kẻ tấn công thụ động: kẻ tấn công nghe lén nhưng không làm thay đổi các thông điệp. Anh ta thấy c h (c || p) , vì vậy anh ta có thể sử dụng cụm của mình để liệt kê mật khẩu tiềm năng cho đến khi tìm thấy kết quả khớp. Điều này sẽ tốn kém cho anh ta. Nếu kẻ tấn công muốn tấn công hai mật khẩu thì anh ta phải thực hiện công việc hai lần . Kẻ tấn công muốn có một chút chia sẻ chi phí giữa hai trường hợp tấn công, sử dụng các bảng được tính toán trước ("Bảng cầu vồng" chỉ là một loại bảng được tính toán trước với lưu trữ được tối ưu hóa, nhưng việc xây dựng bảng Cầu vồng vẫn yêu cầu liệt kê từ điển đầy đủ và băm từng mật khẩu). Tuy nhiên, thử thách ngẫu nhiên đánh bại kẻ tấn công: vì mỗi trường hợp liên quan đến một thử thách mới, đầu vào hàm băm sẽ khác nhau cho mỗi phiên, ngay cả khi sử dụng cùng một mật khẩu. Do đó, kẻ tấn công không thể xây dựng các bảng được tính toán trước hữu ích, đặc biệt là các bảng Rainbow.

Bây giờ giả sử rằng kẻ tấn công trở nên hoạt động. Thay vì chỉ quan sát các tin nhắn, anh ta sẽ chủ động thay đổi tin nhắn, bỏ một số, sao chép các tin nhắn khác hoặc chèn tin nhắn của riêng mình. Kẻ tấn công bây giờ có thể chặn một nỗ lực kết nối từ máy khách. Kẻ tấn công chọn và gửi thử thách của riêng mình ( c ') và chờ phản hồi của khách hàng ( h (c' | | p) ). Lưu ý rằng máy chủ thực sự không được liên lạc; Kẻ tấn công chỉ cần ngắt kết nối đột ngột ngay sau phản hồi của máy khách, để mô phỏng lỗi mạng lành tính. Trong mô hình tấn công này, kẻ tấn công đã có một cải tiến lớn: anh ta vẫn có một thách thức c ' và phản ứng tương ứng, nhưng thách thức là một giá trị mà Kẻ tấn công đã chọn khi anh ta thấy phù hợp. Những gì kẻ tấn công sẽ làm là luôn luôn phục vụ cùng một thử thách c '. Sử dụng cùng một thử thách mỗi lần cho phép kẻ tấn công thực hiện các tính toán trước: anh ta có thể xây dựng các bảng được tính toán trước (tức là các bảng Rainbow) sử dụng "thử thách" đặc biệt đó. Bây giờ kẻ tấn công có thể tấn công một số mật khẩu riêng biệt mà không phải chịu chi phí liệt kê từ điển cho mỗi mật khẩu.

Một khách hàng nonce tránh được vấn đề này. Giao thức trở thành:

  • máy chủ gửi một thử thách ngẫu nhiên c
  • khách hàng chọn một nonce n (nên khác biệt mỗi lần)
  • khách hàng gửi n || h (c | | n | | p)
  • máy chủ tính toán lại h (c || n || p) (sử dụng p từ cơ sở dữ liệu của nó) và xem giá trị này có khớp với những gì khách hàng đã gửi không

Vì máy khách bao gồm một giá trị ngẫu nhiên mới ("nonce") trong đầu vào hàm băm cho mỗi phiên, đầu vào hàm băm sẽ khác biệt mỗi lần, ngay cả khi kẻ tấn công có thể chọn thử thách. Điều này đánh bại các bảng được tính toán trước (Rainbow) và khôi phục mức bảo mật dự định của chúng tôi.

Một mô phỏng thô của một nonce duy nhất là tên người dùng. Hai người dùng riêng biệt trong cùng một hệ thống sẽ có tên riêng biệt. Tuy nhiên, người dùng sẽ giữ tên của mình khi thay đổi mật khẩu; và hai người dùng riêng biệt có thể có cùng tên trên hai hệ thống riêng biệt (ví dụ: mọi hệ thống giống Unix đều có người dùng "root"). Vì vậy, tên người dùng không phải là một nonce tốt (nhưng nó vẫn tốt hơn so với việc không có khách hàng nonce nào cả).

Tóm lại, nonce của khách hàng là về việc bảo vệ khách hàng khỏi một cuộc tấn công chơi lại ("máy chủ" thực tế là một kẻ tấn công, người sẽ gửi thử thách tương tự cho mọi khách hàng mà anh ta muốn tấn công). Điều này là không cần thiết nếu thử thách được thực hiện trên một kênh bao gồm xác thực máy chủ mạnh (như SSL). Trao đổi khóa xác thực mật khẩ là các giao thức nâng cao đảm bảo xác thực dựa trên mật khẩu lẫn nhau giữa máy khách và máy chủ, mà không cần một sự tin cậy ưu tiên ("chứng chỉ gốc" khi máy khách SSL xác thực chứng chỉ máy chủ SSL) và bảo vệ chống lại những kẻ tấn công chủ động và thụ động (bao gồm cả cuộc tấn công "cụm trong hai tuần" vào một mật khẩu duy nhất, vì vậy điều đó tốt hơn hẳn so với giao thức ở trên, không hoặc không mở).

138
Thomas Pornin

Hãy để tôi thử trả lời câu hỏi của bạn: "Giả sử trong một giây rằng kẻ tấn công không muốn tham gia vào một cuộc tấn công trung gian và muốn khôi phục các chi tiết xác thực, làm thế nào một cnonce cung cấp thêm sự bảo vệ?"

Thông thường, một khách hàng không chỉ bao gồm một người không có yêu cầu, nhưng dấu toàn bộ yêu cầu, bao gồm cả nonce. Điều này có nghĩa là ngay cả khi kẻ tấn công chặn tin nhắn giữa máy khách và máy chủ:

  1. Một cuộc tấn công phát lại sẽ không hoạt động (vì máy chủ đang theo dõi các phi vụ khách).
  2. Kẻ tấn công không thể tạo một tin nhắn mới với một máy khách mới , vì nó không biết cách tin nhắn mới một cách thích hợp (nghĩa là nó thiếu bí mật của khách hàng hoặc khóa riêng).
7
Bosh

Theo RFC 2617 , các tham số cnoncenc bảo vệ chống lại các cuộc tấn công văn bản đã chọn. Làm thế nào để bảo vệ chống lại các cuộc tấn công như vậy?

Nếu Eve thay đổi, nonce máy chủ sẽ gửi cho khách hàng, Eve đã đạt được điều gì? Eve không thể tạo h(password || nonce) từ h(password || fake_nonce) và về mặt lý thuyết, có vẻ như máy chủ không nên chấp nhận h(password || fake_nonce) vì máy chủ nên biết những gì nonce được phát hành và cái gì không phải là nó.

1
paynes_bay

Tôi nghĩ rằng một ý tưởng tốt sẽ là đọc về cách sử dụng giá trị nonce trong một cái gì đó như Oauth . Nói tóm lại, khi một ứng dụng sử dụng OAuth đưa ra yêu cầu đối với phân phát được hỗ trợ OAuth, yêu cầu phải chứa một loạt các trường, hai trong số đó là dấu thời gian và không phải là mục đích. là hiển nhiên: nó đưa ra một dấu hiệu về khung thời gian mà tin nhắn được gửi để máy chủ có thể đoán chính xác hơn về việc tin nhắn có bị cũ hay không. Cái sau rõ ràng là một loạt các ký tự/byte ngẫu nhiên.

Khi toàn bộ tiêu đề OAuth được băm với bí mật người tiêu dùng, cả hai trường này đều được bao gồm. Sau đó, chữ ký có gắn với yêu cầu (cho dù đó là tham số truy vấn hoặc tiêu đề HTTP) và được gửi vào đến máy chủ. Phần thân thực tế của yêu cầu là không được băm.

Máy chủ OAuth nên theo dõi bộ giá trị N nonce trước đó cho một khách hàng cụ thể để đảm bảo rằng chúng không được sử dụng lại. Cho rằng phần thân của thông báo có thể thay đổi (về cơ bản là không có ảnh hưởng đến hàm băm) điều quan trọng là phải có một thứ khác sẽ thay đổi (ví dụ: nonce) để đảm bảo rằng các yêu cầu là duy nhất. Với tính chất văn bản mở/đơn giản của HTTP, điều này khá quan trọng.

Điều này có giúp làm rõ mục đích của nó không? (hy vọng vậy :)).

1
OJ.