Sự khác biệt giữa Digest và Xác thực cơ bản là gì?

Sự khác biệt giữa Digest và Xác thực cơ bản là gì?

Xác thực Digest truyền đạt thông tin đăng nhập dưới dạng được mã hóa bằng cách áp dụng hàm băm cho: tên người dùng, mật khẩu, máy chủ được cung cấp giá trị nonce, phương thức HTTP và URI được yêu cầu.

Trong khi đó Xác thực cơ bản sử dụng mã hóa base64 không được mã hóa.

Do đó, Xác thực cơ bản thường chỉ được sử dụng khi bảo mật lớp vận chuyển được cung cấp, chẳng hạn như https.

Xem RFC-2617 để biết tất cả các thông tin chi tiết.

Xác thực truy cập cơ bản HTTP

• BƯỚC 1 : khách hàng đưa ra yêu cầu cung cấp thông tin, gửi tên người dùng và mật khẩu đến máy chủ bằng văn bản thuần túy
• BƯỚC 2 : máy chủ phản hồi với thông tin mong muốn hoặc có lỗi

Xác thực cơ bản sử dụng mã hóa base64 (không phải mã hóa) để tạo chuỗi mật mã của chúng tôi chứa thông tin về tên người dùng và mật khẩu. HTTP Basic không cần triển khai qua SSL, nhưng nếu bạn không, nó hoàn toàn không an toàn. Vì vậy, tôi thậm chí sẽ không giải trí ý tưởng sử dụng nó mà không có.

Ưu điểm:

• Cách thực hiện đơn giản, do đó, các nhà phát triển ứng dụng khách của bạn sẽ có ít việc phải làm hơn và mất ít thời gian hơn để phân phối, vì vậy các nhà phát triển có thể muốn sử dụng API của bạn hơn
• Không giống như Digest, bạn có thể lưu trữ mật khẩu trên máy chủ theo bất kỳ phương thức mã hóa nào bạn thích, chẳng hạn như bcrypt, làm cho mật khẩu an toàn hơn
• Chỉ cần một cuộc gọi đến máy chủ để lấy thông tin, làm cho máy khách nhanh hơn một chút so với các phương thức xác thực phức tạp hơn có thể là

Nhược điểm:

• SSL chạy chậm hơn HTTP cơ bản nên điều này khiến máy khách chậm hơn một chút
• Nếu bạn không có quyền kiểm soát khách hàng và không thể buộc máy chủ sử dụng SSL, nhà phát triển có thể không sử dụng SSL, gây ra rủi ro bảo mật

Tóm lại - nếu bạn có quyền kiểm soát khách hàng hoặc có thể đảm bảo họ sử dụng SSL, HTTP Basic là một lựa chọn tốt. Sự chậm chạp của SSL có thể bị hủy bỏ bởi tốc độ chỉ thực hiện một yêu cầu

Cú pháp xác thực cơ bản

Value = username:password
Encoded Value =  base64(Value)
Authorization Value = Basic <Encoded Value> 
//at last Authorization key/value map added to http header as follows
Authorization: <Authorization Value>

Xác thực
truy cập tiêu hóa HTTP Xác thực truy cập tiêu hóa sử dụng phương pháp băm (nghĩa là tiêu hóa có nghĩa là cắt thành từng mảnh nhỏ) để tạo kết quả mã hóa. Xác thực truy cập HTTP Digest là một hình thức xác thực phức tạp hơn hoạt động như sau:

• BƯỚC 1 : khách hàng gửi yêu cầu đến máy chủ
• BƯỚC 2 : máy chủ trả lời bằng một mã đặc biệt (được gọi lànoncetức là n umber chỉ được sử dụng một lần ), một chuỗi khác đại diện cho vương quốc (hàm băm) và yêu cầu khách xác thực
• BƯỚC 3 : khách hàng phản hồi với thông tin này và phiên bản được mã hóa của tên người dùng, mật khẩu và địa hạt (hàm băm)
• BƯỚC 4 : máy chủ phản hồi với thông tin được yêu cầu nếu hàm băm của khách hàng khớp với hàm băm của tên người dùng, mật khẩu và địa hạt của họ hoặc lỗi nếu không

Ưu điểm:

• Không có tên người dùng hoặc mật khẩu được gửi đến máy chủ trong bản rõ, làm cho kết nối không phải SSL an toàn hơn yêu cầu HTTP Basic không được gửi qua SSL. Điều này có nghĩa là SSL không bắt buộc, điều này làm cho mỗi cuộc gọi nhanh hơn một chút

Nhược điểm:

