41
網絡安全那點事
網絡安全水很深，零碎的也看了不少資料，但是總覺得很飄渺，可能是平時主要是做應用開發，而真正實踐密碼設計（cryptography）和安全設計（security）的機會比較少.
剛剛看了幾篇文章 listed as following，有一些A-Ha moment，也能把我現有的關於web安全的知識竄起來，故記錄在此：
https://gdp.globus.org/gt4-tutorial/multiplehtml/ch09s02.html
https://gdp.globus.org/gt4-tutorial/multiplehtml/ch09s03.html
https://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
參考：https://tools.ietf.org/html/rfc6749
最後更新：2017-04-03 16:48:56