网络安全那点事

网络安全水很深，零碎的也看了不少资料，但是总觉得很飘渺，可能是平时主要是做应用开发，而真正实践密码设计（cryptography）和安全设计（security）的机会比较少.

刚刚看了几篇文章 listed as following，有一些A-Ha moment，也能把我现有的关于web安全的知识窜起来，故记录在此：

http://gdp.globus.org/gt4-tutorial/multiplehtml/ch09s02.html

http://gdp.globus.org/gt4-tutorial/multiplehtml/ch09s03.html

http://gdp.globus.org/gt4-tutorial/multiplehtml/ch09s04.html

一，怎样保证通信安全？

这是个古老的问题，而且古人的经验告诉我们，暗号能够确保通信安全，与似乎，什么“天王盖地虎、宝塔镇河妖”开始登上了历史舞台，其实暗号也就是加密，是对原始信息的隐藏，到近代，加密发展成了一门科学， 也演绎了很多关于加密/解密 攻防大战的经典故事。

所以通过加密来保证通信安全是经过历史考验的可行方法。

二、加密学在网络的延伸

传统的加密大多都是对称加密（symmetric），也就是上锁和开锁都用同一把钥匙，但是internet是个天生就不安全的环境，一窜“my credit card num is 110945110945”从上海跑到北京，不知要经历多少个路由器，交换机，在通信期间，如果有坏人(man in the middle)要窃取你的数据，更是如囊中取物。那就加密吧，不过如果采用对称加密，而且这把钥匙每个人都有的话，那就跟没有加密是一样的。

解决方法是不对称加密（Asymmetric Encryption)，详细请参考上面的reference.

三、怎样保证数据的完整性？

OK, 采用不对称加密后，我们的通信数据不再担心被middle man窃听了，但是新的问题来了（人类总是有追求卓越和完美的本能），我怎么知道这个信息没有被篡改过并且是真实有效的呢？

判断有没有被篡改过，我们有数字签名(Digital Signature)， 很简单，sender用一套单向的哈希算法，生成源数据的摘要，此算法保证对源数据的任何更改都会产生不同的摘要，sender将源数据和摘要一起发给receiver，receiver收到数据后，用同样的算法再生成一次摘要，并将其与sender发过来的进行比对，如果一样，那么就可以断言信息没有被更改过。

四、怎样确保通信方身份真实有效？

数字签名解决了数据完整性问题，那么怎样保证和你通信的人是真实有效的呢，这个身份认证的事情，必须通过第三方来做，因为自己不能为自己做证啊，你说你就是“招商银行”，我凭什么要相信你呢，任何人都可以说自己是招行。如果银监会说，他确实是招商银行，你可以放心把银行密码告诉他，你才敢放心，是不是。这一套解决信任问题的方案就是数字证书(Digital Certificate)，这个第三方，我们管它叫CA（Certificate Authority), Authority应该是很有权威的，虽然不是银监会，但也是绝对可靠可信的，比较知名的有VeriSign，被Symantec收购了，我们公司就在用这个。

五、认证（Authentication），授权（Authorization），访问（Access）

输入用户名，密码，登陆系统，哦，还有验证码，早期的internet，包括现在的大部分应用，都是这种模式。但随着internet 发展，越来越多的service provider，要开放自己的service给第三方应用访问，特别是social network的兴起，这种需求变得越来越强烈，几乎变成大型网站的标配。

怎样让第三方应用访问用户资源，同时又不接触到用户的敏感信息呢？

如果传统的用户名，密码登陆验证，就以为着第三方必须知道user的用户名，密码，显然不满足我们的需求，怎么办呢？ 一帮聪明的人仔细研究了整个验证过程，然后将其分解、抽象成三个步骤，即认证（Authentication），授权（Authorization），访问（Access）。这让我不禁想起那句老话 “在计算机世界，任何问题都可以通过加一层来解决”，是的，加了Access Layer之后，前面的要求就能满足了，具体是怎样实现的，参看下文。

分解后，将访问资源同认证、授权解耦。也就是说认证、授权在一个地方先做，完成后获得一个Access Token， 然后利用这个Access Token去访问resource， 当然resource server要负责验证这个token的有效性，怎么验证呢？ 方法有多种，利用token作为reference id去Authorization server获取相关信息是常见的方式。

通过此方式，第三方只要引导user去完成Authentication 和 Authorization， 而不用touch到user credential information (username, password)， 利用上面步骤获得的Access Token 再去访问Resource server。 也就是OAuth的工作流程了。

    +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

                     Figure 1: Abstract Protocol Flow

参考：http://tools.ietf.org/html/rfc6749

版权声明：本文为博主原创文章，未经博主允许不得转载。