HTTP Authentication Mode

SIP is similar to HTTP protocol. The authentication mode is also the same. The HTTP protocol (RFC 2616) stipulates that the base mode and digest mode can be used ). RFC 2617 specifies two authentication modes. RFC 1321 is the MD5 standard. Digest is not strong in modern password cracking, but it is much better than the basic mode. MD5 has been found by Shandong University professors to be counterfeited (I understand it), but it is still widely used.

1. The simplest attack method

If the website requires authentication and the client sends a plaintext user name and password, the network eavesdroppers can easily obtain the user name and password, which does not play a security role. When I went to school, I tapped someone else's HKUST BBS password in the HKUST lab LAN and found that the BBS user name and password were transmitted in plain text. The treasure of thieves and the excitement of thieves are inexplicable. The hacker money and accounting are morally condemned, and the hacker password is only self-defeating. There is no sense of guilt over "not stealing books. Therefore, if your username and password are transmitted in plain text, you can put a piece of fat meat in front of the mouth. Currently, many ASP websites use MD5 encryption for user names and passwords. MD5 is a 16-byte encrypted string generated after the arbitrary length string and 128-bit random number operation. As a result, eavesdroppers are capturing garbled characters. However, there is a problem: If the eavesdroppers use this garbled code for authentication, they can still pass the authentication. Because the character string obtained after the server encrypts the user name and password with MD5 is a mess of garbled characters, it is naturally impossible to distinguish who is a legitimate user. This is called a replay attack (Replay
Attack ). This is similar to the Basic Authentication Mode of HTTP. To ensure security, do not let others gain nothing. Naturally, we need to take basic measures. The following are two authentication modes stipulated by the HTTP protocol.

2. Basic Authentication Mode

The customer sends a request to the server. The server returns 401 (unauthorized) and requires authentication. 401 The challenge information is contained in the message header. Realm is used to differentiate the parts that require different authentication. After the client receives 401, it encrypts the user name, password, and challenge information with base64 to form a certificate and send it back to the server for authentication. Syntax:

Challenge = "Basic" Realm
Credentials = "Basic" Basic-Credentials

Example:

Authentication Header: www-Authenticate: Basic realm = "zhouhh@mydomain.com"
Certificate: Authorization: Basic qsdfgwghffuicanlc2ftzq =

3. Digest access authentication

Abstract access authentication is used to prevent replay attacks. After the customer sends a request, the customer receives a 401 (unauthorized) message, which contains a challenge. The message contains a unique string: nonce, which varies with each request. The customer encrypts the user name and password together with the challenge returned by message 401 and then sends them to the server. In this way, even if there is eavesdropping, he cannot pass each authentication and cannot replay the attack. HTTP is not a secure protocol. The content is transmitted in plain text. Therefore, do not count on how secure HTTP is.

Syntax:

Challenge = "Digest" digest-Challenge

Digest-challenge = 1 # (realm | [domain] | nonce |
[Opaque] | [stale] | [algorithm] |
[Qop-options] | [auth-Param])

Domain = "Domain" "=" <"> uri (1 * sp uri) <">
Uri = absoluteuri | abs_path
Nonce = "nonce" "=" nonce-Value
Nonce-value = quoted-string
Opaque = "Opaque" "=" quoted-string
Stale = "stale" "=" ("true" | "false ")
Algorithm = "algorithm" "=" ("MD5" | "MD5-sess" |
Token)
Qop-Options = "qop" "=" <"> 1 # qop-value <">
Qop-value = "auth" | "Auth-int" | token

Realm: a string that allows the customer to know which user name and password to use. Different domains may have different passwords. At least tell the user what host is used for authentication, and he may prompt the user to log on, similar to an email.
Domain: A list of Uris that indicate the domains to be protected. It may be a list. The user is prompted to use the same authentication for these Uris. If it is null or ignored, it is the whole server.
Nonce: random string, which is different from 401 each time. Related to algorithms. The algorithm is similar to base64 encryption: time-stamp H (time-stamp ":" etag ":" private-key ). Time-stamp is the server clock, and etag is the request's etag header. Private-key is a value known to the server.
Opaque: the original response is returned when the client initiates a request. It is best to use a base64 string or a hexadecimal string.
Auth-Param: used for extension, which is ignored at this stage.
For other fields, see rfc2617.

