先别急着觉得“HTTPS加密了传输就万事大吉”——HTTPS只解决了传输链路的加密问题，但你用明文传递用户名、密码的操作，在多个环节都埋下了安全炸弹：

核心风险点 #

• 两端应用的内存/日志泄露：App A构造请求时，明文密码会存在内存中；如果App A的代码有漏洞（比如不小心把密码打在日志里、或者被恶意程序dump内存），直接就泄露了。同理，App B接收后如果明文处理密码，也可能在日志、临时存储里留下痕迹，被攻击者轻易获取。
• 逆向/钩子攻击：如果App A是移动端应用，攻击者可以用Frida、Xposed这类工具直接hook App的代码逻辑，在明文密码被加密进HTTPS请求前就把它截走——HTTPS管不了应用内部的明文数据。
• 凭证泄露的不可逆性：明文传递意味着一旦泄露，攻击者直接拿到了用户的核心认证信息，可以直接登录其他使用相同密码的平台。如果传递的是加盐哈希后的凭证，就算泄露也没法直接用来登录。
• HTTPS并非绝对无懈可击：如果App的证书配置有问题（比如信任了恶意证书、使用弱加密套件），攻击者可以实施中间人攻击，解密HTTPS流量拿到明文密码——虽然这种情况相对少见，但风险依然存在。

正确的做法 #

• 永远不要明文处理密码：从生成、传输到存储，全程避免明文密码出现。
• 传输时使用哈希凭证或标准协议：
  • 可以先在App A端对密码做加盐哈希（比如用Argon2、bcrypt这类慢哈希算法），再通过HTTPS传递哈希值；
  • 更推荐使用成熟的认证协议，比如OAuth2、OpenID Connect，或者用短期Token代替密码直接传递。
• 强化应用层安全：两端应用要避免在日志中输出敏感信息，处理完密码后立即清除内存中的明文数据，防止内存dump泄露。
• 加固HTTPS配置：使用TLS 1.2+版本，禁用弱加密套件，确保证书链完整且可信，降低MITM攻击的可能性。

内容的提问来源于stack exchange，提问作者pravin