登錄註冊設計1_Https基本原理與web安全基礎

篇幅較長，請耐心讀完，博主將用簡明扼要的語言進行通俗講解

1.密碼學基礎

1.1 爲何需要加密

  不想自己的賬號密碼裸奔在網絡上吧？不想自己的密碼在數據庫泄露時被黑客直接盜用吧？因此太多地方需要加密，加密後的數據還需要使用時就得進行解密。
  常見概念有：
  明文：你懂我懂大家懂，沒有進行加密的數據。
  密文：明文經過加密就是密文（有可能被破解，爲什麼請看1.2）。
  加密算法：對明文進行加密的算法。
  解密算法：對密文進行解密的算法。
  密鑰：分爲公鑰和私鑰。密鑰就是在加密和解密算法中使用的參數。對稱加密中只使用私鑰（爲什麼請看1.3），非對稱加密中使用一對密鑰（即公鑰和私鑰）。
  公鑰：非對稱加密中，任何方（一般來說就是客戶端）都知道的密鑰。
  私鑰：非對稱加密中，只有擁有方（一般來說就是服務器）知道的密鑰
常見加密方法下方闡述。

1.2 單向散列加密的問題

  單向散列加密：加密後不需要解密。常用於數據庫中存儲加密後的用戶密碼。
  常用算法：使用MD5、SHA-512、SHA-256、bcrypt算法進行hash加密（hash算法）。
  問題：因爲單向散列加密是一個明文對應一個密文，比如123456幾個數字排列的密碼對應了各自的密文。黑客只需建立一張表，就可以根據密文反查出用戶明文密碼即可。這樣的表一般叫做彩虹表。當表越來越大，破解的速度就會越快。
  如何解決：一般使用的方法是加鹽，具體請看2.3。

1.3 對稱加密的問題

  對稱加密：加密方、解密方共用一個私鑰。具體流程：明文-私鑰+加密算法—密文—私鑰+解密算法-明文。
  常用算法：DES、3DES、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK、AES。
  問題：因爲對稱加密算法是公開的，加密方、解密方共用一個私鑰，如果私鑰泄露，則通信雙方將變得不再安全，私鑰管理也變得困難。
  如何解決：使用更加安全的非對稱加密。

1.4 非對稱加密的問題

  對稱加密：加密方用公鑰加密，解密方用私鑰解密，公鑰加密的密文只有私鑰能解，私鑰加密的密文只有公鑰能解。具體流程：明文-公鑰+加密算法—密文—私鑰+解密算法-明文。
  常用算法：RSA、ECC（橢圓曲線加密算法）、Diffie-Hellman、El Gamal、DSA（數字簽名用）。
  問題：在實際使用中，一般是服務端將公鑰給客戶端使用，服務端自己保留私鑰，這樣就可以實現服務端、客戶端的相對安全通信。網絡攻擊中有一種攻擊叫中間人攻擊，如果非對稱加密時，黑客冒充了服務器，給了客戶端黑客自己的公鑰，那麼黑客就可以得到客戶端發送的密碼等信息。這裏就出現了兩個問題，一是：客戶端如何知道黑客沒有修改服務端發給自己的信息，造成安全性問題。二是：客戶端如何識別公鑰的正確性問題，也可以說是服務端的有效性（正確的服務端）的問題。
  如何解決：請看1.5。

1.5 數字簽名的問題

  數字簽名：簽名簽名，顧名思義，就是服務端傳給客戶端數據時，給自己的數據帶上一份簽名，就像合同簽名一樣。這裏的簽名，需要使用服務端的私鑰對數據生成一份摘要，傳輸時，帶上這份摘要。首先，客戶端收到數據後，因爲只有公鑰能解開私鑰生成的摘要，所以可以判斷數據來自服務端，1.4的問題2基本解決了，但是並沒有完全解決。其次，用公鑰解開摘要後的數據，和數據本身一致，則可以判斷數據沒有被修改，1.4的問題1也解決了。
  問題：爲什麼叫基本解決了1.4的問題2？因爲實際上你還是沒法判斷服務端到底是不是黑客，它有可能只是一箇中轉站，數據也能傳到真正的服務端，但是經過中轉站時，所有數據已經泄露。
  如何解決：爲了解決服務端的正確性的問題，引入了數字證書，請看1.6。

