android 上，大家有用 BCrypt 算法给用户密码加密的么？ help！！！！
stewforani · 2017-03-16 20:39:55 +08:00 · 12007 次点击这是一个创建于 2795 天前的主题，其中的信息可能已经有所发展或是发生改变。
大家有在 android 客户端给用户密码用 bcrypt 加密的么？我拷了 bcrypt 的 java 源码，但是加密很耗时，有什么好办法减少加密时间么？
 |
1
lhbc 2017-03-16 21:08:06 +08:00
用 SHA256
|
 |
2
egen 2017-03-16 21:11:17 +08:00
bcrypt 可以调节复杂度的呀，你设置了多少？
|
 |
3
stewforani OP @lhbc 如果服务器用的是 bcrypt 保存密码，那么客户端这边需要怎么处理密码？
|
|
4
stewforani OP @egen 是哪个参数 你知道吗？
|
 |
5
cevincheung 2017-03-16 21:14:18 +08:00
@stewforani #4 cost
|
|
6
stewforani OP @cevincheung 什么意思？大神
|
|
7
egen 2017-03-16 21:18:44 +08:00
@stewforani #4
不知道你用的是哪个库，一般会有一个 ROUNDS 参数，默认的可能是 10 或者 12 ，你可以调低到 8 看看，一般有效值会在 4 到 31 之间。 调整 rounds 参数不会影响旧密码的解密，如果后面你觉得可以性能上来了可以再调高然后更新旧密码即可。 |
 |
8
maemual 2017-03-16 21:53:56 +08:00  2
给服务端做啊，干嘛要在客户端做。
|
 |
9
AbrahamGreyson 2017-03-16 21:56:55 +08:00 via iPhone
楼上说得才是真理，客户端环境不可控，离复杂度设置多少都不合适。
|
 |
10
yidinghe 2017-03-16 23:39:02 +08:00 1
BCrypt 的本质就是要耗电，所以如果楼主不想让用户看到自己在耗电名单上名列前茅的话。。。
|
 |
11
honeycomb 2017-03-17 00:26:18 +08:00
@stewforani
现在还有新的 argon2 算法 |
 |
12
yangqi 2017-03-17 00:27:40 +08:00
上 https 然后服务器端加密
|
 |
13
lslqtz 2017-03-17 01:47:53 +08:00
|
|
14
maemual 2017-03-17 08:28:44 +08:00 via iPhone
@lslqtz 1 、服务端还不需要节省这种负担
2 、如果会被中间人，被人截获密码和被截获 bcrypt 之后的结果并没有什么区别 |
|
15
lhbc 2017-03-17 08:49:00 +08:00 via iPhone
@maemual 2. 避免大批量泄漏明文密码。最好就是在客户端 hash 一次，服务器加 salt 再 hash 若干次。
|
|
17
maemual 2017-03-17 08:56:39 +08:00
@lslqtz #16 服务端性能不够可以靠堆机器解决，客户端性能不够准备靠堆什么解决。更何况还没听说哪家穷到连跑 bcrypt 能成为性能瓶颈的。
|
 |
20
momocraft 2017-03-17 09:04:18 +08:00
同感，想不出在客户端做 bcrypt 有意义的场景
|
 |
23
linbiaye 2017-03-17 09:21:48 +08:00
@lhbc 人家都说走 tls 了，哪里还有什么明文了。
事实标准做法就是登录信息走 https/tls ，服务器端 BCrypt （ salt+hash ）。没什么特殊需求就是跟着标准走啊。 在 C 端做 hash 就得意味着你在手机端 /web 端 /pc 客户端都得做。 |
|
24
momocraft 2017-03-17 09:24:00 +08:00
在客户端计算短密码的 bcrypt hash 再明文传输不比强制使用 72byte 密码更安全。你再想想。
|
|
25
lslqtz 2017-03-17 09:51:38 +08:00 via iPhone
|
 |
26
BOYPT 2017-03-17 09:53:52 +08:00
那些认为 bcrypt 更安全的人一个主要理由是 bcrypt 比 sha 系列算法慢……
|
 |
27
chineselittleboy 2017-03-17 09:58:27 +08:00
想知道以后 web 端搞 bcrypt 方便不
|
|
28
linbiaye 2017-03-17 10:12:27 +08:00 1
@lslqtz 你这和我说的啥。你真的服务器端这么做么？架构做成这样就得改。上了规模的架构做成这样也可以开了做架构的了。
处理用户登录的计算量考虑什么性能。除非你的所有服务就是登录。 |
 |
30
alamaya 2017-03-17 10:24:07 +08:00
https,服务端加密，你 app 被爆破了，啥加密都没用
|
|
31
lhbc 2017-03-17 10:35:35 +08:00 via iPhone
@linbiaye TLS 里就是明文的。到了服务器也是明文的。能通过技术手段还原明文就是不可接受的。
各种客户端计算 SHA 不都是 10 行以内代码的事吗？又不需要自己写 SHA 算法。 |
|
32
linbiaye 2017-03-17 10:46:48 +08:00
@lhbc 只能说你们牛逼， PKI 都不值得信任。 TLS 这套本身就是为了防各种攻击，本来就是用作来安全传输。理论上没有什么加密是不可还原的，不过是时间问题罢了。
|
 |
35
gy911201 2017-03-17 10:57:20 +08:00
防范中间人要靠 https ，使用 http 提交 bcrypt 后的密码与直接提交明文密码其实没有多少区别……
|
|
36
lhbc 2017-03-17 11:57:02 +08:00 via iPhone 2
@linbiaye 不是不信任 PKI ，我说了安全取决最薄弱的环节。
如果客户端通过 TLS 发送明文密码，路上是加密的，但在服务器看来，就是明文。我说的不是 SHA 碰撞。 网站代码，基础组件和框架，运维，这些都是有条件接触到明文密码的。 所以，让客户的明文密码尽量不离开客户端。 |
 |
37
ryd994 2017-03-17 12:14:45 +08:00 1
@lhbc 客户端加密不能增加安全性，重放攻击就好了。
hash 的密文已经成为实质上的明文密码 按你的做法：运维接触到了 hash ，运维只需要重放 /伪造请求，就可以登录 要纠结运维能不能接触密码，怎么不纠结客户端安不安全，中个密码钩子什么都没了 要求更高安全性的场合不应使用密码验证身份，比如用客户端证书，硬件密钥， OTP 这些 |
|
38
momocraft 2017-03-17 12:18:18 +08:00
以不传送明文这个目的来说，没有理由认为客户端计算 bcrypt (72byte) 会比计算加盐 sha512 更安全。
所以问题又回到 "图什么" |
|
39
lhbc 2017-03-17 13:25:01 +08:00 via iPhone 1
@ryd994 一定程度上能防止明文密码泄漏和撞库。
比如说，运维 /入侵者拿到 hash ，能重放，但无法拿去撞库。 另外，有些不懂安全的开发，谁知道他拿着明文会干嘛……也许直接发个邮件给客户说你改了密码，新密码是 xxx 比如某旅游网站，在日志里记录信用卡的安全码。 更高等级的安全就是另外一码事了。 |
|
40
lslqtz 2017-03-17 16:40:13 +08:00
|
 |
41
jarlyyn 2017-03-17 17:33:44 +08:00
|
 |
42
spongebobsun 2017-03-17 19:04:29 +08:00
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 的教材…………(´･Д･)」 |
|
43
spongebobsun 2017-03-17 19:06:35 +08:00
@spongebobsun 楼主请忽略我…我这个并没做优化…可以考虑 c 实现然后 jni
|
Select Language