Authorization Header Syntax:

Credentials = "Digest" digest-Response
Digest-response = 1 # (username | realm | nonce | digest-Uri
| Response | [algorithm] | [cnonce] |
[Opaque] | [Message-qop] |
[Nonce-count] | [auth-Param])

Username = "username" "=" username-Value
Username-value = quoted-string
Digest-uri = "Uri" "=" digest-Uri-Value
Digest-Uri-value = request-Uri; as specified by HTTP/1.1
Message-qop = "qop" "=" qop-Value
Cnonce = "cnonce" "=" cnonce-Value
Cnonce-value = nonce-Value
Nonce-Count = "nc" "=" nc-Value
NC-value = 8 lhex
Response = "response" "=" request-Digest
Request-digest = <"> 32 lhex <">
Lhex = "0" | "1" | "2" | "3" |
"4" | "5" | "6" | "7" |
"8" | "9" | "A" | "B" |
"C" | "D" | "E" | "F"

Response: encrypted password
Digest-Uri: Copy request-line for proxy
Cnonce: If qop is set, it is used for two-way authentication to prevent attacks.
Nonce-count: if the server sees the same count, it is a replay.

Example:

401 response: HTTP/1.1 401 unauthorized
WWW-Authenticate: Digest
Realm = "testrealm@host.com ",
Qop = "auth, Auth-int ",
Nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093 ",
Opaque = "5ccc069c403ebaf9f0171e9517f40e41"
Request again:
Authorization: Digest username = "Mufasa ",
Realm = "testrealm@host.com ",
Nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093 ",
Uri = "/DIR/index.html ",
Qop = auth,
NC = 00000001,
Cnonce = "0a4f113b ",
Response = "6629fae49393a05417978507c4ef1 ",
Opaque = "5ccc069c403ebaf9f0171e9517f40e41"

4. Compared with basic authentication and digest access authentication, they are very fragile. Basic Authentication allows eavesdroppers to directly obtain the user name and password, while digest access authentication eavesdroppers can only obtain the document for one request.

Share:

SIP is similar to HTTP protocol. The authentication mode is also the same. The HTTP protocol (RFC 2616) stipulates that the base mode and digest mode can be used ). RFC 2617 specifies two authentication modes. RFC 1321 is the MD5 standard. Digest is not strong in modern password cracking, but it is much better than the basic mode. MD5 has been found by Shandong University professors to be counterfeited (I understand it), but it is still widely used.

1. The simplest attack method

If the website requires authentication and the client sends a plaintext user name and password, the network eavesdroppers can easily obtain the user name and password, which does not play a security role. When I went to school, I tapped someone else's HKUST BBS password in the HKUST lab LAN and found that the BBS user name and password were transmitted in plain text. The treasure of thieves and the excitement of thieves are inexplicable. The hacker money and accounting are morally condemned, and the hacker password is only self-defeating. There is no sense of guilt over "not stealing books. Therefore, if your username and password are transmitted in plain text, you can put a piece of fat meat in front of the mouth. Currently, many ASP websites use MD5 encryption for user names and passwords. MD5 is a 16-byte encrypted string generated after the arbitrary length string and 128-bit random number operation. As a result, eavesdroppers are capturing garbled characters. However, there is a problem: If the eavesdroppers use this garbled code for authentication, they can still pass the authentication. Because the character string obtained after the server encrypts the user name and password with MD5 is a mess of garbled characters, it is naturally impossible to distinguish who is a legitimate user. This is called a replay attack (Replay
Attack ). This is similar to the Basic Authentication Mode of HTTP. To ensure security, do not let others gain nothing. Naturally, we need to take basic measures. The following are two authentication modes stipulated by the HTTP protocol.

2. Basic Authentication Mode

The customer sends a request to the server. The server returns 401 (unauthorized) and requires authentication. 401 The challenge information is contained in the message header. Realm is used to differentiate the parts that require different authentication. After the client receives 401, it encrypts the user name, password, and challenge information with base64 to form a certificate and send it back to the server for authentication. Syntax:

Challenge = "Basic" Realm
Credentials = "Basic" Basic-Credentials

