访问axis2 身份验证_了解HTTP摘要访问身份验证

访问axis2 身份验证

Digest Access Authentication is one method that a client and server can use to exchange credentials over HTTP. This method uses a combination of the password and other bits of information to create an MD5 hash which is then sent to the server to authenticate. Sending a hash avoids the problems with sending a password in clear text, a shortfall of Basic Access Authentication.

摘要访问身份验证是客户端和服务器可用于通过HTTP交换凭据的一种方法。 此方法使用密码和其他信息位的组合来创建MD5哈希，然后将其发送到服务器进行身份验证。 发送哈希可以避免以明文形式发送密码的问题，这是基本访问身份验证的不足之处。

Digest Access was originally defined in RFC 2069, and optional security enhancements were later added in RFC 2617 which should be considered the current standard if you wish to implement this method yourself. We’ll have a look at both in this article.

摘要访问最初是在RFC 2069中定义的，后来在RFC 2617中添加了可选的安全性增强功能，如果您希望自己实现此方法，则应将其视为当前标准。 我们将在本文中对两者进行介绍。

基本访问身份验证的问题 (The Problem with Basic Access Authentication)

First, lets look a Basic Access Authentication. With your browser, you request some sort of object that requires you to authenticate yourself. If the browser hasn’t cached credentials you’ve already provided, you’ll be met with a “HTTP 401 Not Authorized” response which includes the following header:

首先，让我们看一下基本访问身份验证。 使用浏览器，您需要某种需要您进行身份验证的对象。 如果浏览器还没有缓存您已经提供的凭据，则会收到“ HTTP 401未经授权”响应，其中包括以下标头：

WWW-Authenticate: Basic realm="example.com"

The client/browser is then expected to respond with the appropriate credentials in order to be allowed access.

然后，希望客户端/浏览器以适当的凭据进行响应，以便被允许访问。

The username and password are concatenated together, like “admin:p@ssw0rd”, This string is then Base64 encoded. The encoded string (YWRtaW46cEBzc3cwcmQ=) is used in an Authorization header which is sent back to the server.

用户名和密码是串联在一起的，例如“ admin：p @ ssw0rd”，然后此字符串经过Base64编码。 编码的字符串(YWRtaW46cEBzc3cwcmQ =)在“授权”标头中使用，该标头被发送回服务器。

Authorization: Basic YWRtaW46cEBzc3cwcmQ=

When the server receives this request, it notices the Authorization header and applies the steps in reverse (decode and split the resulting string) to get the original username and password. The process can then do whatever lookup/verification is necessary with the credentials.

当服务器收到此请求时，它会注意到Authorization标头，并反向应用这些步骤(解码并拆分结果字符串)以获取原始用户名和密码。 然后，该过程可以使用凭据执行所需的任何查找/验证。

The major problem here is that Base64 is a data transfer scheme; it’s not a hashing or encryption scheme. It may as well be clear text. Digest Access Authentication tries to improve upon this by sending the password as a hashed value, which is much harder (not impossible) to reverse engineer a clear text value from.

这里的主要问题是Base64是一种数据传输方案。 它不是哈希或加密方案。 它也可能是明文。 摘要访问身份验证试图通过将密码作为散列值发送来改善此情况，这对于反向工程明文值来说要困难得多(并非不可能)。

使用摘要访问身份验证 (Working with Digest Access Authentication)

When working with Digest Access Authentication, it’s the server who must make the first move when it discovers a client is trying to access a restricted area. There are a few values the server needs to provide as part of the WWW-Authenticate header that the client needs.

使用摘要访问身份验证时，服务器必须在发现客户端正在尝试访问受限区域时首先采取措施。 服务器需要提供一些值作为客户端需要的WWW-Authenticate标头的一部分。

The server generates a value, referred to as nonce, which should be unique for each request. It’s recommended this value be either Base64 or hexadecimal, specifically because it will be enclosed in double quotes and we want to ensure there are no double quotes in the string. The nonce will be used by the client to generate a hash to send back to the server.

