“原始密碼(Raw password)”和“散列密碼(hashed password)”是可行的解決方案。但是，HTTPS 下的原始密碼更常用，例如 Google 和 Facebook。以下原因解釋了為什麼原始密碼更可行，因為信息安全應該與業務需求保持一致：
. 在瀏覽器中，散列密碼是通過自定義 JavaScript 模塊計算的；如果客戶關閉 JavaScript 功能或防病毒軟件干擾操作，則無法正常工作。這將對市場份額、客戶滿意度和客戶服務成本產生負面影響。
. 如果攻擊者可以破壞 HTTPS 連接，發送原始密碼或散列密碼沒有任何區別，因為他可以竊取訪問令牌並劫持會話。剩餘風險幾乎相同。
. 此外，發送散列密碼意味著用戶的密碼必須被散列或加鹽，並且變得不可逆轉。但是，有些網站可能需要支持“找回密碼”功能，對密碼進行加密，客戶可以查詢自己忘記的密碼。
鹽密碼(Salted Password)
加鹽密碼是指根據原始密碼和鹽的串聯計算得出的哈希值，鹽是“作為輔助輸入合併到單向或加密函數中的隨機變量，用於派生密碼驗證數據”。(ISO/IEC 11770-4:2017) 加鹽通常在服務器端生成並且對客戶端保密，因此客戶端不可能提交加鹽密碼。
電子簽名(Digital Signature)
數字簽名在技術上是可行的，但對於電子商務網站要求客戶安裝數字證書進行身份驗證來說實際上是不可行的。
參考
. 為什麼客戶端對密碼的散列如此不常見？
. 為什麼幾乎沒有網頁在提交之前在客戶端散列密碼（並在服務器上再次散列它們），以“防止”密碼重用？
. 你（可能）做錯了登錄系統
資料來源： Wentz Wu QOTD-202104018
PS:此文章經過作者同意刊登 並且授權可以翻譯成中文
