REST Web服务的身份验证令牌实现 [英] REST Web Service authentication token implementation

问题描述

我使用这将在Azure托管作为云服务的C＃实现REST Web服务。既然是一个REST服务，它是无状态的，因此没有cookie或会话状态。

I'm implementing a REST web service using C# which will be hosted on Azure as a cloud service. Since it is a REST service, it is stateless and therefore no cookies or session states.

Web服务只能通过HTTPS（证书由StartSSL.com提供）。

The web service can only be accessed over HTTPS (Certificate provided by StartSSL.com).

一旦用户成功登录到服务，他们会得到一个安全令牌。此令牌将在未来的通信提供身份验证。

Upon a user successfully logging into the service they will get a security token. This token will provide authentication in future communications.

令牌将包含客户端的时间戳，用户ID和IP地址。

The token will contain a timestamp, userid and ip address of the client.

所有的通信将只通过HTTPS发生，所以我不担心被拦截和重放攻击中使用的记号。令牌将有到期呢。

All communication will only happen over HTTPS so I'm not concerned about the token being intercepted and used in replay attacks; the token will have an expiry anyway.

由于这是一个面向公众的服务，不过，我担心有人可能会与该服务注册，登录，然后修改令牌，他们收到访问其他用户的帐户。

Since this is a public facing service I am however concerned that someone could register with the service, login and then modifying the token that they receive to access the accounts of other users.

我不知道如何最好地保护令牌的内容，并且还验证它没有被篡改。

I'm wondering how best to secure the content of the token and also verify that it hasn't been tampered with.

我打算做以下，以确保令牌：

I plan on doing the following to secure the token:

客户端成功登录到服务和服务所做的：

The client successfully logs into the service and the service does:

1. 生成一个随机值和SHA256散列它1000倍。


2. 生成私钥一次性会话密钥+散列随机值。


3. 哈希与SHA256 1000次，然后用它来加密令牌的会话密钥


4. 使用私有密钥使用RSA签名加密令牌。


5. 发送所述加密的令牌+签名+以未加密的JSON包散列随机值到客户端。

当客户端调用其将加密的令牌和签名以未加密的JSON包到服务的服务。该服务将

When the client calls a service it sends the encrypted token and signature in an unencrypted JSON package to the service. The service will

1. 重新创建私有密钥+散列随机值的会话密钥


2. 使用私有密钥验证签名


3. 使用哈希会话密钥来解密令牌


4. 检查令牌还没有到期


5. 与所请求的操作继续...

我真的不知道任何加密的，所以我有一些问题：

I don't really know anything about encryption so I have some questions:

1. 这是充分还是矫枉过正？


2. 我读来检测篡改我应该包括HMAC与令牌。因为我用私钥签名，我还需要一个HMAC？


3. 我应该使用，而不是RSA Rijndael算法？


4. 如果Rijndael算法是preferred，是生成IV需要解密？即我可以把它扔掉或者我需要发送它会把加密令牌？例如加密令牌+ HMAC + IV +散列随机值。

由于所有的通信发生在HTTPS上未加密的JSON包是不是真的加密，直到它到达客户机。

Since all communication happens over HTTPS the unencrypted JSON package isn't really unencrypted until it reaches the client.

此外，我可能要重新实现在PHP服务后让这一切都需要是可行的在PHP中也是如此。

Also I may want to re-implement the service in PHP later so this all needs to be doable in PHP as well.

感谢您的帮助。

推荐答案

您是真的结束了思维的令牌。说实话，最好的令牌安全依赖于随机性，或者更准确的未predictability 的。最好令牌是完全随机的。你是正确的，值得关注的是，用户将修改他/她的令牌，并使用它来访问其他人的帐户。这是被称为一个常见的​​攻击会话偷。这种攻击几乎是不可能的，当令牌是随机产生并在服务器端过期。使用用户的信息，如IP和/或时间戳是不好的做法，因为它提高了predictability。我没有在大学的攻击，成功地猜测是基于以微秒服务器时间戳，积极的令牌。应用笔者以为微秒会改变速度不够快，他们会被取消predictable，但事实并非如此。

You are really over-thinking the token. Truthfully, the best token security relies on randomness, or more accurately unpredictability. The best tokens are completely random. You are right that a concern is that a user will modify his/her token and use it to access the accounts of others. This is a common attack known as "session stealing." This attack is nearly impossible when the tokens are randomly generated and expired on the server side. Using the user's information such as IP and/or a time stamp is bad practice because it improves predictability. I did an attack in college that successfully guessed active tokens that were based on server time stamps in microseconds. The author of the application thought microseconds would change fast enough that they'd be unpredictable, but that was not the case.