Example:

Authentication Header: www-Authenticate: Basic realm = "zhouhh@mydomain.com"
Certificate: Authorization: Basic qsdfgwghffuicanlc2ftzq =

3. Digest access authentication

Abstract access authentication is used to prevent replay attacks. After the customer sends a request, the customer receives a 401 (unauthorized) message, which contains a challenge. The message contains a unique string: nonce, which varies with each request. The customer encrypts the user name and password together with the challenge returned by message 401 and then sends them to the server. In this way, even if there is eavesdropping, he cannot pass each authentication and cannot replay the attack. HTTP is not a secure protocol. The content is transmitted in plain text. Therefore, do not count on how secure HTTP is.

Syntax:

Challenge = "Digest" digest-Challenge

Digest-challenge = 1 # (realm | [domain] | nonce |
[Opaque] | [stale] | [algorithm] |
[Qop-options] | [auth-Param])

Domain = "Domain" "=" <"> uri (1 * sp uri) <">
Uri = absoluteuri | abs_path
Nonce = "nonce" "=" nonce-Value
Nonce-value = quoted-string
Opaque = "Opaque" "=" quoted-string
Stale = "stale" "=" ("true" | "false ")
Algorithm = "algorithm" "=" ("MD5" | "MD5-sess" |
Token)
Qop-Options = "qop" "=" <"> 1 # qop-value <">
Qop-value = "auth" | "Auth-int" | token

Realm: a string that allows the customer to know which user name and password to use. Different domains may have different passwords. At least tell the user what host is used for authentication, and he may prompt the user to log on, similar to an email.
Domain: A list of Uris that indicate the domains to be protected. It may be a list. The user is prompted to use the same authentication for these Uris. If it is null or ignored, it is the whole server.
Nonce: random string, which is different from 401 each time. Related to algorithms. The algorithm is similar to base64 encryption: time-stamp H (time-stamp ":" etag ":" private-key ). Time-stamp is the server clock, and etag is the request's etag header. Private-key is a value known to the server.
Opaque: the original response is returned when the client initiates a request. It is best to use a base64 string or a hexadecimal string.
Auth-Param: used for extension, which is ignored at this stage.
For other fields, see rfc2617.

Authorization Header Syntax:

Credentials = "Digest" digest-Response
Digest-response = 1 # (username | realm | nonce | digest-Uri
| Response | [algorithm] | [cnonce] |
[Opaque] | [Message-qop] |
[Nonce-count] | [auth-Param])

Username = "username" "=" username-Value
Username-value = quoted-string
Digest-uri = "Uri" "=" digest-Uri-Value
Digest-Uri-value = request-Uri; as specified by HTTP/1.1
Message-qop = "qop" "=" qop-Value
Cnonce = "cnonce" "=" cnonce-Value
Cnonce-value = nonce-Value
Nonce-Count = "nc" "=" nc-Value
NC-value = 8 lhex
Response = "response" "=" request-Digest
Request-digest = <"> 32 lhex <">
Lhex = "0" | "1" | "2" | "3" |
"4" | "5" | "6" | "7" |
"8" | "9" | "A" | "B" |
"C" | "D" | "E" | "F"

Response: encrypted password
Digest-Uri: Copy request-line for proxy
Cnonce: If qop is set, it is used for two-way authentication to prevent attacks.
Nonce-count: if the server sees the same count, it is a replay.

Example:

401 response: HTTP/1.1 401 unauthorized
WWW-Authenticate: Digest
Realm = "testrealm@host.com ",
Qop = "auth, Auth-int ",
Nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093 ",
Opaque = "5ccc069c403ebaf9f0171e9517f40e41"
Request again:
Authorization: Digest username = "Mufasa ",
Realm = "testrealm@host.com ",
Nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093 ",
Uri = "/DIR/index.html ",
Qop = auth,
NC = 00000001,
Cnonce = "0a4f113b ",
Response = "6629fae49393a05417978507c4ef1 ",
Opaque = "5ccc069c403ebaf9f0171e9517f40e41"

4. Compared with basic authentication and digest access authentication, they are very fragile. Basic Authentication allows eavesdroppers to directly obtain the user name and password, while digest access authentication eavesdroppers can only obtain the document for one request.