| 方案 | 致命缺陷 |
|---|
| 前端 RSA 加密（公鑰加密，後端私鑰解密） | 公鑰傳輸過程可被劫持替換（MITM），攻擊者替換公鑰後可解密密文；無法防禦重放攻擊；需防範 Bleichenbacher 攻擊（PKCS#1 v1.5）。 |
| 前端 AES 對稱加密（密鑰嵌入 JS/從後端獲取） | 密鑰在客戶端明文可見，攻擊者輕易獲取；等同於明文傳輸。 |
| 前端哈希（MD5/SHA256）再傳輸 | 哈希值即成為「等效密碼」，資料庫洩露後可直接用哈希值登錄（Pass-the-Hash）；無法防禦重放；彩虹表/撞庫風險極高。 |
| 挑戰-響應（Nonce/時間戳） | 需 HTTPS 保護挑戰值傳輸，否則中間人可攔截並構造響應；實現複雜，易出漏洞。 |
| SRP (Secure Remote Password) 協議 | 理論安全，但實現極複雜，前端 JS 庫審計困難，且**仍需 HTTPS 防止腳本注入/降級攻擊**。 |
HTTPS 如何保護密碼傳輸？
- 加密傳輸層：TLS 記錄協議對 HTTP 消息體（含密碼）加密，中間人只見密文。
- 服務器身份驗證：CA 簽發證書，瀏覽器驗證域名所有權，防止偽造服務器（釣魚/中間人）。
- 完整性校驗：防止數據被竄改（如注入惡意腳本竊取密碼）。
- 前向保密：現代密碼套件（ECDHE）確保長期私鑰洩露不影響歷史會話。
正確的登錄安全實踐清單
1. 傳輸層：強制 HTTPS
- 全站 HTTPS（含靜態資源），HSTS 頭預載。
- 證書使用 ECC (ECDSA P-256) 或 RSA 2048+，TLS 1.2/1.3，禁用弱套件。
- 設置 `Secure`、`HttpOnly`、`SameSite=Strict/Lax` Cookie 屬性。
2. 應用層：密碼存儲與驗證
- 絕不存明文/可逆加密/單次哈希。
- 使用 **Argon2id**（首選）、**bcrypt**、**scrypt** 或 **PBKDF2** 進行**鹽值哈希**，成本因子適配硬件（如 Argon2id t=3, m=64MB, p=4）。
- 登錄時：前端 HTTPS POST 明文密碼 → 後端驗證哈希 → 簽發 JWT/Session。
3. 前端：負責任的交互
- 輸入框 `type="password"`、`autocomplete="current-password"`。
- 提交按鈕防抖，防止重複請求。
- CSP 頭限制腳本來源，防 XSS 竊取輸入框內容。
4. 進階防護
- 多因子認證（MFA/2FA）：TOTP、WebAuthn/FIDO2、簡訊碼（次選）。
- 頻率限制：IP/用戶/設備維度限制登錄嘗試，防暴力破解。
- 異常登錄檢測：新設備/地理位置/時間觸發二次驗證/通知。
- 密碼強度策略：NIST 800-63B 建議（最小 8 字符、拒絕常見弱密碼、無複雜度強制）。
常見誤區回應
「CSDN 登錄也是 HTTPS，你能抓包獲得密碼嗎？」
**不能。** 抓包只能看到 TLS 加密後的二進制流。除非安裝了受信任的根證書（企業中間人設備）並導入瀏覽器，否則無法解密。這正是 HTTPS 的設計目標：不信任網絡，只信任端點身份與加密通道。
「但我必須在 HTTP 環境下部署，無法上 HTTPS。」
**沒有「必須」。** 免費證書（Let's Encrypt、ZeroSSL）、自動化工具、CDN/負載均衡器終止 TLS、內網自簽 CA + 客戶端信任，成本極低。若真受限於極端環境（如嵌入式設備無存儲證書空間），才考慮 SRP/PAKE 協議，且必須接受較高實現風險。
總結
Web 密碼傳輸安全的**唯一標準答案是 HTTPS**。客戶端加密方案在無 HTTPS 時均不安全，有 HTTPS 時則多餘且有害。工程師應將精力投入於：全站 HTTPS 部署、強哈希存儲、MFA、頻率限制、CSP/HSTS 安全頭，而非研究如何在 JS 中「加密密碼」。
- 上一篇文章： MFC 編寫網頁瀏覽器：CHtmlView 點擊鏈接跳轉到外部瀏覽器的解決方法
- 下一篇文章： Java 對象創建與引用變量聲明的區別：new、聲明、初始化的內存模型圖解
Copyright ©
程式碼之家 All Rights Reserved
