Shulou(Shulou.com)06/03 Report--

authentication

Certification is to give some X X Ming. When ××× is presented with a photograph, such as a passport or driver's license, some evidence is given that you are who you claim to be. When you enter a PIN at an ATM or a password in a dialog box on a computer system, you are proving that you are who you claim to be

Now, none of these strategies are absolutely effective. Passwords can be guessed or overheard, ××× pieces stolen or forged, but each type of evidence helps build reasonable confidence that you are who you claim to be.

HTTP Challenge/Response Authentication Framework

HTTP provides a native challenge/response framework that simplifies the authentication process for users. HTTP authentication model is shown below

When a Web application receives an HTTP request message, instead of acting on the request, the server responds with an "authentication challenge," challenging the user to provide some confidential information about who he is

When the user initiates a request again, he/she must attach a confidentiality certificate (username and password). If the certificates do not match, the server can challenge the client again or generate an error message. If the certificate matches, the request can be completed normally

[Authentication protocol and header]

HTTP provides an extensible framework for different authentication protocols through a set of customizable control headers. The following table lists header formats and contents that vary with authentication protocols. The authentication protocol is also specified in the HTTP authentication header.

HTTP defines two official authentication protocols: basic authentication and digest authentication. In the future, people will be free to design new protocols that use the HTTP Challenge/Response framework

An example of basic authentication is shown below

When the server challenges the user, it returns a 401 Unauthorized response with a WWW-Authenticate header explaining how and where to authenticate.

When the client authorization server continues processing, it resends the request, but appends the encrypted password and other authentication parameters to the Authorization header

When the authorization request is successfully completed, the server will return a normal status code (e.g., 200 OK). For high-level authentication algorithms, some additional information may be appended to the Authentication-Info header.

[Security Domain]

Before we get into the details of basic authentication, we need to explain how HTTP allows servers to use different access rights for different resources. The WWW-Authenticate challenge in Figure (b) above contains a realm directive. The Web server organizes protected documents into a security realm. Each security domain can have a different set of authorized users

For example, suppose a Web server establishes two security domains: one for corporate financial information and one for personal family documents. Different users have different access rights to each security domain. The CEO of a company should be able to access sales forecasts, but he should not be allowed to access photos of employees and their families on vacation.

Here is a hypothetical basic authentication challenge that specifies a domain:

HTTP/1.0 401 UnauthorizedWWW-Authenticate： Basic realm="Corporate Financials"

Fields should have a descriptive character name, such as Corporate Financials, to help users understand which username and password to use. It is also helpful to list the server host name in the name of the security domain--for example, executive-committee @ bigcompany. com

basic authentication

Basic authentication is the most popular HTTP authentication protocol. Almost every major client and server implements basic authentication mechanisms. Basic authentication was originally proposed in the HTTP/1.0 specification, but has since been moved to RFC 2617, which details HTTP authentication mechanisms.

In basic authentication, the Web server can reject a transaction, challenge the client, and ask the user for a valid username and password. The server will return a 401 status code instead of a 200 status code to initialize the authentication challenge and specify the security domain to access with the WWW-Authenticate response header. When the browser receives a challenge, it opens a dialog asking the user to enter a username and password for the domain. Then scramble the username and password slightly, and then send it back to the server with the Authorization request header.

[Basic certification example]

Below is a detailed example of basic authentication

In Figure a, the user requested a private family photo/family/jeff.jpg

In Figure b, the server sends back a 401 Authorization Required, a password challenge to a private family photo, along with a WWW-Authenticate header. This header requests basic authentication of the Family domain

In Figure c, the browser receives a 401 challenge, which pops up a dialog asking for the username and password for the Family domain. When a user enters a username and password, the browser concatenates them with a colon, encodes them in a scrambled Base-64 representation, and sends them back in the Authorization header

In Figure d, the server decodes the username and password, verifies their correctness, and returns the requested message with an HTTP 200 OK message

The following table summarizes WWW-Authenticate and Authorization headers for HTTP Basic Authentication