您应该知道，当用户代理服务器之后，代理有时会查看纯文本格式的SSL请求（出于安全原因，许多代理将进行深度包检测）。出于这个原因，它是好的，你过期的会话。如果你没有你的用户将很容易受到攻击，如这一点，也有可能XSS和CSRF。

You should be aware that when users are behind proxy servers, the proxy will sometimes view their SSL requests in plain text (for security reasons, many proxies will perform deep packet inspection). For this reason it is good that you expire the sessions. If you didn't your users would be vulnerable to an attack such as this, and also possible XSS and CSRF.

RSA或Rijndael算法应该是足够充分，提供了一个合理的密钥长度。此外，你应该使用HMAC与令牌prevent篡改，即使你在上面签名。理论上这将是多余的，因为你用私钥签名。然而，HMAC是很好的测试，您的签名机制实现可能是有缺陷的。由于这个原因，最好使用HMAC。你会惊讶有多少滚你自己的安全实现有缺陷，导致他们妥协。

RSA or Rijndael should be plenty sufficient, provided a reasonable key length. Also, you should use an HMAC with the token to prevent tampering, even if you're signing it. In theory it would be redundant, since you're signing with a private key. However, HMAC is very well tested, and your implementation of the signing mechanism could be flawed. For that reason it is better to use HMAC. You'd be surprised how many "roll your own" security implementations have flaws that lead them to compromise.

您的声音在安全pretty精明。保持良好的工作！我们需要更多的安全意识的开发者在这个世界上。

You sound pretty savvy on security. Keep up the good work! We need more security conscious devs in this world.

编辑：

它被认为是安全的，只要它们具有强烈的对称的秘密密钥（例如AES，河豚，等）进行加密，以包括在令牌时间戳/用户ID，只有服务器具有与作为只要令牌包括与它的防篡改散列，如HMAC，这是与秘密密钥一起与用户ID /时间戳的加密。散列保证完整性和加密保证保密性。

It is considered safe to include timestamps/user IDs in the token as long as they are encrypted with a strong symmetric secret key (like AES, Blowfish, etc) that only the server has and as long as the token includes a tamper-proof hash with it such as HMAC, which is encrypted with the secret key along with the user ID/timestamp. The hash guarantees integrity, and the encryption guarantees confidentiality.

如果您不包括在加密的HMAC（或其他哈希值），那么它有可能为用户与加密令牌篡改，并将它解密的东西有效。我没有在其中用户ID和时间戳进行加密，并作为无散列令牌服务器上的攻击。由字符串中改变一个随机字符，我能够从像58762改变我的用户ID 58531.虽然我挑不出新的用户ID，我是能够访问别人的帐户（这是在学术界作为一个疗程的一部分）。

If you don't include the HMAC (or other hash) in the encryption, then it is possible for users to tamper with the encrypted token and have it decrypt to something valid. I did an attack on a server in which the User ID and time stamp were encrypted and used as a token without a hash. By changing one random character in the string, I was able to change my user ID from something like 58762 to 58531. While I couldn't pick the "new" user ID, I was able to access someone else's account (this was in academia, as part of a course).

到这方面的一个替代方法是使用完全随机的令牌值，并且在服务器端映射它到所存储的用户ID /时间戳（其保持在服务器侧，因此客户端的外面控制）。这需要多一点的内存和处理能力，但更安全。这是一个决定，你必须逐案基础上做出的一个例子。

An alternative to this is to use a completely random token value, and map it on the server side to the stored User ID/time stamp (which stays on the server side and is thus outside of the clients control). This takes a little more memory and processing power, but is more secure. This is a decision you'll have to make on a case by case basis.

至于重用/从IV和其他键导出密钥，这通常是确定，只要该密钥只对很短的时间周期。在数学上是不可能有人能打破它们。这是可能然而。如果你想要去的路线偏执（我通常做），随机生成的所有新密钥。

As for reusing/deriving keys from the IV and other keys, this is usually ok, provided that the keys are only valid for a short period of time. Mathematically it is unlikely someone can break them. It is possible however. If you want to go the paranoid route (which I usually do), generate all new keys randomly.

这篇关于REST Web服务的身份验证令牌实现的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！