這是一個挺有意思的面試題,挺簡單的,不知道大家平時在重置密碼的時候有沒有想過這個問題。回答這個問題其實就一句話:因為服務端也不知道你的原密碼是什麼。如果知道的話,那就是嚴重的安全風險問題了。
我們這裡來簡單分析一下。
做過開發的應該都知道,服務端在儲存密碼到資料庫的時候,絕對不能直接明文儲存。如果明文儲存的話,風險太大,且不說資料庫的資料有被盜的風險,如果被服務端的相關人員特別是有資料庫許可權的惡意利用,那將是不可預估的風險。
一般情況下,我們都是透過雜湊演算法來加密密碼並儲存。
雜湊演算法也叫雜湊函式或摘要演算法,它的作用是對任意長度的資料生成一個固定長度的唯一標識,也叫雜湊值、雜湊值或訊息摘要(後文統稱為雜湊值)。
雜湊演算法可以簡單分為兩類:
- 加密雜湊演算法:安全性較高的雜湊演算法,它可以提供一定的資料完整性保護和資料防篡改能力,能夠抵禦一定的攻擊手段,安全性相對較高,但效能較差,適用於對安全性要求較高的場景。例如 SHA2、SHA3、SM3、RIPEMD-160、BLAKE2、SipHash 等等。
- 非加密雜湊演算法:安全性相對較低的雜湊演算法,易受到暴力破解、衝突攻擊等攻擊手段的影響,但效能較高,適用於對安全性沒有要求的業務場景。例如 CRC32、MurMurHash3、SipHash 等等。
除了這兩種之外,還有一些特殊的雜湊演算法,例如安全性更高的慢雜湊演算法。
關於雜湊演算法的詳細介紹,可以看我寫的這篇文章:雜湊演算法和加密演算法總結 。
目前,比較常用的是透過 MD5 + Salt 的方式來加密密碼。鹽(Salt)在密碼學中,是指透過在密碼任意固定位置插入特定的字串,讓雜湊後的結果和使用原始密碼的雜湊結果不相符,這種過程稱之為“加鹽”。
不過,這種方式已經不被推薦,因為 MD5 演算法的安全性較低,抗碰撞性差。詳細介紹可以閱讀我寫的這篇文章:簡歷別再寫 MD5 加密密碼了! 。你可以使用安全性較高的加密雜湊演算法+ Salt(鹽)(例如 SHA2、SHA3、SM3,更高的安全性更強的抗碰撞性)或者直接使用慢雜湊(例如 Bcrypt,更推薦這種方式)。
假如我們這裡使用 SHA-256 + Salt 這種方式。
這裡寫了一個簡單的示例程式碼:
String password = "123456";
String salt = "1abd1c";
// 建立SHA-256摘要物件
MessageDigest messageDigest = MessageDigest.getInstance("SHA-256");
messageDigest.update((password + salt).getBytes());
// 計算雜湊值
byte[] result = messageDigest.digest();
// 將雜湊值轉換為十六進位制字串
String hexString = new HexBinaryAdapter().marshal(result);
System.out.println("Original String: " + password);
System.out.println("SHA-256 Hash: " + hexString.toLowerCase());
輸出:
Original String: 123456
SHA-256 Hash: 424026bb6e21ba5cda976caed81d15a3be7b1b2accabb79878758289df98cbec
在這個例子中,服務端儲存的就是密碼“123456”加鹽雜湊之後的資料,也就是“424026bb6e21ba5cda976caed81d15a3be7b1b2accabb79878758289df98cbec” 。
當你輸入密碼登入之後,服務端會先把你的密碼對應的鹽取出,然後再去執行一遍獲取雜湊值的過程。如果最終計算出來的雜湊值和儲存在資料庫中的雜湊值一直,那就說明密碼是正確的。否則的話,密碼就不是正確的。
雜湊演算法的是不可逆的,你無法透過雜湊之後的值再得到原值,這樣的話,服務端也不知道你的原密碼到底是什麼,自然沒辦法告訴你原密碼是什麼。
那有的朋友又有疑問了,為什麼很多網站改密碼不可與原密碼相同呢?這是過程實際和驗證密碼正確性一樣的流程,計算一遍雜湊值比較即可!