程序員必備基礎：如何安全傳輸存儲用戶密碼？

前言

咱們開發網站或者APP的時候，首先要解決的問題，就是「如何安全傳輸和存儲用戶的密碼」。一些大公司的用戶數據庫泄露事件也時有發生，帶來很是大的負面影響。所以，如何安全傳輸存儲用戶密碼，是每位程序員必備的基礎。本文將跟你們一塊兒學習，如何安全傳輸存儲用戶的密碼。前端

1. 如何安全地傳輸用戶的密碼

要拒絕用戶密碼在網絡上裸奔，咱們很容易就想到使用https協議，那先來回顧下https相關知識吧~git

1.1 https 協議

「http的三大風險」

爲何要使用https協議呢？「http它不香」嗎? 由於http是明文信息傳輸的。若是在茫茫的網絡海洋，使用http協議，有如下三大風險：程序員

❝

竊聽/嗅探風險：第三方能夠截獲通訊數據。

數據篡改風險：第三方獲取到通訊數據後，會進行惡意修改。

身份僞造風險：第三方能夠冒充他人身份參與通訊。

❞

若是傳輸不重要的信息還好，可是傳輸用戶密碼這些敏感信息，那可不得了。因此通常都要使用「https協議」傳輸用戶密碼信息。github

「https 原理」

https原理是什麼呢？爲何它能解決http的三大風險呢？web

❝
https = http + SSL/TLS, SSL/TLS 是傳輸層加密協議，它提供內容加密、身份認證、數據完整性校驗，以解決數據傳輸的安全性問題。算法
❞

爲了加深https原理的理解，咱們一塊兒複習一下「一次完整https的請求流程」吧~數據庫

❝

客戶端發起https請求

服務器必需要有一套數字證書，能夠本身製做，也能夠向權威機構申請。這套證書其實就是一對公私鑰。

服務器將本身的數字證書（含有公鑰、證書的頒發機構等）發送給客戶端。

客戶端收到服務器端的數字證書以後，會對其進行驗證，主要驗證公鑰是否有效，好比頒發機構，過時時間等等。若是不經過，則彈出警告框。若是證書沒問題，則生成一個密鑰（對稱加密算法的密鑰，實際上是一個隨機值），而且用證書的公鑰對這個隨機值加密。

客戶端會發起https中的第二個請求，將加密以後的客戶端密鑰(隨機值)發送給服務器。

服務器接收到客戶端發來的密鑰以後，會用本身的私鑰對其進行非對稱解密，解密以後獲得客戶端密鑰，而後用客戶端密鑰對返回數據進行對稱加密，這樣數據就變成了密文。

服務器將加密後的密文返回給客戶端。

客戶端收到服務器發返回的密文，用本身的密鑰（客戶端密鑰）對其進行對稱解密，獲得服務器返回的數據。

❞

「https必定安全嗎？」

https的數據傳輸過程，數據都是密文的，那麼，使用了https協議傳輸密碼信息，必定是安全的嗎？其實「否則」~編程

❝

好比，https 徹底就是創建在證書可信的基礎上的呢。可是若是遇到中間人僞造證書，一旦客戶端經過驗證，安全性頓時就沒了哦！平時各類釣魚不可描述的網站，極可能就是黑客在誘導用戶安裝它們的僞造證書！

經過僞造證書，https也是可能被抓包的哦。

❞

1.2 對稱加密算法

既然使用了https協議傳輸用戶密碼，仍是「不必定安全」，那麼，咱們就給用戶密碼「加密再傳輸」唄~緩存

加密算法有「對稱加密」和「非對稱加密」兩大類。用哪一種類型的加密算法「靠譜」呢？安全

❝
對稱加密：加密和解密使用「相同密鑰」的加密算法。
❞

經常使用的對稱加密算法主要有如下幾種哈：

若是使用對稱加密算法，須要考慮「密鑰如何給到對方」，若是密鑰仍是網絡傳輸給對方，傳輸過程，被中間人拿到的話，也是有風險的哦。

1.3 非對稱加密算法

再考慮一下非對稱加密算法呢？

❝
「非對稱加密：」 非對稱加密算法須要兩個密鑰（公開密鑰和私有密鑰）。公鑰與私鑰是成對存在的，若是用公鑰對數據進行加密，只有對應的私鑰才能解密。
❞

經常使用的非對稱加密算法主要有如下幾種哈：

❝
若是使用非對稱加密算法，也須要考慮「密鑰公鑰如何給到對方」，若是公鑰仍是網絡傳輸給對方，傳輸過程，被中間人拿到的話，會有什麼問題呢？「他們是否是能夠僞造公鑰，把僞造的公鑰給客戶端，而後，用本身的私鑰等公鑰加密的數據過來？」 你們能夠思考下這個問題哈~
❞

