android 上，大家有用 BCrypt 算法给用户密码加密的么？ help！！！！

[stewforani]

大家有在 android 客户端给用户密码用 bcrypt 加密的么？我拷了 bcrypt 的 java 源码，但是加密很耗时，有什么好办法减少加密时间么？

[lhbc]

@maemual 了解，写过，怎么了？

[lhbc]

@Inside 安全不是取决哪里最安全，而是哪里最薄弱。
所以，最佳的方法是避免使用任何途径传输明文密码。

[linbiaye]

@lhbc 人家都说走 tls 了，哪里还有什么明文了。
事实标准做法就是登录信息走 https/tls ，服务器端 BCrypt （ salt+hash ）。没什么特殊需求就是跟着标准走啊。
在 C 端做 hash 就得意味着你在手机端 /web 端 /pc 客户端都得做。

[momocraft]

在客户端计算短密码的 bcrypt hash 再明文传输不比强制使用 72byte 密码更安全。你再想想。

[lslqtz]

@maemual 我也不知道什么客户端会跑 bcrypt 都瓶颈的
服务端大量用户访问 再好的 cpu 都不一定抗得住 需要上集群
为成本考虑。

@linbiaye 在已有旧架构这么升级比 https 更方便，不过其实没什么差别

[BOYPT]

那些认为 bcrypt 更安全的人一个主要理由是 bcrypt 比 sha 系列算法慢……

[chineselittleboy]

想知道以后 web 端搞 bcrypt 方便不

[linbiaye]

@lslqtz 你这和我说的啥。你真的服务器端这么做么？架构做成这样就得改。上了规模的架构做成这样也可以开了做架构的了。
处理用户登录的计算量考虑什么性能。除非你的所有服务就是登录。

[jarlyyn]

@lslqtz

客户端不是应该是换 token ，而不是每次都登录么？

[alamaya]

https,服务端加密，你 app 被爆破了，啥加密都没用

[lhbc]

@linbiaye TLS 里就是明文的。到了服务器也是明文的。能通过技术手段还原明文就是不可接受的。
各种客户端计算 SHA 不都是 10 行以内代码的事吗？又不需要自己写 SHA 算法。

[linbiaye]

@lhbc 只能说你们牛逼， PKI 都不值得信任。 TLS 这套本身就是为了防各种攻击，本来就是用作来安全传输。理论上没有什么加密是不可还原的，不过是时间问题罢了。

[linbiaye]

@lhbc ，另外你的客户端 hash 后传输和明文传输对于有服务器端都是字符串，都是有效凭证。

[breeswish]

@lhbc 你这追求的已经到端到端加密的级别啦

[gy911201]

防范中间人要靠 https ，使用 http 提交 bcrypt 后的密码与直接提交明文密码其实没有多少区别……

[lhbc]

@linbiaye 不是不信任 PKI ，我说了安全取决最薄弱的环节。
如果客户端通过 TLS 发送明文密码，路上是加密的，但在服务器看来，就是明文。我说的不是 SHA 碰撞。
网站代码，基础组件和框架，运维，这些都是有条件接触到明文密码的。
所以，让客户的明文密码尽量不离开客户端。

[ryd994]

@lhbc 客户端加密不能增加安全性，重放攻击就好了。
hash 的密文已经成为实质上的明文密码
按你的做法：运维接触到了 hash ，运维只需要重放 /伪造请求，就可以登录
要纠结运维能不能接触密码，怎么不纠结客户端安不安全，中个密码钩子什么都没了

要求更高安全性的场合不应使用密码验证身份，比如用客户端证书，硬件密钥， OTP 这些

[momocraft]

以不传送明文这个目的来说，没有理由认为客户端计算 bcrypt (72byte) 会比计算加盐 sha512 更安全。

所以问题又回到 "图什么"

[lhbc]

@ryd994 一定程度上能防止明文密码泄漏和撞库。
比如说，运维 /入侵者拿到 hash ，能重放，但无法拿去撞库。
另外，有些不懂安全的开发，谁知道他拿着明文会干嘛……也许直接发个邮件给客户说你改了密码，新密码是 xxx
比如某旅游网站，在日志里记录信用卡的安全码。

更高等级的安全就是另外一码事了。

[lslqtz]

@linbiaye 政企。。你懂的
@jarlyyn 没看懂，换加密 token 吗？
加密用 token 这个的确是不太安全，可以考虑通过用户的密码做加密。
解密时用用户输入的密码加密用户输入的密码然后发到服务端，或用用户的密码解密服务端的密文。。
这个，好 tm 复杂 / 怪。。