密码存储改进

[aplqo]

现有的密码处理是客户端将client_salt作为密钥对密码进行HMACmd5，服务端将用户名和HMAC拼接后计算MD5。但是已知密钥HMAC安全性相当于MD5，而MD5保存密码容易破解。
建议：

• 使用bcrypt或scrypt保存密码
• 在服务端进行哈希值计算，防止直接使用哈希值登录

[Ruanxingzhi]

密码学角度看，现行的方式没有问题。目前浏览器上计算 md5(password || salt) 并发送，但这种情况下（以 2021 年目前的研究来看）仍然是抗原像的。攻击者无法恢复出密码（如果密码是强的）。

从 md5 切换成 sha256 增强了理论上的安全性，但造成旧系统向新系统迁移时的困难。鉴于现行方案在实践上是安全的，我不考虑切换成 sha256，除非业界研究出针对 md5 的多项式时间的原像攻击或第二原像攻击。

至于信道上的窃听者重放登录流量包，以伪装成用户的问题。这是 HTTP 协议的固有缺陷，想要解决重放攻击，要么在 UOJ 系统上打补丁（例如序列号机制、时间戳机制，但它们都不能抵抗中间人攻击，而且会造成服务器这边数据库的不必要负担），要么切换成 https。

鉴于切换成 https 可以解决上述一切问题，我认为 UOJ 没有维护传输安全的必要（事实上我们无论如何努力，都无法防范中间人攻击）。使用 UOJ 的人士应当部署 https 来保证传输安全，借助于 nginx 和免费签发证书的 CA，这是不难做到的。

@billchenchina @TechCiel @MascoSkray 你们的观点呢？

[cebarobot]

目前 UOJ 社区版应该还用的是 Apache2，搞一份在 Apache2 上部署 HTTPS 的文档还是可以考虑的……

不过现在 UOJ 的可维护性其实挺差的，几乎任何更改都会导致旧系统到新系统迁移困难……

[TechCiel]

如果不想重新实现 TLS ，最好还是套上 TLS 。

我来说点现实的，服务器端可以考虑将 HMAC 当作用户密码，对于 MD5 hash 验证正确的，进行 rehash 重新存成 bcrypt 或者 Argon2 等格式，这个渐进式升级的逻辑较易实现。

至于客户端，当前的实现在 TLS 下，似乎唯一重要的问题是提供的信息允许服务器比较不同用户的密码，想避免这一点需要给每个用户一个随机盐，实现感觉会很冗杂。

再现实一点，现在的保护措施加上 TLS 几乎足以阻挡99%常见的攻击，没有很严重的 Eve 问题，不过如果数据库泄露，弱密码会被较快爆破出来，但仍不是多项式的，我觉得并不特别需要担心。

考虑在服务器端加上前述的更新，我觉得是我们现在可以做的事情。

上文是 2 月 1 日在群里的讨论。