我该做什么请记住，在最初的请求中，用户使用基于SSL的基本身份验证发送其凭据。服务器对凭据进行身份验证后，便会创建一个安全令牌并将其发送回用户，以便他们可以在后续请求中使用该令牌，直到令牌过期或被吊销为止。
我正在寻找一些建议，例如关于如何生成不会受到MoM / Replay攻击等影响的令牌以及确保无法提取令牌中存储的数据的说明。
我将使用以下内容生成令牌的方法，我认为这会阻止从中提取任何数据。但是，我仍然需要确保它不受其他攻击的侵害。
只能通过SSL访问该API，但是我不确定我是否可以完全从安全角度上依靠它。
/>
#1 楼
“身份验证令牌”的工作方式取决于服务器如何记住它。通用令牌是随机字符串；服务器在其数据库中保留从发出的令牌到经过身份验证的用户名的映射。可以自动删除旧令牌，以防止服务器的数据库无限期增长。只要攻击者不能以不可忽略的概率创建有效令牌，这样的令牌就足以保证安全，“有效令牌”是“在已发射令牌的数据库中的令牌”。令牌值的长度至少为16个字节并由具有加密功能的PRNG生成就足够了（例如，根据您的平台，例如
/dev/urandom，CryptGenRandom()，java.security.SecureRandom ...）。可以卸载客户本身的存储需求。在上面的段落中，服务器应该为令牌提供哪些“内存”？即用户名和令牌的生产日期。因此，像这样创建令牌：
服务器具有密钥K（由加密安全PRNG生成的128位序列）。
令牌包含用户名（U），发布时间（T）以及在U和T上（一起）计算的键控完整性检查，键控完整性检查用K键（默认情况下，使用HMAC搭配SHA-256或SHA-1）。 br />
借助对K的了解，服务器可以验证用户发回的给定令牌是否是其自己的令牌；但是攻击者无法伪造此类令牌。
您链接到的答案看起来有点像那样，除了它谈论的是加密而不是MAC，并且是：
confused;
令人困惑；
可能不安全；
，因为加密不是MAC。
评论
+1这与我要寻找的答案类型大致相同，谢谢。您提到了所提出的用于生成令牌的解决方案可能不安全，并且我理解为什么（如果已加密，则有可能被解密）。但是，它是使用服务器的机器密钥加密的（请参见此处），所以我说的是对的，只要我的服务器在物理上是安全的并且没有人拥有解密密钥就可以了吗？
–詹姆斯
2012年9月3日14:59
@James：我的意思是，只要攻击者无法构建伪造的令牌，身份验证令牌就是安全的。加密无法防止这种情况。例如，如果使用类似RC4的流密码（通过与密钥生成的伪随机流进行XOR运算来加密数据），那么用户以其姓名进行身份验证将很简单，然后用这些位来摆弄新的有效令牌，他选择的另一个名称（只要它的大小与他的名字相同）（并且我已经在部署的银行系统中看到了该名称！）。确实，如果需要完整性，请使用MAC。
–托马斯·波宁（Thomas Pornin）
2012年9月3日15:06
根据您的评论，这就是我正在做的事情（服务器端）。使用.NET RNG生成256位的秘密密钥。然后使用用户名的SHA12 +令牌的创建日期（使用密钥）生成HMAC。然后最后，再次使用密钥生成最终用户名+创建日期+ HMAC（用户名+创建日期）的HMAC。那个听起来是对的吗？如果需要，我可以发布代码。
–詹姆斯
2012年9月3日于20:41
作为记录，原始问题中链接的标准ASP.NET功能确实涉及MAC。方法名称Encrypt（）具有误导性。它实际上所做的包括HMAC（带有SHA256）和加密（带有AES）。
– Erv Walter
2012年9月16日在22:18
@ThomasPornin谢谢您的很好回答。当您说“可以减轻客户端自身的存储要求”时，是否意味着服务器不需要存储任何已发行令牌的信息？由于令牌是由服务器本身签名的，并携带所有相关信息（用户名和有效期限），因此服务器不需要查询其数据库以将令牌与用户绑定并检查有效期限-令牌中的所有数据均可用，并且不能如果已检查其签名，则已更改。正确？
– Janus Varmarken
16年7月14日在13:43
#2 楼
简而言之，您应该使用一次加密强度的随机令牌，并在数据库中对其进行哈希处理。令牌
只允许使用一次，
只能用于为其创建的用户，
只能通过HTTPS发送，
应该有有效期（例如7天）。
用户使用令牌登录后，该令牌无效，应创建一个新令牌并将其分配给用户。如果令牌已过期，则必须使用户使用其真实凭据再次登录。
有关这些规则的更详细和冗长的描述，请参见《基于表单的网站权威指南》的第2部分。身份验证：
永久登录Cookies（“记住我”功能）是危险区域；一方面，当用户了解如何处理它们时，它们与传统登录完全一样安全；另一方面，对于大多数用户而言，它们是巨大的安全风险，因为这些用户在公用计算机上使用它们，忘记注销，不知道什么是cookie或如何删除它们，等等。
[...]
关注Charles Miller的“最佳做法”文章。不要试图遵循本文末尾链接的“改进的”最佳实践。可悲的是，该方案的“改进”很容易受到挫败（攻击者在窃取“改进的” cookie时所要做的所有事情都必须记住删除旧的cookie。这将要求合法用户重新登录，并创建一个新的系列标识符并将被盗的密码保留为有效）。
不要将永久性登录COOKIE（令牌）存储在您的数据库中，仅是一种哈希！登录令牌等效于密码，因此，如果攻击者将您的手放在您的数据库上，他可以使用这些令牌登录到任何帐户，就像它们是明文登录密码组合一样。因此，在存储持久性登录令牌时，请使用强盐散列（bcrypt / phpass）。
更新：对不起，我误解了这个问题。您链接的方法看起来很合理，但不能保护您免受重放攻击或中间人攻击。您应该在其旁边使用SSL。
评论
您会说“加密强度一次性随机令牌”对此是否足够安全？ “一旦用户使用令牌登录，它就无效，应该创建一个新令牌。”我不确定我是否知道该如何工作。您是说要根据每个请求使令牌无效/重新发行吗？
–詹姆斯
2012年9月3日12:17
@James当用户来到站点并且没有会话时，cookie令牌将发送到服务器。服务器对其进行验证，以登录用户的身份创建一个新会话，并使令牌无效。然后，它为用户提供了一个新令牌。会话在他们使用网站时识别了他们，但是当他们关闭浏览器（或会话终止）时，用户不再登录。当他们回来时，他们没有会话，并且您赋予他们的新令牌允许您创建一个新会话（返回步骤1）
–多项式
2012年9月3日于12:21
@Polynomail就我而言，没有cookie，会话或浏览器的概念。这是一个REST API，可通过移动应用程序进行访问。
–詹姆斯
2012年9月3日12:23
@James对不起，这个问题被误解了。您链接的机制适用于这种情况，但是它不能保护您免受重放攻击。您需要使用类似SSL的内容来防止MitM /重放。
–多项式
2012年9月3日于12:29
该API在HTTPS上运行，因此可以安全地假设我不会受到这类攻击吗？我想我可能过于偏执，但是，当涉及到网络安全性时，我认为这样做是一件好事！
–詹姆斯
2012年9月3日12:31
#3 楼
纯粹的RESTful API Web服务应使用基础协议标准功能：对于HTTP，RESTful API应该包含并遵守现有的HTTP标准标头，状态代码和方法。添加新的HTTP标头违反了REST原则。RESTful服务必须是无状态的。任何技巧，例如基于令牌的身份验证试图记住服务器上先前REST请求的状态，都违反了REST原则。
底线：出于身份验证/授权的目的，应使用HTTP授权标头。并且，您应该在每个需要认证的后续请求中添加特定的HTTP授权方案标头。
我为Cisco Prime Performance Manager应用程序开发了RESTful Web服务。在Google上搜索我为该应用程序编写的Cisco Prime Performance Manager REST API文档，以获取有关RESTFul API合规性的更多详细信息-参见下文。对于此应用程序，我们选择使用HTTP“基本”授权方案对请求进行身份验证和授权。显然，当使用HTTP授权时，我们正在使用HTTP加密从客户端到服务器的所有传输数据。
http://www.cisco.com/c/en/us/support /cloud-systems-management/prime-performance-manager/products-programming-reference-guides-list.html
评论
如果不允许使用基于令牌的方法，这是否意味着客户端必须在每个请求上存储并重新发送用户名和密码，并确定何时使它们无效？
–迈克尔
2014年11月8日下午4:49
几件事情-谁说我没有使用授权标头？令牌身份验证仍然是无状态的，服务器无法记住当前请求之外的任何内容-令牌仅用作票证，表示“嘿，我以前来过，他是证明，因此您可以跳过身份验证步骤”。
–詹姆斯
2014-12-16 15:35
评论
OAuth呢？@MikeWeller OAuth可能是解决此问题的通用解决方案，但是，时间限制和开发的复杂性却在下降。另外，OAuth可能有点过大，因为目前尚无计划向第三方开放API。我想要实现的基于令牌的系统与OAuth的功能相差不远，它更像Twitter的XAuth版本，您可以跳过整个登录请求部分。
编写自己的会话管理机制（本质上是您所建议的）时要非常小心。每个新的会话管理机制中不可避免地会发生许多常见错误，这些错误也将影响您。您应该认真考虑如何使用现有机制，而不是自己动手