這是一個挺有意思的面試題，挺簡單的，不知道大家平時在重置密碼的時候有沒有想過這個問題。回答這個問題其實就一句話：因爲服務端也不知道你的原密碼是什麼。如果知道的話，那就是嚴重的安全風險問題了。
我們這裏來簡單分析一下。
做過開發的應該都知道，服務端在保存密碼到數據庫的時候，絕對不能直接明文存儲。如果明文存儲的話，風險太大，且不說數據庫的數據有被盜的風險，如果被服務端的相關人員特別是有數據庫權限的惡意利用，那將是不可預估的風險。
一般情況下，我們都是通過哈希算法來加密密碼並保存。
哈希算法也叫散列函數或摘要算法，它的作用是對任意長度的數據生成一個固定長度的唯一標識，也叫哈希值、散列值或消息摘要（後文統稱爲哈希值）。
哈希算法可以簡單分爲兩類：
- 加密哈希算法：安全性較高的哈希算法，它可以提供一定的數據完整性保護和數據防篡改能力，能夠抵禦一定的攻擊手段，安全性相對較高，但性能較差，適用於對安全性要求較高的場景。例如 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” 。
當你輸入密碼登錄之後，服務端會先把你的密碼對應的鹽取出，然後再去執行一遍獲取哈希值的過程。如果最終計算出來的哈希值和保存在數據庫中的哈希值一直，那就說明密碼是正確的。否則的話，密碼就不是正確的。
哈希算法的是不可逆的，你無法通過哈希之後的值再得到原值，這樣的話，服務端也不知道你的原密碼到底是什麼，自然沒辦法告訴你原密碼是什麼。
那有的朋友又有疑問了，爲什麼很多網站改密碼不可與原密碼相同呢？這是過程實際和驗證密碼正確性一樣的流程，計算一遍哈希值比較即可！
