為什麼連網站管理員都不知道你的密碼？一次搞懂雜湊 (Hash)、加密 (Encryption) 與加鹽 (Salt)

你一定有過這種經驗：太久沒登入某個網站，忘記了密碼。於是你點了「忘記密碼」按鈕，期待網站把你的舊密碼寄給你。

但奇怪的是，網站通常只會寄給你一個「重設密碼」的連結，要你設定一組新的，卻死都不肯告訴你原本的舊密碼是什麼。

你可能會想：「是不是管理員太懶了？明明資料庫就在他們手上，幫我查一下有這麼難嗎？」

事實上，這不是懶惰，而是安全。在一個設計良好的系統中，連網站的開發者、資料庫管理員（DBA），甚至是老闆本人，都不應該知道你的密碼是什麼。

如果有一個網站能把你的「舊密碼」寄回給你，請立刻做兩件事： 1. 刪除帳號。 2. 逃跑。因為這個網站的資安防護等於零。

為什麼？這要從如何「儲存秘密」說起。

最笨的方法：存「明碼」 (Plaintext) 想像一下，如果網站的資料庫像是一個 Excel 表格，直接寫著： User: Justin Password: 123456 這叫做明碼儲存。這非常危險，因為只要駭客攻破了資料庫，或是公司出了內鬼，所有人的密碼就會瞬間看光光。這在現代資安標準中是絕對禁止的。

很多人搞錯的觀念：加密 (Encryption) 為了不存明碼，很多人會想到：「那我們把密碼加密不就好了？」 加密就像是把文件放進保險箱並鎖上。 你有鑰匙（解密金鑰），就可以把文件鎖進去（加密）。 需要看文件時，用鑰匙打開保險箱（解密），就能看到原始內容。

這看起來很安全，但有一個邏輯漏洞：鑰匙在誰手上？ 如果網站使用「加密」來存密碼，代表伺服器裡一定藏著那把「解密金鑰」。只要管理員擁有這把鑰匙，或者駭客偷到了鑰匙，他們依然可以把所有人的密碼還原出來。 所以，存密碼不能用加密，要用雜湊。 真正的解法：雜湊 (Hash) —— 單向的果汁機 雜湊 (Hashing) 跟加密最大的不同在於：它是單向的。 想像你把一顆草莓丟進果汁機打成汁： 草莓（密碼） -> 果汁機（雜湊函式） -> 草莓汁（雜湊值/亂碼） 你可以輕易把草莓打成汁，但你絕對無法把「草莓汁」還原成一顆「草莓」。這就是雜湊的特性：不可逆。 當你設定密碼 123456 時，網站會把 123456 丟進果汁機，變成一串像 e10adc39... 的亂碼存進資料庫。網站只存這杯果汁，不存草莓。 那你下次登入時，網站怎麼知道密碼對不對？ 很簡單，網站把你輸入的密碼再丟進果汁機打一次，然後比較 「這杯新果汁」跟資料庫裡的「舊果汁」 長得有沒有一樣。如果一樣，代表你輸入的原始密碼是正確的。 這就是為什麼管理員無法告訴你舊密碼——因為他手上只有果汁，他也不知道原本的水果長怎樣。

駭客的逆襲：彩虹表 (Rainbow Table) 雖然雜湊不可還原，但駭客也不是省油的燈。 如果你的密碼很簡單，像是 password 或 123456。駭客可以在家裡先準備好一份清單（彩虹表），把所有常見密碼都先打成「果汁」。 123456 -> e10adc... password -> 5f4dcc... 當駭客偷到資料庫，看到你的密碼是 e10adc...，他只要查表對照一下，馬上就知道你的密碼是 123456 了。 最後的防線：加鹽 (Salt) 為了對付彩虹表，工程師發明了 「加鹽 (Salting)」。 原理很簡單：在把你的密碼丟進果汁機之前，先隨機撒一把鹽（隨機字串）。 原本：Hash(123456) -> 被破解 加鹽：Hash(123456 + "Xk9#m2") -> 產生出完全不同的亂碼 每個使用者的「鹽」都是隨機且不同的。這意味著，就算我和你都使用 123456 當密碼，因為我們加的鹽不同，資料庫裡存的亂碼也會完全不同。駭客的彩虹表就徹底失效了，因為他不可能預先算出所有「密碼 + 隨機鹽」的組合。

給開發者的建議

如果你正在寫一個登入系統： 千萬不要自己發明加密算法。 不要只用簡單的 MD5 或 SHA-1（這些已經被證明不夠安全）。 請使用現代標準的雜湊演算法，如 Bcrypt、Argon2。這些演算法內建了加鹽機制，而且運算速度故意設計得很慢，可以有效防止駭客暴力破解。 現在你知道了，下次點擊「忘記密碼」時，如果收到的是重設連結而不是舊密碼，請感到安心，因為這代表那個網站的工程師有好好保護你的資料！