服务器会生成一个称为nonce的值，该值对于每个请求都应该是唯一的。 建议此值为Base64或十六进制，特别是因为它将用双引号引起来，并且我们要确保字符串中没有双引号。 客户端将使用随机数生成哈希以发送回服务器。

In PHP, applying md5() to a unique string is generally sufficient.

在PHP中，将md5()应用于唯一字符串通常就足够了。

<?php
$nonce = md5(uniqid());

The next value needed by the client is opaque. This is another unique string generated by the server and is expected to be sent and returned by the client unaltered.

客户需要的下一个值是opaque 。 这是服务器生成的另一个唯一字符串，预期客户端将原封不动地发送和返回该字符串。

<?php
$opaque = md5(uniqid());

The last value, realm, is just a string to display to users so they know which username and password they should provide. It’s also used by the client to generate a hash to send back to the server.

最后一个值realm只是要显示给用户的字符串，因此他们知道应提供的用户名和密码。 客户端还使用它生成哈希以发送回服务器。

<?php
$realm = 'Authorized users of example.com';

All of these values are used to compose the WWW-Authenticate directive and send as a response to the client.

所有这些值都用于构成WWW-Authenticate指令，并作为响应发送给客户端。

<?php
if (empty($_SERVER['PHP_AUTH_DIGEST']) {
    header('HTTP/1.1 401 Unauthorized');
    header(sprintf('WWW-Authenticate: Digest realm="%s", nonce="%s", opaque="%s"', $realm, $nonce, $opaque));
    header('Content-Type: text/html');
    echo '<p>You need to authenticate.</p>';
    exit;
}

When the client receives this response, it has to compute a return hash. It does so by concatenating the username, realm, and password and hashing the result with MD5 as follows:

当客户端收到此响应时，它必须计算返回哈希。 通过串联用户名，领域和密码并使用MD5对结果进行哈希处理，如下所示：

1. Compute A1 as MD5("username:realm:password").

   将A1计算为MD5(" username : realm : password ") 。

2. Compute A2 as MD5("requestMethod:requestURI").

   将A2计算为MD5(" requestMethod : requestURI ") 。

3. Compute the final hash, know as “response”, as MD5("A1:nonce:A2").

   计算最终的哈希，即MD5("A1: nonce :A2") ，称为“响应”。

The client sends the response back to the server in an Authorization header and includes the username, realm, nonce, opaque, uri, and the computed response.

客户端在Authorization标头中将响应发送回服务器，并包括用户名，领域，随机数，不透明，uri和计算出的响应。

Authorization: Digest username="%s", realm="%s", nonce="%s", opaque="%s", uri="%s", response="%s"'

Note that realm, nonce, and opaque are all returned to the server unchanged.

请注意，领域，随机数和不透明性均未更改地返回到服务器。

When the server receives the response, the same steps are taken to compute the server’s version of the hash. If the computed hash and the received response hash values match, then the request is considered authorized. It looks something like this:

当服务器收到响应时，将执行相同的步骤来计算服务器的哈希版本。 如果计算出的哈希值和接收到的响应哈希值匹配，则该请求被视为已授权。 看起来像这样：

<?php
$A1 = md5("$username:$realm:$password");
$A2 = md5($_SERVER['REQUEST_METHOD'] . ":$uri");
$response = md5("$A1:$nonce:$A2");

Of course, the user’s password is never passed to the server. To perform authentication look ups from a database then, the value of A1 can be stored. Keep in mind however the stored hash becomes invalid if you ever change your realm.

当然，用户密码永远不会传递到服务器。 为了从数据库执行认证查询，可以存储A1的值。 请记住，但是如果您更改了领域，则存储的哈希将变得无效。

原始摘要访问规范的改进 (Improving on the Original Digest Access Spec)

Now that you’re familiar with the workings of Digest Access Authentication from RFC 2069, let’s turn our attention to some of the enhancements that were added in 2617: qop, nc, and cnonce.

现在您已经熟悉了RFC 2069中的摘要式访问身份验证的工作原理，下面我们将注意力转向2617中添加的一些增强功能：qop，nc和cnonce。

qop, or quality of protection, is specified in the WWW-Authenticate header and can have a value of “auth” or “auth-int”. When no qop directive is found or when it is set to “auth”, Digest Access is used for client authentication only – the default mode which you’ve seen so far. When set to “auth-int”, an attempt is made to provide some level of integrity protection of the response as well and the client must also include the request body as part of the message digest. This allows the server to determine whether the request has been adulterated in transfer between the indented client and intended server.

在WWW-Authenticate标头中指定了qop或保护质量，其值可以为“ auth”或“ auth-int”。 如果找不到qop指令，或者将其设置为“ auth”，则Digest Access仅用于客户端身份验证-到目前为止，您已经看到了默认模式。 当设置为“ auth-int”时，也会尝试为响应提供某种程度的完整性保护，并且客户端还必须将请求正文作为消息摘要的一部分包括在内。 这允许服务器确定请求是否已在缩进客户端和预期服务器之间进行传输时被掺假。

The client nonce, or cnonce, is similar to nonce but is generated by the client. The cnonce figures into the response digest computed by the client and its original value is passed along to the server so that it can be used there to compare digests. This provides some response integrity and mutual authentication, in that both the client and server have a way to prove they know a shared secret. When the qop directive is sent by the server, the client must include a cnonce value.

客户端随机数或cnonce类似于随机数，但由客户端生成。 Cnonce会计入客户端计算的响应摘要中，并将其原始值传递到服务器，以便可以在服务器上用于比较摘要。 这提供了一些响应完整性和相互认证，因为客户端和服务器都可以证明自己知道共享的机密。 当服务器发送qop指令时，客户端必须包含一个cnonce值。

The nonce count, nc, is a hexadecimal count of the number of requests that the client has sent with a given nonce value. This way, the server can guard against replay attacks.

随机数nc是客户机以给定的随机数值发送的请求数的十六进制计数。 这样，服务器可以防范重放攻击。

With the enhancements, the computation of A2 and the response goes something like this:

通过增强，A2的计算和响应如下所示：

<?php
if ($qop == 'auth-int') {
    $A2 = md5($_SERVER['REQUEST_METHOD'] . ":$uri:" . md5($respBody));
}
else {
    $A2 = md5($_SERVER['REQUEST_METHOD'] . ":$uri");
}
$response = md5("$A1:$nonce:$nc:$cnonce:$qop:$A2");

摘要式访问身份验证的优点和缺点 (Strengths and Weaknesses of Digest Access Authentication)

Digest Access has some advantages over Basic Authentication, since Basic Authentication uses a clear-text exchange of username and passwords, which is almost the same as telling the world what your password is. Digest Access passes a hashed value and not the password itself, so it’s much more secure than Basic Auth. The server nonce, which should be unique per request, will drastically change the computed hash on each new request, and the nc value provided by RFC 2617 is helpful at preventing replay attacks, whereby a malicious individual is able to intercept your request data and “replay” or repeat it as his own request.

摘要访问比基本身份验证具有一些优势，因为基本身份验证使用用户名和密码的明文交换，这几乎与告诉世界您的密码相同。 摘要访问传递的是散列值而不是密码本身，因此它比基本身份验证安全得多。 服务器随机数(每个请求应唯一)将彻底更改每个新请求的计算得出的哈希值，RFC 2617提供的nc值有助于防止重放攻击，从而使恶意个人能够拦截您的请求数据，并且“重播”或按自己的要求重复。

There are a few weaknesses with Digest Authentication as well. When RFC 2617 replaced the original specification, the enhancements that were added to provide extra security measures between the client and server were made purely optional, and Digest Authentication will proceed in its original RFC 2069 form when not implemented.

摘要式身份验证也有一些缺点。 当RFC 2617取代原始规范时，为在客户端和服务器之间提供额外安全措施而添加的增强功能完全是可选的，并且摘要身份验证在未实现时将以其原始RFC 2069形式进行。

Another problem is MD5 is not a strong hashing algorithm. All it takes is time and CPU to brute force the original value back to life. Bcrypt is preferable as it is more resilient against brute force attacks. There’s also no way for a server to verify the identity of the requesting client when using Digest Access Authentication. This opens the possibility for man in the middle attacks, where a client can be led to believe a given server is really who he thinks it is, but ends up sending his login credentials to an unknown entity.

另一个问题是MD5不是强大的哈希算法。 只需要时间和CPU即可将原始值恢复原状。 Bcrypt是更可取的，因为它在抵御暴力攻击方面更具弹性。 使用摘要访问身份验证时，服务器也无法验证请求客户端的身份。 这为中间攻击中的人员打开了可能性，在这种情况下，可以使客户端相信给定的服务器确实是他认为的真实身份，但最终会将其登录凭据发送给未知实体。

Your best bet when dealing with authentication is to use SSL and encrypt passwords using Bcrypt. You can use Basic Authentication or a home brewed authentication mechanism over SSL, but for situations where SSL is not possible for whatever reason, Digest Access is better than simple Basic Authentication and sending passwords in plain text over the public Internet.

处理身份验证时，最好的选择是使用SSL并使用Bcrypt加密密码。 您可以在SSL上使用基本身份验证或家庭酿造的身份验证机制，但是在由于某种原因无法使用SSL的情况下，摘要访问比简单的基本身份验证和通过公用Internet以纯文本形式发送密码要好。

There’s a simple example of RFC-2069 HTTP Digest Access available on GitHub to accompany this article. If you’re the type of person who likes to explore and tinker, feel free to clone it. A good place to start your exercise is to make the necessary modifications to work with accounts stored in a database instead of the hard-coded credentials in the script (remember, you’ll need to calculate and store A1 as the user’s password hash for later lookup at login), and then enhance it with RFC-2617 features. Afterwards, you’ll have a pretty solid understanding of HTTP Digest Access Authentication.

GitHub上有一个简单的RFC-2069 HTTP Digest Access示例，可随本文一起提供。 如果您是喜欢探索和修补的人，请随时克隆它。 开始练习的一个好地方是进行必要的修改以使用存储在数据库中的帐户，而不是脚本中的硬编码凭据(请记住，您需要将A1计算并存储为用户的密码哈希，以供以后使用在登录时查找)，然后使用RFC-2617功能对其进行增强。 之后，您将对HTTP摘要访问身份验证有相当深入的了解。

摘要 (Summary)

By now you should have an idea of what your available HTTP authentication methods are.

现在，您应该对可用的HTTP身份验证方法有所了解。

Basic Authentication is the easiest to implement and also the least secure. Usernames and passwords are encoded in Base64 but effectively sent to the server in plain text.

基本身份验证是最容易实现的，也是最不安全的。 用户名和密码在Base64中编码，但是有效地以纯文本格式发送到服务器。

Digest Authentication improves on the Basic method by sending authentication data through MD5. While MD5 is still not a strong password encryption algorithm, it is much harder to decode than the plain text/Base64 method of Basic Authentication. In its original form, there were still problems of man in the middle attacks and not being able to confirm server identity, but these weaknesses have been improved in later revisions to the RFC.

摘要式身份验证通过通过MD5发送身份验证数据来改进基本方法。 尽管MD5仍然不是一种强大的密码加密算法，但与“基本身份验证”的纯文本/ Base64方法相比，它很难解码。 在其原始形式中，仍然存在中间人攻击和无法确认服务器身份的问题，但是这些缺陷在RFC的更高版本中得到了解决。

SSL is the most modern and secure method of sending user authentication data over the public Internet. But when SSL is not available, please use Digest over Basic authentication.

SSL是通过公共Internet发送用户身份验证数据的最现代，最安全的方法。 但是，如果SSL不可用，请使用Digest over Basic身份验证。

Image via Fotolia

图片来自Fotolia

翻译自: https://www.sitepoint.com/understanding-http-digest-access-authentication/

访问axis2 身份验证