1.6 什麼是數字證書

  數字證書：因爲無法驗證服務端的有效性問題。所以客戶端要求服務端去公信機構（CA）做認證。CA有自己的私鑰，也有自己的公鑰。服務端做認證時，CA會使用自己的私鑰將服務端的一些信息+服務端的公鑰生成一個數字證書。客戶端保留了很多公信機構的公鑰，這時服務端再把公鑰拿給客戶端時會帶上CA的數字證書，客戶端用CA的公鑰打開數字證書，也就可以拿到服務端的公鑰以及域名等信息。這樣就可以判斷服務端的有效性，以及可以判斷域名和正在訪問的域名是否一致了。
  在什麼地方使用：Https協議就使用了數字證書。而且在瀏覽器客戶端中也保留了許多的CA機構的公鑰。我們在開發Android應用是，也需要設置訪問域名認證的CA機構的公鑰。我們開發服務端時，想要使用Https協議安全傳輸數據，就得花錢申請一個數字證書，然後提供給瀏覽器或者App使用Https協議啦！
  延伸：請看本文第3點Https基本原理。

2.Https基本原理

2.1 什麼是Https

  Https協議 = Http協議 + SSL/TLS協議。Http協議又叫超文本傳輸協議，是一種運行在應用層的網絡協議，是基於傳輸層TCP/IP協議的協議。Https是在Http基礎上加上了SSL或TLS加密協議的安全協議，確保了通信雙方的安全。Http協議採用的是明文傳輸，但是Https則是使用了數字證書的形式去傳輸加密信息。所以，大多數需要信息加密的網站，都是採用的https協議。而一般的政府公開網站，則是採用http協議即可。

2.2 Https的性能問題

  由於Https協議採用了數字證書，但是由於非對稱加密過程複雜，可會造成性能問題，所以Https是由對稱加密和非對稱加密聯合使用的。其過程是：先使用非對稱加密去協商一個僅雙方知道的私鑰，然後再根據協商私鑰去進行對稱加密通信。

2.3 Https具體的流程

協商私鑰流程：

1. 服務器端的公鑰和私鑰，用來進行非對稱加密
2. 客戶端生成的隨機密鑰，用來進行對稱加密

具體流程：

1. 客戶端向服務器發起HTTPS請求，連接到服務器的443端口。
2. 服務端有一對密鑰，即公鑰和私鑰，一般是用錢註冊得來。
3. 服務端將自己的公鑰發送給客戶端。
4. 客戶端根據數字證書驗證服務端合法性，並生成一個隨機密鑰。至此，HTTPS中的第一次HTTP請求結束。
5. 客戶端會發起HTTPS中的第二個HTTP請求，用服務端公鑰對隨機密鑰進行加密後發送給服務端。
6. 服務器接收到客戶端發來的密文之後，會用自己的私鑰對其進行非對稱解密，解密之後的明文就是客戶端密鑰，然後用客戶端隨機密鑰對數據進行對稱加密，這樣數據就變成了密文。
7. 然後服務器將加密後的密文發送給客戶端。
8. 客戶端收到服務器發送來的密文，用客戶端隨機密鑰對其進行對稱解密，得到服務器發送的數據。這樣HTTPS中的第二個HTTP請求結束，整個HTTPS傳輸完成。

2.4 Https在瀏覽器和Android客戶端中的使用

推薦參考文章

3.web安全基礎

