请教一下关于 password_hash 的密码安全问题

[muziyue]

由于 password_hash 只能用 php 验证，那客户端提交是不是用要配合 https 才行
如果没 https 的情况下， js 本地加密一下再 post 给 php 验证这样安全么？没用过这种加密，是不是应该这样用

[owt5008137]

现在两层的 md5 和 sha1 都比较容易被撞库

[jasontse]

「 js 本地加密一下再 post 给 php 」这样除了增加前端的复杂度修改了最终提交的密码有什么不一样吗

[lslqtz]

不安全， http 情况下可以修改源文。

[muziyue]

@jasontse 不然呢？ post 明文？

@lslqtz 就是说能上 https 还是上呗

[jasontse]

@muziyue 那我直接抓取你的密文当作密码用行不行呢

[lc4t]

没有 https 那么传输过程都不可信，谁都能看。 md5/sha1 也不安全了，建议前端 bcrypt 然后 https 。

[dangyuluo]

@jasontse 我觉得可以 https+js 加密密码的时候考虑进去时间戳

[lslqtz]

@muziyue 嗯 这样没有啥作用，需要劫持的可以直接把你的 js 改成先明文发送其他机子，再用你自己的 js 加密发送到你服务器。

[lslqtz]

吃力不讨好，该改还是改，还占资源。。要安全还是上 https 。

[iyaozhen]

如果 js 只是单纯的加密密码是没用的，黑客也不用知道你原始密码，知道你加密后的密码就行，传给服务端服务端自己会解密成原始密码。 js 加密要和服务端结合才行，做到一次一密。先从服务端拿个动态 token(初始向量)然后再加密传输到服务端，这样那种一般的抓包就不行了，必须要拿到你的 js 来解密。

当然一切前端的东西都是不可信的，不过也能提高黑客的成本，能上 https 还是上 https 吧。

还有楼上有些同学可能对 PHP 不了解， PHP 的 password_hash 函数就是专门搞这个事情的，把密码 hash ，还可以自己加 salt ，还能保证不同密码长度完成加密时间一样。非常可靠和安全。如果后端是 PHP 的话就不要自己造轮子了。

[qqmishi]

建议上 https 。
只前端加密的话，唯一的用处是中间人不能直接看到明文密码，但拦不住重放攻击，直接再发一遍这个包就破了。
或者你加个动态验证，比如时间或者服务器发的 token 。

[SoloCompany]

这问题都讨论烂了
前端加密有任何意义吗？
即便你都要用上非对称加密了， rsa 吧
走 http 的话中间人直接换掉你的公钥，那就和明文没区别了
即便不换掉你的 key
都中间人了
直接捕获你的密码输入，旁路提交到另一个地方又怎么了

[muziyue]

@SoloCompany 抱歉我可没看到其他关于 password_hash 的讨论帖子

[Citrus]

@muziyue 这个问题跟 password_hash 无关，而是如何安全的传输密码ˊ_>ˋ

[qgy18]

@SoloCompany

其实还是有一点用的，如果中间人只嗅探不改包，那么他只能拿到密文，只能用于这一个网站登录。对于不同网站使用同密码的用户来说，能提高一点安全性。

能上 HTTPS 还是直接上 HTTPS 吧。

抛开安全性不谈，浏览器也在逐步淘汰 HTTP ： https://imququ.com/post/moving-to-https-asap.html

[shiny]

password_hash 只不过是加盐与 hash 的打包解决方案。

[muziyue]

@Citrus 不，我本意是问一下是不是不用 https 用了 password_hash 也没啥意义

[shiny]

@muziyue 怎么会没有意义，假设你网站被脱裤，这个时候 password_hash 的作用就提现出来了嘛，不管你用的是不是 https 。

[shiny]

password_hash 的意义在于很多程序员无法正确实现 hash 和加盐。比如拿用户名去加盐就是错误实现方式的一种。

[hard2reg]

@owt5008137 加盐可以防止被撞。。。。

还有，楼上的你们怎么不说别人直接在你电脑种个木马，键盘记录你密码？