[Note] Basic authentication protocol does not use Authentication-Info header

[Base-64 username/password code]

HTTP basic authentication packages a username and password (separated by colons) and encodes them in Base-64 encoding. In simple terms, Base-64 encoding divides an 8-bit byte sequence into 6-bit blocks. Each 6-digit block selects a character from a special 64-character alphabet that contains most letters and numbers.

The figure below shows an example of basic authentication using Base-64 encoding. In this example, the username is brian-totty and the password is Ow!. The browser concatenates the username and password with colons to produce a wrapped string brian-totty:Ow!. Then Base-64 encode this string into a garbled string: YnJpYW4tdG90dHk6T3ch

Base-64 encoding can accept binary strings, text, and international character representations of data (causing problems in some systems) and temporarily convert them into an easily portable alphabet for transmission. The original string can then be decoded at the far end without reporting a transmission error.

Base-64 encoding is useful for usernames and passwords that contain international characters or other characters that are illegal in HTTP headers (such as quotes, colons, and carriage returns). Also, Base-64 encoding scrambles user names and passwords, which also prevents administrators from accidentally seeing user names and passwords while administering servers and networks

[Agent certification]

The proxy server in the middle can also implement authentication functions. Some organizations use proxy servers to authenticate users before they can access servers, LANs, or wireless networks. Access policies can be centrally managed on a proxy server. Therefore, proxy servers are a convenient way to provide unified access control to resources within an organization. The first step in this process is identification through proxy authentication

The steps for proxy authentication are the same as for Web server authentication. But the headers and status codes are different. The following table lists the differences in status codes and headers used by Web servers and proxies in authentication

security flaws

Basic authentication is simple and convenient, but not secure. It can only be used to prevent inadvertent access by non-malicious users or in conjunction with encryption techniques such as SSL

Basic authentication sends a username and password over the network in a form that is easy to decode. In fact, passwords are transmitted in plain text and can be read and captured by anyone. Although Base-64 encoding hides usernames and passwords, making it less likely that friendly users will inadvertently see passwords while observing the network, Base-64 encoded usernames and passwords can be easily decoded through a reverse encoding process, or even manually decoded in seconds with a pen and paper, so that Base-64 encoded passwords are actually transmitted "in plain text." If there is a possibility that motivated third-party users will intercept the username and password sent by basic authentication, send all HTTP transactions over SSL encrypted channels, or use a more secure authentication protocol such as Digest Authentication.

Even if the password is encrypted in a more difficult way to decode, the third party user can still capture the modified username and password and replay the modified username and password to the original server again and again to gain access to the server. Nothing can be done to prevent these replays ***

Even if basic authentication is used for less important applications, such as access control for a company's internal network or access to personalized content, some bad habits can make it dangerous. Many users are fed up with a large number of password-protected services and use the same username and password across these services. For example, *** would capture usernames and passwords in plaintext from free Internet mail sites and then discover that the same usernames and passwords could also be used to access important online banking sites

Basic authentication does not provide any protection against agents and intermediate nodes acting as intermediaries, which do not modify the authentication header, but modify the rest of the message, thus seriously changing the nature of the transaction

Fake servers can easily fool basic authentication. If the user can be convinced that he is connecting to a legitimate host protected by basic authentication when he actually connects to a malicious server or gateway, the attacker can ask the user to enter the password, store it for future use, and then fabricate an error message to the user.

All of this suggests that in friendly environments, or environments where privacy protection is desirable but not necessary, basic authentication can be used to provide convenient document personalization or access control protection. In this way, basic authentication can be used to prevent some curious users from inadvertently or accidentally accessing documents

For example, within a company, product management may password protect future product plans to prevent premature release of information. For the average user, basic authentication is enough to make them feel inconvenienced and stop accessing the data. Similarly, passwords may be used to protect private photos or private sites that are not highly confidential or have little information value, and that really have little to do with anyone else.

Basic authentication is made more secure by using it in conjunction with encrypted data transfers such as SSL to hide usernames and passwords from malicious users. It's a common technique.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.