• Đối với mỗi cuộc gọi cần thiết, máy khách phải thực hiện 2, làm cho quá trình chậm hơn một chút so với HTTP Basic
• HTTP Digest dễ bị tấn công bảo mật trung gian, điều đó có nghĩa là nó có thể bị hack
• HTTP Digest ngăn chặn việc sử dụng mã hóa mật khẩu mạnh, có nghĩa là mật khẩu được lưu trữ trên máy chủ có thể bị hack

Tóm lại , HTTP Digest vốn dễ bị tổn thương trước ít nhất hai cuộc tấn công, trong khi đó một máy chủ sử dụng mã hóa mạnh cho mật khẩu với HTTP Basic qua SSL thì ít có khả năng chia sẻ các lỗ hổng này.

Nếu bạn không có quyền kiểm soát khách hàng của mình, tuy nhiên họ có thể cố gắng thực hiện xác thực Cơ bản mà không cần SSL, điều này kém an toàn hơn nhiều so với Digest.

Cú pháp xác thực truy cập RFC 2069

Hash1=MD5(username:realm:password)
Hash2=MD5(method:digestURI)
response=MD5(Hash1:nonce:Hash2)

Cú pháp xác thực truy cập RFC 2617

Hash1=MD5(username:realm:password)
Hash2=MD5(method:digestURI)
response=MD5(Hash1:nonce:nonceCount:cnonce:qop:Hash2)
//some additional parameters added 

nguồn và ví dụ

Trong Postman trông như sau:

Ghi chú:

• Các lược đồ Cơ bản và Tiêu hóa được dành riêng cho xác thực bằng tên người dùng và bí mật.
• Các chương trình Bearer là dành riêng cho việc xác thực bằng một mã thông báo.

Chúng ta hãy xem sự khác biệt giữa hai xác thực HTTP bằng cách sử dụng Wireshark(Công cụ để phân tích các gói được gửi hoặc nhận).

1. Xác thực cơ bản http

Ngay khi máy khách gõ đúng tên người dùng: mật khẩu , theo yêu cầu của máy chủ Web, Máy chủ Web sẽ kiểm tra trong Cơ sở dữ liệu nếu thông tin đăng nhập là chính xác và cấp quyền truy cập vào tài nguyên.

Đây là cách các gói được gửi và nhận:

Trong gói đầu tiên, Máy khách điền thông tin đăng nhập bằng phương thức POST tại tài nguyên - lab/webapp/basicauth. Trả lại máy chủ trả lời lại với mã phản hồi http 200 ok , tức là tên người dùng: mật khẩu đã đúng.

Bây giờ, trong Authorizationtiêu đề cho thấy đó là Ủy quyền cơ bản theo sau là một chuỗi ngẫu nhiên. Chuỗi này là phiên bản được mã hóa (Base64) của thông tin đăng nhập admin:aadd(bao gồm cả dấu hai chấm).

2. Xác thực tiêu hóa (rfc 2069)

Cho đến nay chúng ta đã thấy rằng Xác thực cơ bản gửi tên người dùng: mật khẩu trong văn bản gốc qua mạng. Nhưng Autest Auth gửi HASH của Mật khẩu bằng thuật toán Hash.

Dưới đây là các gói hiển thị các yêu cầu được thực hiện bởi máy khách và phản hồi từ máy chủ.

Ngay khi máy khách nhập thông tin đăng nhập do máy chủ yêu cầu, Mật khẩu sẽ được chuyển đổi sang responsesử dụng thuật toán và sau đó được gửi đến máy chủ, Nếu Cơ sở dữ liệu máy chủ có phản hồi giống như được cung cấp bởi máy khách, máy chủ sẽ cấp quyền truy cập vào tài nguyên , nếu không thì lỗi 401 .

Ở phía trên Authorization, các responsechuỗi được tính toán dựa trên các giá trị của Username, Realm, Password, http-method, URIvà Noncenhư thể hiện trong hình ảnh:

(bao gồm dấu hai chấm)

Do đó, chúng ta có thể thấy rằng Xác thực Digest an toàn hơn vì nó liên quan đến Băm (mã hóa MD5), vì vậy các công cụ sniffer gói không thể đánh hơi được Mật khẩu mặc dù trong Basic Auth, Mật khẩu chính xác được hiển thị trên Wireshark.

Xác thực cơ bản sử dụng Mã hóa cơ sở 64 để tạo chuỗi mật mã chứa thông tin tên người dùng và mật khẩu.

Xác thực truy cập Digest sử dụng các phương pháp băm để tạo kết quả mã hóa