前段时间给客户网站做新浪微博账号登录功能，对OAuth协议以及相关的一些安全协议做了一些研究，顺便就记录一下学习心得吧。在这里就不打算具体讲OAuth的协议流程了，而是针对OAuth请求头里的nonce（随机数）、timestamp（时间戳）、signatrue（签名）这些参数的作用做一下总结。
首先看一下HTTP规范里定义的Basic认证。
Basic认证是一个流程比较简单的协议，整个过程可以分为以下三个步骤：
a） 客户端使用GET方法向服务器请求资源。
b） 服务器返回401响应码和WWW-Authentication：Basic realm=”Family”响应头要求客户端进行身份验证。其中realm声明了资源所在的域。
c） 浏览器接收到以上HTTP响应头后，弹出登录框要求用户输入用户名和密码；用户提交的用户名和密码通过冒号串联起来并对其进行BASE64编码后再提交到服务器；服务器对提交上来的BASE64字符串进行验证，如果验证通过则返回200响应码。
Basic认证固然简单、便利，但它只能作为对非敏感资料的接见认证，因为它并不安然，首要发挥解析在以下几个方面：
1、 客户端提交的用户名和暗码只经过简单的编码，进击者只要****到该数据包，便可很轻易的将其反编码为原始用户名和暗码。
2、 即使客户端应用了一种比BASE64更错杂的编码体式格式使得进击者无法对其反编码，进击者也可以应用fiddler等对象将阻碍到的HTTP报文从头提交给办事器，办事器只对编码的字符串进行验证，所以验证同样能经由过程。这种进击办法称之为重放进击（Replay-Attack）。
以上两个题目也是各类身份认证和谈须要推敲到的安然题目，包含OAuth、Digest认证、NTLM认证等等认证机制都应用了nonce和timestamp来解决这些题目。
Nonce是由办事器生成的一个随机数，在客户端第一次恳求页面时将其发还客户端；客户端拿到这个Nonce，将其与用户暗码串联在一路并进行非可逆加密（MD5、SHA1等等），然后将这个加密后的字符串和用户名、Nonce、加密算法名称一路发还办事器；办事器应用接管到的用户名到数据库搜刮暗码，然后跟客户端应用同样的算法对其进行加密，接着将其与客户端提交上来的加密字符串进行斗劲，若是两个字符串一致就默示用户身份有效。如许就解决了用户暗码明文被窃取的题目，进击者就算知道了算法名和nonce也无法解密出暗码。
每个nonce只能供一个用户应用一次，如许就可以防止进击者应用重放进击，因为该Http报文已经无效。可选的实现体式格式是把每一次恳求的Nonce保存到数据库，客户端再一次提交恳求时将恳求头中得Nonce与数据库中得数据作斗劲，若是已存在该Nonce，则证实该恳求有可能是恶意的。然而这种解决规划也有个题目，很有可能在两次正常的资料恳求中，产生的随机数是一样的，如许就造成正常的恳求也被当成了进击，跟着数据库中保存的随机数络续增多，这个题目就会变得很明显。所以，还须要加上别的一个参数Timestamp（时候戳）。
Timestamp是按照办事器当前时候生成的一个字符串，与nonce放在一路，可以默示办事器在某个时候点生成的随机数。如许就算生成的随机数雷同，但因为它们生成的时候点不一样，所以也算有效的随机数。
题目又来了，跟着用户接见的增长，数据库中保存的nonce/timestamp/username数据量会变得很是大。对于这个题目，可选的解决规划是对数据设定一个&＃8220;过期时候&＃8221;，比如说在数据库中保存跨越一天的数据将会被清除。若是是如许的，进击者可以守候一天后，再将阻碍到的HTTP报文提交到办事器，这时辰因为nonce/timestamp/username数据已被办事器清除，恳求将会被认为是有效的。要解决这个题目，就须要给时候戳设置一个超不时候，比如说将时候戳与办事器当前时候斗劲，若是相差一天则认为该时候戳是无效的。
很不幸的是，经过上方这些错杂的处理惩罚后，我们的数据传输仍然是不安然的。我们都知道，http报文是以明文的体式格式在收集中传输的，包含Basic认证、Digest认证、OAuth、NTLM等等验证这一些认证机制都只是对HTTP头的信息作保护，而对于Http消息体的数据却没有作加密。以新浪首页的登录为例，它的账号就是以明文的体式格式传送的，如下图所示：
这样的方式是很不安全的，用户名和密码完全以明文的方式提交了。同样是新浪的网站——新浪微博就在登录前作了加密过的，如下图所示：
加密的方法可以参考前面讲到的nonce+timestamp的方案。不过这只解决了登录的问题，在注册时就不能提交使用nonce和timestamp非可逆加密了，这个时候要使用非对称加密。在用户打开注册页时，服务器生成一个公钥/私钥对并将公钥返回给客户端，客户端使用该公钥将密码加密后提交到服务器，服务器使用私钥解密后再保存到数据库。非对称加密算法的特点是每一个公钥和私钥都是一一对应的，使用公钥加密后只有拥有私钥的人才能进行解密，所以攻击者截取到http报文也毫无用处。
当然，在条件允许的情况下，可以使用SSL来实现HTTP报文的加密，这种方案是在应用层和传输层中间添加一个SSL层，该层使用对称加密的方法将HTTP报文加密后再传递到传输层，如下图所示：
在这之前，客户端与服务器需要使用非对称加密的方法来协商用于对称加密的公钥，对称加密要求加密者和解密者拥有同一个密钥（即公钥）。当客户端首次访问页面时，需要生成一个公钥给服务器，而这个公钥不是不可以给第三方知道的（知道了这个公钥就可对数据进行解密了），所以需要服务器首先生成一个公钥/密钥对，并使用生成的公钥加密客户端生成的公钥（非对称加密），这一个过程与前面讲到的注册密码加密的方式类似。
正因为在正式数据传输之前需要在服务器跟客户端之间进行几轮的协商，所以HTTPS相比HTTP来说安全性会高些、而性能会差些。
