消息验证码hmac_什么是HMAC身份验证，为什么有用？

最新推荐文章于 2024-07-15 11:00:00 发布

danpu0978

最新推荐文章于 2024-07-15 11:00:00 发布

阅读量762

点赞数

文章标签： python java 数据库人工智能区块链

原文链接：https://www.javacodegeeks.com/2012/10/what-is-hmac-authentication-and-why-is.html

版权

消息验证码hmac

首先，我将概述基于HMAC的基于HTTP的服务器API的身份验证选项，最后，我将为开发人员构建和使用基于HMAC的身份验证提供一些技巧。

最近，我在服务器API及其周围进行了大量研究和黑客研究。这些类型的API的身份验证实际上取决于服务的类型，分为两大类：

消费者或个人应用程序，通常使用简单的用户名和密码，在某些情况下使用OAuth，但这更多的是为了在受信任的第三方中标识个人授权会话。
基础结构应用程序通常使用一组与所有者/管理员凭据不同的凭据，并为企业或设备提供某种自动化API，以增强功能或控制某些内容。

对于基础结构API，我介绍了一些选项，下面将对这些选项进行详细说明。

基本认证

这是最简单的实现，并且对于某些实现可以很好地工作，但是由于用户名和密码随请求而出现，因此它需要传输级加密。有关此的更多信息，请参见Wikipedia文章。

摘要式身份验证

实际上，这比基本HMAC更加接近HMAC，它使用md5对身份验证属性进行哈希处理，从而使拦截和破坏用户名和密码属性更加困难。请注意，我建议阅读有关该主题的Wikipedia页面，总之，它比基本身份验证更安全，但是它完全取决于客户端软件中实现了多少种保护措施，并且密码的复杂性是一个因素。

请注意，与基本身份验证不同的是，这不需要SSL连接，因此请确保您已阅读Wikipedia文章，因为在中间攻击中有人存在一些问题。

HMAC验证

与以前的身份验证方法不同，据我所知，没有这样做的标准方法，因为这是Amazon Web Services所使用的主要身份验证方法，因此很好理解，并且有许多库实施它。要使用这种形式的身份验证，您需要使用密钥标识符和私钥，这两个标识符通常是在管理界面中生成的（下面有更多详细信息）。

需要特别注意的是，这种身份验证与BIG的区别之一是它对整个请求进行签名，如果包括content-md5，则基本上可以保证操作的真实性。如果中间一方出于恶意原因使用API调用，或者中介代理中的bug丢弃了一些重要的标头，则签名将不匹配。

使用HMAC身份验证摘要是使用提供的密钥使用URI，请求时间戳和一些其他标头（取决于实现）的组合来计算的。密钥标识符和使用Base64编码的摘要一起被合并并添加到授权标头中。

以下示例来自Amazon S3文档。

'Authorization: AWS ' + AWSAccessKeyId + ':'  + base64(hmac-sha1(VERB + '\n'
                   + CONTENT-MD5 + '\n'
                   + CONTENT-TYPE + '\n'
                   + DATE + '\n'
                   + CanonicalizedAmzHeaders + '\n'
                   + CanonicalizedResource))

这将导致一个HTTP请求，其标题如下所示。

PUT /quotes/nelson HTTP/1.0
Authorization: AWS 44CF9590006BF252F707:jZNOcbfWmD/A/f3hSvVzXZjM2HU=
Content-Md5: c8fdb181845a4ca6b8fec737b3581d76
Content-Type: text/html
Date: Thu, 17 Nov 2005 18:49:58 GMT
X-Amz-Meta-Author: foo@bar.com
X-Amz-Magic: abracadabra

请注意，冒号后的AWS有时被称为服务标签，我见过的大多数服务都遵循将其更改为名称缩写或HMAC的惯例。

如果我们仔细检查一下Amazon的实现，与普通的用户名和密码相比，有几个优点变得显而易见：

如前所述，HMAC身份验证通过对标头进行签名来保证请求的真实性，尤其是如果content-md5由服务器和客户端进行签名和检查的情况。
管理员可以生成任意数量的密钥对，并独立于其Amazon凭证使用它们。
如前所述，这些是计算值，可以进行优化以使其达到所需的最大大小，Amazon使用40个字符的SHA-1密码，具体取决于所使用的哈希算法。
无需SSL即可使用这种身份验证形式，因为永远不会真正传输秘密，而只会传输MAC。
由于密钥对独立于管理员凭据，因此在系统受到入侵而无法使用时，可以将其删除或禁用。

至于缺点，确实有一些缺点：

与Amazon交互的实现之外的实现没有太多一致性。
服务器端实现的数量很少，而且也非常不一致。
如果您确实决定建议自己构建自己的加密API，例如OpenSSL，对于以前没有直接使用过它们的人来说可能很难，那么一个字符的差异将带来完全不同的价值。
如果请求中的所有标头均已签名，则在服务器或客户端必须非常小心，以免由库注入或修改标头（更多详细信息，请参见下文）。

在我目前正在开发并且确实重写了一些现有实现的过程中，我认为我应该为图书馆作者整理一些提示。

编写API时，请确保您在网上检查请求，以确保您使用的HTTP库没有更改或“调整”任何内容，我在Content-Type中添加了字符编码属性。
测试您的标头顺序在请求分配时也是正确的，我使用的是哈希映射（自然顺序）的库，这可能会破坏您的签名，具体取决于实现方式。对于Amazon，它们要求您在计算签名之前按字母顺序对“额外”标题进行排序，并以小写形式对标题名称进行排序。
在将疯狂的Ruby库作为标题名称列表呈现给您的代码之前，请注意疯狂的Ruby库会乱写标题名称（是的，这是错误的形式）。
调试时，打印用于生成签名的规范字符串，最好使用诸如ruby inspect之类的东西来显示所有字符。这将有助于在开发过程中进行调试，并与服务器端实际减轻的负担进行比较。
观察各种客户端或服务器API如何引入或删除标题。

从安全角度来看，有两个基本建议。