咱們直接「登陸一下百度」，抓下接口請求，驗證一發大廠是怎麼加密的。能夠發現有獲取公鑰接口，以下:

再看下登陸接口，發現就是RSA算法，RSA就是「非對稱加密算法」。其實百度前端是用了JavaScript庫「jsencrypt」，在github的star還挺多的。

所以，咱們能夠用「https + 非對稱加密算法（如RSA）」 傳輸用戶密碼~

2. 如何安全地存儲你的密碼？

假設密碼已經安全到達服務端啦，那麼，如何存儲用戶的密碼呢？必定不能明文存儲密碼到數據庫哦！能夠用「哈希摘要算法加密密碼」，再保存到數據庫。

❝
哈希摘要算法：只能從明文生成一個對應的哈希值，不能反過來根據哈希值獲得對應的明文。
❞

2.1 MD5摘要算法保護你的密碼

MD5 是一種很是經典的哈希摘要算法，被普遍應用於數據完整性校驗、數據（消息）摘要、數據加密等。可是僅僅使用 MD5 對密碼進行摘要，並不安全。咱們看個例子，以下：

public class MD5Test {
    public static void main(String[] args) {
        String password = "abc123456";
        System.out.println(DigestUtils.md5Hex(password));
    }
}

運行結果：

0659c7992e268962384eb17fafe88364

在MD5免費破解網站一輸入，立刻就能夠看到原密碼了。。。

試想一下，若是黑客構建一個超大的數據庫，把全部20位數字之內的數字和字母組合的密碼所有計算MD5哈希值出來，而且把密碼和它們對應的哈希值存到裏面去（這就是「彩虹表」）。在破解密碼的時候，只須要查一下這個彩虹表就完事了。因此「單單MD5對密碼取哈希值存儲」，已經不安全啦~

2.2 MD5+鹽摘要算法保護用戶的密碼

那麼，爲何不試一下MD5+鹽呢？什麼是「加鹽」？

❝
在密碼學中，是指經過在密碼任意固定位置插入特定的字符串，讓散列後的結果和使用原始密碼的散列結果不相符，這種過程稱之爲「加鹽」。
❞

用戶密碼+鹽以後，進行哈希散列，再保存到數據庫。這樣能夠有效應對彩虹表破解法。可是呢，使用加鹽，須要注意一下幾點：

❝

不能在代碼中寫死鹽，且鹽須要有必定的長度（鹽寫死太簡單的話，黑客可能註冊幾個帳號反推出來）

每個密碼都有獨立的鹽，而且鹽要長一點，好比超過 20 位。(鹽過短，加上原始密碼過短，容易破解)

最好是隨機的值，而且是全球惟一的，意味着全球不可能有現成的彩虹表給你用。

❞

2.3 提高密碼存儲安全的利器登場，Bcrypt

即便是加了鹽，密碼仍有可能被暴力破解。所以，咱們能夠採起更「慢一點」的算法，讓黑客破解密碼付出更大的代價，甚至迫使他們放棄。提高密碼存儲安全的利器~Bcrypt，能夠閃亮登場啦。

❝
實際上，Spring Security 已經廢棄了 MessageDigestPasswordEncoder，推薦使用BCryptPasswordEncoder，也就是BCrypt來進行密碼哈希。BCrypt 生而爲保存密碼設計的算法，相比 MD5 要慢不少。
❞

看個例子對比一下吧：

public class BCryptTest {

    public static void main(String[] args) {
        String password = "123456";
        long md5Begin = System.currentTimeMillis();
        DigestUtils.md5Hex(password);
        long md5End = System.currentTimeMillis();
        System.out.println("md5 time:"+(md5End - md5Begin));
        long bcrytBegin = System.currentTimeMillis();
        BCrypt.hashpw(password, BCrypt.gensalt(10));
        long bcrytEnd = System.currentTimeMillis();
        System.out.println("bcrypt Time:" + (bcrytEnd- bcrytBegin));
    }
}

運行結果：

md5 time:47
bcrypt Time:1597

粗略對比發現，BCrypt比MD5慢幾十倍，黑客想暴力破解的話，就須要花費幾十倍的代價。所以通常狀況，建議使用Bcrypt來存儲用戶的密碼

3. 總結

所以，通常使用https 協議 + 非對稱加密算法（如RSA）來傳輸用戶密碼，爲了更加安全，能夠在前端構造一下隨機因子哦。
使用BCrypt + 鹽存儲用戶密碼。
在感知到暴力破解危害的時候， 「開啓短信驗證、圖形驗證碼、帳號暫時鎖定」等防護機制來抵禦暴力破解。

Reference

[1]

如何正確保存和傳輸敏感數據？: https://time.geekbang.org/column/article/239150

[2]

如何加密傳輸和存儲用戶密碼: https://juejin.cn/post/6844903604944371726#heading-8