https://blog.csdn.net/iechenyb/article/details/78249791

1   伺服器端不要儲存密碼明文，因為攻擊者甚至不需要很高深的技術，利用SQL注入就可以獲取所有的明文密碼，後果嚴重。

    如 sql注入問題 :

   select * from user_table where userid='x' and password='1111';--正常的sql

   注入sql

   select * from user_table where userid='x' or (1=1) --'   and password='1111'  ; 輸入引數userid= x ' or (1=1)--   x為任意值。

   最終sql變成

   select * from user_table where userid='x' or (1=1),後邊內容全部作被註釋掉了，因此可以獲取所有使用者的資訊。

2   伺服器端也不能儲存密碼的雜湊值，按理說雜湊值是單向的，不可能被逆向，只能要麼字典要麼暴力破解，但是時間上很難接受(比如需要幾天甚至幾年，取決於密碼的複雜程度和計算機運算能力)，但是這世界上竟然有查表(彩虹表)攻擊，也就是說攻擊者可以先行建立一張"所有"明文密碼到雜湊值的對應表，這樣拿到一個雜湊值幾秒鐘就能獲取其對應的明文密碼。假設網站有10萬註冊使用者，並且其中10%的使用者密碼很簡單，那攻擊者通過簡單的查表也許幾個小時就能獲得這1萬用戶的明文密碼。

    常用的非對稱加密演算法有hash，md5加密等。 hash後儲存是相對安全，但是不是絕對安全，見第3條。

3  伺服器端的密碼應該儲存"加鹽"(salting password)後的雜湊值，所謂加鹽是指在密碼前加一串隨機字串，注意不能用固定的字串加鹽，因為假如鹽固定，那攻擊者還是能事先建立起彩虹表，那就回到了上面的規則2，所以應該每個使用者用不同的隨機鹽。
4  客戶端儲存密碼(因為有自動登入的要求)的規則同伺服器儲存規則。

  拿到使用者的cookie可以自動登入了，因為cookie可以包含使用者登入的所有資訊。

5  客戶端不能傳送明文密碼到伺服器作登入校驗，在使用者和伺服器之間有太多惡意裝置的可能(嗅探，代理,AP，路由器...)，有的客戶端甚至用GET傳遞明文密碼，那普通的代理log就把使用者密碼給洩露了。
6 客戶端也不能傳送密碼雜湊值到伺服器，一個原因是規則2的彩虹表，另一個原因是對於你個人，黑客甚至不需要破解到明文密碼，複用這個雜湊值就可以登入某人賬戶了。

 採用https協議進行密碼傳輸，可以防止傳輸時密碼被截獲。

7  客戶端也不能把加鹽的雜湊值傳到伺服器，雖然這麼做可以避免彩虹表攻擊，但是由於該雜湊值是固定的，黑客還是能複用該值做登入用。
8  作為登入校驗的值必須是不固定的，由於密碼和鹽是固定的，所以必須加入個隨機值一起做雜湊。客戶端可以預先從伺服器處獲取個隨機值(比如時間戳)，然後和加了鹽的密碼雜湊再雜湊一次。這樣就算是中間人(MITM)攻擊也無效。

 hash（時間戳+hash（密碼+鹽）） 時間戳不傳輸，但是需要在伺服器端儲存相同的時間戳。

9  假如客戶端是js網頁，規則6就尤其重要，因為黑客可以通過修改js網頁(惡意http代理)，使密碼作雜湊值的程式碼失效，後者直接就能拿到明文密碼。
10 由於登入時伺服器和使用者共享個第三方無法知道的祕密(密碼)，因此簡單的設計就能保證很高的安全性。難點在於註冊階段，因為要保證使用者設定的密碼(包括雜湊值，包括加鹽雜湊值)不在網路上傳輸到伺服器，這隻能通過https或者簡訊註冊來保證安全了，當然這2個方法本質上還是"伺服器和使用者共享個第三方無法知道的祕密"，前者通過非對稱加密的公鑰私鑰作祕密，後者通過網路黑客無法截獲(手機沒中病毒)的動態密碼作祕密。

11 總結

  即使使用者能夠拿到has(鹽+密碼)或者has(密碼+鹽)的明文，則因為鹽是隨機的，所以黑客在暴力破解或者字典破解的時候，則無法通過彩虹表或者字典表找到對應的密碼明文或者耗費超長時間才能獲取明文（因為鹽是隨機的，所以可能性很小）。

參考博文：http://blog.csdn.net/azhegps/article/details/70851649
--------------------- 
作者：iechenyb_ 
來源：CSDN 
原文：https://blog.csdn.net/iechenyb/article/details/78249791 
版權宣告：本文為博主原創文章，轉載請附上博文連結！