3.1 web安全導致的事故

  2011年12月，國內最大的程序員社區遭拖庫，600萬個賬戶信息泄露。
  2014年3月，攜程旅行網的系統存技術漏洞，漏洞可能導致用戶的姓名、身份證號碼、銀行卡類別、銀行卡卡號、銀行卡CVV碼以及銀行卡6位Bin泄露。
  2014年5月，小米論壇涉及800萬用戶信息遭泄露，信息包括用戶名、密碼、註冊IP、郵箱等。
  2014年12月，12306遭撞庫攻擊，13萬用戶信息泄露，包括用戶賬號、明文密碼、身份證、郵箱等敏感信息。
  2015年10月，網易郵箱遭攻擊，近5億條用戶信息被泄露，包括用戶名、密碼、密碼保護信息、登陸IP以及用戶生日等多個原始信息。
  不可思議吧？這麼多大公司大網站的系統都遭到攻擊，泄露用戶信息，更別說其他小網站了。這些攻擊都可以從技術上來進行防範的，但是我們看到即使是大公司，安全方面也是那麼的薄弱。

3.2 web安全存在的問題

  從用戶敲出的第一個字符開始，我們就需要對數據使用正確的姿勢去操作。
  正確的姿勢有：
  1. 用正確的姿勢保存密碼。
  2. 用正確的姿勢傳輸數據。
  3. 用正確的姿勢加密敏感信息。
  4. 用正確的姿勢對數據進行備份和監控。

3.3 保存密碼

  保存密碼原理：使用單向散列加密，但是光是單向散列加密是不行的，我們得加點鹽（salt）。加鹽的好處是可以讓密碼長度更長，加密後強度更強。黑客進行逆推或者撞庫（猜）的難度更大。一般來說進行兩次加鹽MD5就行了，如：md5(md5(pwd) + salt)。
  問題：我們在單向散列加密中說到了彩虹表的問題。直接使用MD5的hash算法加密，可能會被暴力破解。
  解決：所以我們需要使用加鹽的方法使我們數據庫中加密後的密碼更加難以被破解。最關鍵的是 salt 從哪裏來？ salt 該怎麼設置才能安全。

1. 不要使用固定不變的 salt。
2. 每個用戶的 salt 都需要不同。
3. salt 要保持一定的長度。
4. salt 必須由服務端使用安全的隨機函數生成。
5. 客戶端運算需要的 salt 需要從服務端動態獲取。
6. 客戶端加鹽 hash 的結果並不是最終服務端存盤的結果

3.4 傳輸數據

  傳輸數據我們在數字證書那裏已經講到了，並且Https也是一種可靠的傳輸數據的手段，你也可以使用其他方式替代Https，但是中間人攻擊就沒多大辦法，當然，這裏的中間人攻擊得到的也是不能夠破解的數據。

3.5 加密敏感信息

  用戶的密碼不能明文保存，而且要使用不可逆的加密算法，只保存最終的 hash 結果用來驗證是否正確。那用戶其他的敏感信息呢？比如身份證、銀行卡、信用卡等信息，該如何加密保存而不被泄露呢？
  對於身份證信息，可以像密碼一樣只保存 hash 的結果，可以用於用戶輸入身份證號後進行驗證。假如需要給用戶顯示身份證信息，只需要保存抹掉了幾位數字的身份證號。
  假如你的系統涉及到支付，需要用戶的銀行卡，信用卡（卡號，CVV碼）等信息時，必須遵循 PCI DSS （第三方支付行業數據安全標準）標準。
  如果只是銀行卡，還需要遵循 ADSS （銀聯卡收單機構賬戶信息安全管理標準） 標準。

3.6 對數據進行備份和監控

  主要措施有：磁盤 raid，物理備份（磁帶庫），異地的邏輯備份。同時做好權限控制，並對訪問記錄做好監控，及時發現問題，保留現場證據。

參考文章：
https://www.wosign.com/News/news_2018101101.htm
https://blog.csdn.net/iispring/article/details/51615631
http://www.easemob.com/news/3706
https://blog.coderzh.com/2016/01/03/security-design/
https://blog.coderzh.com/2016/01/10/a-password-security-design-example/
https://blog.coderzh.com/2016/01/13/password-security-additional/