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

[stewforani]

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

[lhbc]

用 SHA256

[egen]

bcrypt 可以调节复杂度的呀，你设置了多少？

[stewforani]

@lhbc 如果服务器用的是 bcrypt 保存密码，那么客户端这边需要怎么处理密码？

[stewforani]

@egen 是哪个参数 你知道吗？

[cevincheung]

@stewforani #4 cost

[stewforani]

@cevincheung 什么意思？大神

[egen]

@stewforani #4
不知道你用的是哪个库，一般会有一个 ROUNDS 参数，默认的可能是 10 或者 12 ，你可以调低到 8 看看，一般有效值会在 4 到 31 之间。
调整 rounds 参数不会影响旧密码的解密，如果后面你觉得可以性能上来了可以再调高然后更新旧密码即可。

[maemual]

给服务端做啊，干嘛要在客户端做。

[AbrahamGreyson]

楼上说得才是真理，客户端环境不可控，离复杂度设置多少都不合适。

[yidinghe]

BCrypt 的本质就是要耗电，所以如果楼主不想让用户看到自己在耗电名单上名列前茅的话。。。

[honeycomb]

@stewforani
现在还有新的 argon2 算法

[yangqi]

上 https 然后服务器端加密

[lslqtz]

@maemual 在客户端做有两个优点。
1 、减轻服务端负担。
2 、防止中间人攻击。
而无论何种方式，在客户端受到攻击的情况下都没有意义

[maemual]

@lslqtz 1 、服务端还不需要节省这种负担
2 、如果会被中间人，被人截获密码和被截获 bcrypt 之后的结果并没有什么区别

[lhbc]

@maemual 2. 避免大批量泄漏明文密码。最好就是在客户端 hash 一次，服务器加 salt 再 hash 若干次。

[lslqtz]

@maemual 服务器加密的性能同样有限

[maemual]

@lslqtz #16 服务端性能不够可以靠堆机器解决，客户端性能不够准备靠堆什么解决。更何况还没听说哪家穷到连跑 bcrypt 能成为性能瓶颈的。

[maemual]

@lhbc #15 你了解 bcrypt 么？

[Inside]

@lhbc 为何不干脆 https ？

[momocraft]

同感，想不出在客户端做 bcrypt 有意义的场景

[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 复杂 / 怪。。

[jarlyyn]

@lslqtz

我的意思是，登录的时候用加密的

登录好后换 token,之后都用 token 啊。

你不可能所有用户都同时需要登录吧？

5/10 天登录一次，慢点也无所谓吧？

[spongebobsun]

https://github.com/PuffOpenSource/Puff-Android

可以参考下 https://github.com/PuffOpenSource/Puff-Android/blob/master/app/src/main/java/sun/bob/leela/runnable/CryptoRunnable.java 这个

其他代码有点乱，还没时间重构……

我觉得我这个项目是滥用 EventBus 的教材…………(´･Д･)」

[spongebobsun]

@spongebobsun 楼主请忽略我…我这个并没做优化…可以考虑 c 实现然后 jni

[lslqtz]

@jarlyyn 也看并发来着。。
像是大网站之类的

[klesh]

@lhbc 服务端拿到明文后是 hash 后再对比，原则上一个正常的系统不应该存储明文。所以你说的运营人员能接触到这中间的明文我想他们得种马才能达成吧？若运营人员都能在服务器种马了，那你要担心的可远远的不止所谓的明文密码了吧。再说这个运营已经有无限权限了，套出客户明文密码并非难事！
再退一步说，登录成功后你要不给 token 要不 cookie 。若不上 https ，你怎么解决重放的问题？

[lhbc]

@klesh
1. 我没有说过不上 https
2. 运营跟运维不是一个岗位，也不是一个团队

[lslqtz]

@klesh
用真实 IP 做 token 呢？