最近在 V2EX 上看到有关 密码是否有必要加密传输 的讨论，因此趁此机会学习一下，下面整理一下相关知识点。
Https 原理
参考文章：
- HTTPS原理通俗理解
- 浏览器如何验证HTTPS证书的合法性？ - (注：对证书的加签和验签讲的比较清楚)
这里额外补充一下，签发证书 时进行的加密操作用的是
CA提供的私钥，而 校验证书 时进行的解密操作则是用的CA提供的公钥，这就是Https保证数据安全的方式：非对称加密
Https 中证书验证是根据一套证书信任链来完成的，如下：
其中根证书是内置在用户的操作系统和浏览器中的，关于根证书的介绍见：根证书 - 维基百科
中间人攻击和密码加密
概念见 中间人攻击 - 维基百科：
中间人攻击（英语：Man-in-the-middle attack，缩写：MITM）在密码学和计算机安全领域中是指攻击者与通讯的两端分别建立独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制[1]。在中间人攻击中，攻击者可以拦截通讯双方的通话并插入新的内容。在许多情况下这是很简单的（例如，在一个未加密的Wi-Fi 无线接入点的接受范围内的中间人攻击者，可以将自己作为一个中间人插入这个网络）。
上面提到的 Https 防范的一个问题就是中间人攻击
另外，在论坛中看到有人讨论：使用Https的情况下，密码前端加密是不是脱裤子放屁
关于这个问题的详细调查见这篇帖子：網站前端打 API 時把密碼加密，有意義嗎？
我将我了解到的信息汇总一下：
- 假设
Https是不安全的，攻击者有办法拿到Request内容。有以下四种情况：①. 攻击者可以掌控整台电脑；②. 攻击者成功执行了中间人攻击；③. 攻击者在网络层监听Request并使用漏洞获取到了请求明文信息；④. 攻击者直接针对Https Server发起攻击。这些情况下，请求信息是可以被攻击者截取的，密码在客户端进行加密之后再传输相对来说更安全，但是这里的更安全指的是 攻击者根据加密后的密码获取到明文密码的成本会更高（比如通过md5加密，那么只能通过彩虹表暴力破解）。 - 假设
Https是安全的。这种情况下攻击者是无法拿到请求内容的，因此密码是否加密的意义确实不大。但是系统一般都会有日志输出，比如记录每次请求传入的参数，在发生错误时将堆栈信息和请求信息打印出来，这时就会出现 密码暴露在日志中的风险。因此，这种情况下，密码加密的意义就是可以 避免密码明文出现在日志中这种意外情况。
这篇文章最后的总结说的很好：網站前端打 API 時把密碼加密，有意義嗎？
- 在客户端对密码进行加密确实可以提高安全性，反映在下面几个方面：①.
Https如果被攻破了，那么攻击者无法知道明文；②.Server端(数据库)，没有任何人知道使用者的明文密码；③. 明文密码不会出现在日志中 - 大部分大公司的网站，密码并没有进行加密传输，使用的是明文，但还是有很多公司做了加密传输的。
- 密码加密传输确实可以提供安全性，但是实际上执行时还需要考虑其他因素，比如成本。如果加密传输真的比较安全，那么为什么还有那么多大公司不去做呢？可能是因为如下几个原因：①.
Https被攻破的可能性太低了②. 加密传输后会增加代码复杂度，加密之后还涉及到解密操作，这会消耗更多的资源
最后贴上这篇帖子的观点：
很多人在討論這個問題的時候，沒有辦法把「單一問題」跟「最佳實踐」切開來看，總是在討論著「以成本來說，怎樣怎樣才是最好的」或是「為什麼不乾脆怎樣怎樣」，但技術選型從來都不是一刀切的事情，最好的方案通常成本也較高，如果真的沒有這麼多的資源怎麼辦？是不是就需要選擇次好且成本較低的方案？
不是只有最佳實踐才叫做實踐，技術是需要進行妥協的。
舉個例子，把登入驗證機制都換成 Passkeys，成本可能是 50，增加的安全性是 90。
把原本明文傳輸的密碼先 hash，成本可能是 20，增加的安全性是 5。
儘管 Passkeys 的效益整體來說更高，但問題是有些公司可能現在就只有 20 個單位的資源。
我自己認為一位優秀的工程師不能只給得出最佳實踐，而是必須針對有限資源的狀況之下，給出各種不同的解法，因此這篇討論的問題不是毫無意義的。把這個問題整理過一輪之後，自然而然就會出現許多成本不同，效益也不同的解法。
有多少資源，就做多少事。不過話說回來，了解最佳實踐是什麼還是滿重要的，這樣你才能知道該做多少取捨。
上面的帖子中提到一个密码加密的方案：**2FA - 双因素认证**，比如 Github 登录用的就是这个方式，关于 2FA 的概念见：什么是 2FA（双因素身份验证） - IBM
2FA（双因素身份验证）是一种身份验证方法，用户必须提供两个证据，如密码和一次性通行码，才能证明自己的身份并访问在线帐户或其他敏感资源。