这是一个创建于 2192 天前的主题，其中的信息可能已经有所发展或是发生改变。
个人认为意义不大，再被劫持的情况下，明文和 md5 是没有区别的吧。大佬轻喷
 |
1
lincanbin 2018-12-29 11:54:10 +08:00  7
有必要，有的运维或者后台会记录包含请求体的 access log，如果不加密，log 里面就是明文密码。
这种在架构上垂直扩展&多层的公司很容易发生。 |
 |
2
yukiww233 2018-12-29 11:55:24 +08:00
可以避免明文撞库吧
|
 |
3
liuzhedash 2018-12-29 11:55:50 +08:00 30
我感觉任何提高攻击成本的设计都是有意义的
|
|
4
lincanbin 2018-12-29 11:56:11 +08:00 1
今年上半年，GitHub 就翻车过一次，在请求日志里发现了明文密码，然后就群发邮件通知用户改密码。
|
 |
5
SuperMild 2018-12-29 11:56:36 +08:00
用 md5 是为了防止破解本站密码吗？
为啥用 md5 不用明文，是为了防止什么？ |
 |
6
yzkcy 2018-12-29 12:34:04 +08:00
在一定程度上可以提高黑客攻击的成本，能加还是最好加上。
|
 |
7
no1xsyzy 2018-12-29 12:44:33 +08:00
加密传输能防止旁听攻击啊，另外，网页不一定是热乎的，可能是从缓存里拉出来的未被劫持的版本
——但不要 md5，换一些专门加密密码的算法。 |
 |
8
ccbikai 2018-12-29 12:56:49 +08:00 via iPhone
有那么一丢丢
|
 |
9
hanru 2018-12-29 12:58:12 +08:00 via Android
用单向函数“加密”等同于明文，用其他方法加密也几乎不可能不犯错误，前端还是不要自己造轮子比较好。
|
 |
10
ladypxy 2018-12-29 13:02:40 +08:00 via iPhone
基本没意义，前段加密，只要有心查下源代码，加密方式轻松找出来
|
 |
11
0ZXYDDu796nVCFxq 2018-12-29 13:06:52 +08:00 via Android
有一定意义
因为 CDN，负载均衡系统，可能会发生 https-->http 的转换，另外一些审计、日志模块也是泄漏的风险。 所以前端进行 hash，后端加 salt 再 hash 是有意义的。 所以，一些更敏感的数据，比如支付系统的，应该用公钥加密给服务端，服务端解密后再处理数据。 |
 |
12
Exceptions 2018-12-29 13:08:06 +08:00
@ladypxy 加密方式又不可逆。。。
|
 |
13
veightz 2018-12-29 13:13:54 +08:00
意义是有的。
比如说传输的数据做非对称加密，可以在一定程度上提高传输链路上的安全性。 |
 |
14
jim9606 2018-12-29 13:16:31 +08:00 via Android
首先，tls 保护不能省的，没有这个你连代码完整性都没法保证，不要用手撸加密库替代 tls。
前端密码推荐使用密钥衍生算法保护(argon2,scrypt,pbkdf2,靠前的更好),需要服务器生成 kdf key。这种算法专门对抗彩虹表，不过对于撞库防御效果较弱 |
 |
15
virusdefender 2018-12-29 13:30:41 +08:00
聊胜于无吧
- 防止后端等位置打印日志直接暴露明文密码（本站还是可以直接用于登录） - 证明服务提供商也不想看你的明文密码（虽然想看还有很多办法） |
 |
16
otakustay 2018-12-29 13:35:40 +08:00
能增加攻击的难度。安全领域并不是非黑即白的，如果小量成本能挡住小学 3 年级的傻子攻击，那就有意义
|
 |
17
icaca 2018-12-29 13:38:31 +08:00
关键数据传输加密这是必须的。
|
 |
18
hoythan 2018-12-29 13:40:10 +08:00
前端也可以 rsa 加密
|
 |
19
LancerComet 2018-12-29 13:41:02 +08:00
现在不都 RSA 加密后传过去么
|
 |
20
VoidChen 2018-12-29 13:43:03 +08:00
前端不加密，密码明文出去可能会被有心人用在关联账号上尝试，比如绑定的 QQ 或者微信什么的
|
 |
21
shadiao 2018-12-29 13:45:01 +08:00 via iPhone
突然想起 12306 明文储存密码以及密保问题答案
|
 |
22
beiyu 2018-12-29 13:46:32 +08:00 1
前端加密主要使用的是 javascript，众所周知 javascript 是暴露在任何用户面前的，所以但从加密的角度上来说，你加密的方式是暴露的，即使我不知道你是什么算法，但是我能用你暴露的 javascript 来计算出你的密码。所以前端加密从某种角度上来说形同虚设。
关于有没有必要加密？这个是有必要的。俗说防君子不防小人，但加密后能阻止一部分因技术不足的人来对 javascript 解密，提高攻击者成本。 然后如何增加解密者的难度呢？对 javascript 进行混淆、加密、压缩是一般使用的方式了，越是生成人类难以理解的语句对破解者来说更难。当然这一切是以牺牲性能为代价的。 ︿(￣︶￣)︿ |
 |
23
newmlp 2018-12-29 13:48:59 +08:00
任何提高攻击门槛的做法都是有意义的
|
 |
24
lzvezr 2018-12-29 13:55:23 +08:00 via Android
感觉一般加密意义不大，中间人重放就可以了，但聊胜于无
顺便一说 B 站采用的是前端非对称加密 |
 |
25
puncsky 2018-12-29 13:59:24 +08:00 1
一般来讲 https 就足够了。
请求日志里出现明文密码，要么是有 bug，要么是日志太弱，没法过滤敏感信息和 PII |
 |
26
lhx2008 2018-12-29 14:05:11 +08:00 1
@beiyu
非对称加密。用公钥加密，知道 JS 源码也没用。 但是我觉得在 HTTPS 下面没必要。另外，如果进日志，肯定不要存密码啊。 如果原封进日志，那所有加密都没有意义。因为这个加密过的密码本来就可以从前端登录进去。我只是不知道明文而已。 CDN 商是可以拦截保存，所以不要啥的都经过 CDN |
|
27
lhx2008 2018-12-29 14:10:16 +08:00 via Android 1
基于上面的分析，还有一种比较稳妥的方式是
前端密码提交的时候，附上 timestamp，用 RSA 公钥加密，服务器私钥解密后验证时间，然后登录一次 timestamp 作废 这样日志泄露或者被拦截，也无法用原密文重放 |
|
28
lhx2008 2018-12-29 14:11:28 +08:00 via Android
当然你用 cdn 过密码，还是防止不了第三人攻击的
|
 |
29
ericls 2018-12-29 14:12:49 +08:00 via iPhone
有意义 特别是有用一些 analytics, logging, performance monitoring 等等 需要上报数据给第三方的服务时
|
 |
30
swulling 2018-12-29 14:16:05 +08:00 via iPhone
有 https 的情况下，前端进行计算是有价值的。github 就是一个大大的反例，把明文密码写日志里。
但是不要用 hash 算法。有很多专门的密码库可以做 |
 |
31
beastk 2018-12-29 14:41:34 +08:00 via iPhone
前端 rsa 加密发送到后端，反正我是这么干的
|
 |
32
Shook 2018-12-29 14:47:06 +08:00
前端密码加密的话，后端就无法校验密码的格式了
|
 |
33
sannyzeng 2018-12-29 14:57:55 +08:00
前端 rsa 加密 +1
|
 |
34
kakudesu 2018-12-29 15:10:32 +08:00
有没有前端加密相关文章啊
|
 |
35
FakeLeung 2018-12-29 15:11:58 +08:00
|
 |
36
iiji86 2018-12-29 15:12:02 +08:00 1
看了下苹果、微软、谷歌、fb 这几个登录页面都是明文传输密码的，百度、淘宝、qq 都是先前端加密，总结一下就是在国外没意义，国内有意义
 |
|
37
lhx2008 2018-12-29 15:26:16 +08:00 via Android
@FakeLeung 公钥谁都可以知道的，伪造是可以的，关键是你不知道正确的密码，即使半路拦截了密文，没有私钥也无法解开。
|
|
39
lhx2008 2018-12-29 15:35:00 +08:00 via Android
@FakeLeung 是的，HTTPS 本身就可以防止第三人监听，但是楼上也说会有一些被服务端明文记到日志，然后日志有可能泄露，这个。。
|
 |
42
Xek1n 2018-12-29 15:46:55 +08:00
用 HTTPS 的加密不加密就没多大关系，用 HTTP 的也勉强有点拖时间的作用，前者会自动在传输上使用非对称加密，所以在数据传输过程中即使被人打下来也拿不到原密码，后者如果为明文，那就直接被拖走，如果为加密，那攻击者还必须知道你加密的方式，不过这点在前端基本都是透明的，只要多费点心思查一下网页 js 就清楚了。所以如果网站的用户表比较重要的话还是上 HTTPS 吧。
|
|
43
hanru 2018-12-29 16:06:40 +08:00 via Android 1
无语了，这么多人认为在前端（浏览器里）把密码加密一下是有意义的…
在正确启用 HTTPS 的前提下，这么做完全是脱裤子放屁好不好？ 不理解的话，想一想如果坏人拿到了加密后的密码，直接发送给服务器是什么效果？和他拿到不加密的密码有什么区别？ |
 |
44
ysc3839 2018-12-29 16:12:11 +08:00
对于 https 来说无意义，对于 http 来说可以防止嗅探流量，防止不了中间人攻击。
|
|
45
hanru 2018-12-29 16:17:11 +08:00 via Android
@iiji86 这是国内长期 HTTP 当道（包括登录页面）的历史遗留问题，毕竟国内大规模普及 HTTPS 是近两年的事——这还得感谢劫持黑产为些做出的贡献。😀
|
 |
46
reb00ts 2018-12-29 16:27:48 +08:00
当然有意义啊，防止 request body 以各种理由被保存在 log、db 里，这样就存在泄漏风险。另外 HTTPS 只是保证了传输链路的防窃听、篡改、冒充，端上的防护还是有必要的
|
 |
47
mytry 2018-12-29 16:51:27 +08:00
文不对题 —— 标题里说“加密”，内容里却说 md5 （哈希），两个完全不同的概念。
|
 |
48
kkllxy 2018-12-29 16:55:52 +08:00
战马
|
 |
49
zzzzzzZ 2018-12-29 17:03:58 +08:00
笑看楼上一群密码学和前后端加密机制都不知道的菜鸡在这里科普“用了 HTTPS 就不用加密啦”
另外前端不止是浏览器，大专毕业了再来跟大家谈笑风生好吗 |
 |
50
wanghao2018 2018-12-29 17:45:18 +08:00
@ysc3839 大哥 你是认真的吗 ？
|
|
51
ysc3839 2018-12-29 17:48:15 +08:00 via Android
@wanghao2018 什么意思？
|
 |
52
passerbytiny 2018-12-29 18:05:22 +08:00
不加背景的讨论前端 web 密码加密是否有意义，讨论本身就是毫无意义的，就好比：还不知道用不用 JPA 的时候，去讨论布尔类型的列用什么类型。
假如，有完整的 https，日志记录也能保证脱敏，那么，前端加密就是脱裤子放屁。假如因为各种原因（最终都能归类为老板太抠）不能上完整的 https，那么前端加密就是非常有必要的。假如日志记录没脱敏，那就赶紧查查还有那些漏洞没处理，前端加不加密现在不重要。 |
 |
53
oonnnoo 2018-12-29 18:12:41 +08:00 via iPhone
知乎之前有讨论过。
端对端加密就是前端加密。 前端加密的意义是为了保护用户隐私。 不过这样加密后，你后端也是拿不到明文数据的。 否则前端加密就没有意义。 |
 |
54
kongkongyzt 2018-12-29 18:24:33 +08:00
没什么意义. 不论加密算法是不是可逆的, 攻击者使用中间人重放都是一样的.
另外, 如果用的是不可逆算法, 注册的时候后端就无法检查密码的长度, 符号规则等等了. 当然, 你也可以注册的时候用可逆算法, 然后把 md5 后的数据存入数据库, 登录的时候前端传 md5. 但是如果你打算是 salt + md5 的密码数据入库的话就不行了, 你总不能下发 salt 到前端让前端在登录的时候计算 salt+md5 的值吧 简单的事情简单做, 登录的安全是要花精力, 但是不是花在这个方向上 |
|
55
hanru 2018-12-29 18:48:01 +08:00
@oonnnoo 端到端（ end to end, e2e ）加密是另一回事，和前端（ front end ）加密没有任何关系。前端相对于后端（ back end ）。前端是与后端交换数据的界面，这里讨论的 web 前端指的就是浏览器、App 这类东西。
不得不说中文的术语太不严谨了。 |
 |
56
agagega 2018-12-29 18:49:47 +08:00 via iPad 2
1. 在非 SSL 的情况下，服务端发过来的 JavaScript 代码完全有可能被劫持篡改。所以这种情况下去尝试自己用 JavaScript 实现一套 SSL 不是重复造轮子，而是完全不可行。那为什么浏览器可以安全地实现 SSL ？因为浏览器那部分代码是你下载的时候就内置在里面的。换句话说，如果你用了不安全的途径下载浏览器，理论上也可能被篡改。
2. GitHub 和 Twitter 把密码泄露到日志中的原因应该是某个日志相关的中间件配置不当。正常的 HTTP 日志不会去记录这些 POST、PUT 请求的请求体内容。就算前端不直接传明文密码，遇到这种情况，总不可能说就不算泄露了吧？ 3. 前端那个不叫「加密」，叫散列、摘要。知乎上有个和本帖标题差不多的问题，下面一群人义愤填膺地驳斥认为前端「加密」没有意义的人（现在应该排序好多了，见 https://www.zhihu.com/question/25539382/answer/539557939 ），真是替其中某些程序员的老板捏把汗。 4. 有重放攻击这种东西。有些东西多学习下大厂和知名框架的最佳实践就行了。 5. 我觉得需要前端对密码明文处理一下的只有一类情况：就是后端不应该得到用户的明文密码。诚然只要是用了成熟一点的框架的网站肯定都知道把密码通过一些安全的散列（比如 Bcrypt ）之后再存数据库，也不会再去把明文密码存到另一个地方。不过像端到端加密的应用里，你可能不希望服务端在任何情况下看到你的明文密码。 @zzzzzzZ 没毕业。所以是啥机制？ |
 |
57
oyosc 2018-12-29 18:57:52 +08:00
可以加密比较隐私的数据，其他的没必要
|
 |
58
expy 2018-12-29 19:28:51 +08:00
可以防止中间人拿明文去其它网站撞。
|
 |
59
checkzhzzzzz 2018-12-29 20:27:30 +08:00
楼上前端加密形同虚设?RSA 公钥私钥?
|
 |
60
Rubicker666 2018-12-29 20:46:43 +08:00
@lincanbin 是 Twitter 吧
|
 |
61
leoleoasd 2018-12-29 20:53:55 +08:00
1. 传 md5 有用 可以防止被爆库
2. 说无法加盐的 后端可以再次加盐后用后端的方式加密 3. 还有一个好处就是用户调用 api 的时候 可以可以直接是密码的 md5 |
 |
62
lasuar 2018-12-29 22:37:10 +08:00
传 MD5，即使监听请求也是看到 md5 后的秘钥，无法解密 /模拟，不加密的话在请求中你的密码就是以明文在网络中传输。
|
|
63
lasuar 2018-12-29 22:38:51 +08:00
最主要是防楼上的已经说过的 log 以及脱裤。
|
|
64
lincanbin 2018-12-29 23:20:33 +08:00 via Android
@Rubicker666 很多大厂都做过这种事，这两家公开说过自己发生过这种事。
因为量级大的情况下，bug 会更容易被发现，但是一般收到用户反馈后又很难复现。 有的人为了方便就会不对数据脱敏直接写日志，方便重现现场。 |
 |
65
IvanLi127 2018-12-30 00:52:37 +08:00 via Android
个人认为，前端密码哈希是保护用户隐私的一种方式，仅此而已。前端哈希对自己系统没啥意义，对用户可能有点意义，至少不可能把用户原始密码公之于众。不过，自己搞加密是真的没啥用，瞧不起 HTTPS 这些？
|
|
67
zzzzzzZ 2018-12-30 09:11:20 +08:00 via Android
@agagega #55
你发的这个 answer 已经把你的脸打肿了，还再说啥？ ##任何场合下都不应该传输明文密码，无论它是什么密码。 请告诉我后端在什么场合下需要得到明文密码？得到明文密码有什么用？用来 regex ？非明文的就不能 regex 了？ 只有在你这样的垃圾程序员懒得写代码解密直接一撸到底明文放到数据库顺便打个 log 的情况下后端才需要明文密码，其他任何场合后端都不需要明文密码 然后上面就有菜鸡又提了，别人可以拆包呀，找 js 的加密 key 照样可以解密了呢。 公私钥了解一下？ 然后上面又有菜鸡又提了，别人做中间人，做重放，照样可以拿到**md5**，重现请求照样可以操作呢，反正黑客攻击能做到，关我前端什么事呢。 脱库了解一下？撞库了解一下？攻击成本了解一下？ 真以为加密就是后端的事情咯 得到用户第一手的隐私信息不脱敏就直接扔 我不是性别歧视，我只是想说：如果女人的 B 有密码，那你这样的肯定是 123456 |
|
68
zzzzzzZ 2018-12-30 09:20:09 +08:00 via Android
|
|
69
hanru 2018-12-30 09:25:46 +08:00 via Android
@geelaw 我是针对前面提到的知乎上把端到端等同于前端发的评论，我应该说的是知乎上对于中文术语的使用太不严谨了。
|
|
70
zzzzzzZ 2018-12-30 09:48:13 +08:00
@agagega #55
看错了，既然是完全公正客观地从学术角度谈 js 加密。那我不应该是这样的讨论语气，在这里道歉。 顺便，第一条浏览器 SSL 的事情，猎豹浏览器窃取用户信息，UC 浏览器 DNS 污染这些事情可以了解一下。 被脱库的事件，泄露 500 万密文和泄露 500 万明文的差别很大，前者顶多击中 500 万，后者可能会击中三四千万账号。不然大家何必用 1password |
 |
71
kingcc 2018-12-30 10:02:10 +08:00
首先，劫持了做不做 hash 都一样吧……
第二，做 hash 应该是为了安全等级吧。一般注重用户信息保护的都不会存用户的明文密码的 |
 |
72
cyrbuzz 2018-12-30 11:31:59 +08:00
歪个楼，
除了劫持方面，前端进行加密的话还能起到防止数据轻易得到的作用吧。 比如要抓取一个 APP 里必须登陆后才会返回的数据，抓包得到的请求数据是这样的： ``` username=123456&password=654321 ``` 这个抓取成本不用说...，随随便便都能模拟出登陆然后抓取。 但如果抓到的是 ``` f11d8b13da6e83cf588b6d6dd0c13a5f ``` 在不了解具体的加密算法之前无论如何都不太可能模拟出登陆这个步骤。 |
 |
74
wolfie 2018-12-30 11:51:30 +08:00
针对会劫持，但懒得看加密过程😂😂
|
 |
75
reself 2018-12-30 14:13:13 +08:00 via Android
@cyrbuzz http 这种明文传输的，黑客想干啥都行，密码 hazh 了也没用，直接重放攻击，管他内容是啥，劫持下来，原样发过去照样登录。要在 http 下防止这些，这几乎等于自己写了一套 ssl/tls，没准还考虑不周全有漏洞，所以还不如用 https 呢。
|
 |
78
chinvo 2018-12-30 14:35:37 +08:00 via iPhone
你 JS/wasm 再怎么加密，中间人都只需要重发数据包而已，真要保安全，还是 HTTPS + cert pinning
密码学最忌讳闭门造车和自己造轮子。一切需要靠算法保密来维持“安全性”的加密方式都是不可靠的。在前端实现对称加密连密钥都是随时会泄露的，而实现非对称加密根本上和 HTTPS 是一样的（而且你的实现还会因为自己造轮子得不到广泛的审计从而不能快速发现并修补可能的弱点 |
 |
79
eslizn 2018-12-30 14:58:25 +08:00
说记录日志会泄漏的，没考虑过前端加密和没加密有啥区别吗？而且一般请求日志是不写 body 内容的
|
|
80
reself 2018-12-30 15:02:18 +08:00 via Android
@cyrbuzz 抱歉打错了，hazh->hash
先说结论，客户端散列是有意义的，但不在于防属于信道安全的劫持问题，而是防端点安全问题。针对楼主的分场景讨论一下。 不可信传输信道下（例如 http ），就密码散列而言，没啥卵用，毫无安全性，中间人可以直接篡改密码字段，改成由他构造的密码。当然如果前端用 rsa 加密，那光有加密还不行，还要做签名防篡改。用户名和密码的加密了也不够，用户的敏感操作（比如付款）也要加密，内容一多就有性能问题，要引入更快的对称加密和密钥协商。这基本上等于手撸一套 ssl，成本太高，而且非常容易出 bug。 可信传输信道下（例如 https，在这里不讨论 https 本身的安全问题，如果讨论的话就成了拜占庭问题了），这么做也颇有意义。解决了传输信道的安全问题就万事大吉了吗？还有端点的安全问题。客户端和服务端总有一个加密和解密的过程：客户端加密之前的步骤得小心翼翼，上钩子防键盘窃听，内存保护，各层的日志得仔细审核防止记录密码，还有就是楼主质疑的这点，服务端不完善的话（就算确认了对端的身份，也要假设对端存在泄露风险），要对密码进行散列，而且直接散列都不行，要加盐散列，防止用户密码泄露后被字典攻击和在别的网站密码重放。服务端解密后的过程也是，拿到密码也要再进行一次散列（这里就是包含密钥的加盐散列了），日志层要仔细审核防止记录密码，还要保证散列密钥、私钥的安全。随着计算性能的提高，加密和散列算法或者短密钥也会暴露出问题，如何及时替换老旧算法或者老旧密钥也是个问题。 扯远了，总之客户端做密码散列也是有意义的，意义不在于劫持问题，而是端点的安全问题，区分传输信道的安全和端点安就很好理解了。 |
 |
82
explore365 2018-12-30 15:09:21 +08:00
@zzzzzzZ 已经讲的很全了，怎奈还有很多没有安全常识的人。。。
了解一下撞库，了解一下社工。。。 任何一个小的爆破点，都能被做网安人无限放大来用。。。 还是要慎重一些好。。。 最后再说一句，前端做个 hash 还是非常非常非常有必要的。 |
 |
83
dongyx 2018-12-30 15:16:23 +08:00
服务器每次发一个随机盐过来，前端先把密码哈希，然后把哈希值加盐再哈希发回去，服务器拿到二次加盐哈希后，把数据库里的密码哈希用这个盐做二次哈希再比对嘛。 监听到二次带盐哈希也没用，下次盐就变了。
|
|
84
zzzzzzZ 2018-12-30 16:12:09 +08:00
|
|
85
chinvo 2018-12-30 16:18:07 +08:00 via iPhone
@explore365 #77 前端 hash 和直接发明文，对于后端和数据的安全性上来说是没有任何差别的
|
|
86
agagega 2018-12-30 17:07:55 +08:00 via iPhone
@zzzzzzZ 后端存储的时候把密码再加密当然是有意义的。我的意思是，如果说前端实现的各种加密是后面的 0 的话，完整的 HTTPS 就像是开头的 1。在我第一次看到知乎那个问题的时候，一帮人在争论没有这个 1 的前提下怎么自己造轮子比较重要，有点不知道该说什么，所以说话也绝对了点。80 楼说得很好了。
每个应用都有自己独特的要求，比如像 LastPass 这样的，就算有了 SSL，直接发明文密码也不合适。但是对大多数网站而言，恐怕先把传输过程中的安全做好比较要紧。顺便，发 hash 的话怎么做 regex ？我很好奇。 另外，我可从来没有用过 123456 这种东西做过密码：） |
|
87
agagega 2018-12-30 17:25:18 +08:00 via iPhone
Dropbox 的密码保护实践是：先用 SHA-256 散列密码让长度一致，然后 bcrypt，再用 AES 加密。这应该是比较靠谱的实践，不过是否一定要在前端完成呢？
另外，国外一部分网站要考虑没有 JavaScript 运行环境或者没有启用的用户，这种情况下就算要给前端做也没法做了。 |
 |
88
Mohanson 2018-12-31 01:34:19 +08:00 via Android
唯一的正确做法是用“签名”，而不是用 n 个复杂的你所谓加密 /哈希算法。
r = a(b(c(password))) 无论 a, b, c 函数多复杂，你发给服务端的永远是 r. 因此最后的 r 实际上就是明文密码。 |
 |
89
ihciah 2019-01-01 13:16:31 +08:00 via iPhone
有的系统是后端提供一个随机盐给网页，前端 hash(pwd)后再加盐 hash，传给后端。
|
|
90
zzzzzzZ 2019-01-02 10:42:13 +08:00
@agagega
* 用散列当然做不了 decrypt，但是前端 encrypt 当然是可以后端 decrypt，我从来没有讨论过散列的解密，并且 md5 都是带引号声明过。 * 其实本帖很多人一边坚持推崇 HTTPS 的 SSL 是多么安全，一边又用中间人做开脱才是我真正愤怒的原因，明摆着的双标。 * 大家可以不做加密，让用户的隐私赤条条的在互联网上到处跑，不过是企业信息安全的一个小漏洞外带一点点用户隐私相关道德层面的不负责而已。 * 但是一边担保 HTTPS 的安全，一边又用中间人等方式加密与否都能登录做借口。后者的存在才是前端需要加密的真正原因。 * 另外，由于很多不可抗因素的存在，很多 HTTPS 通讯其实从用户到服务器的过程中并不是完全的 HTTPS，中间可能会由于 DNS 等存在进行非 HTTPS 的数据传输。这等同于未被启用的中间人攻击，或者说其实有启用监控但未被滥用的中间人。 * 推崇 HTTPS 而不加密的那些用户数据，正在这些监控下裸奔 |
 |
91
legiorange 2019-01-02 15:22:45 +08:00
我求你们别用 MD5 了行吗？
HTTPS 在中间人的情况下，采用一样的证书就看得见明文密码，在此声明，所有的证书都是可以伪造的。 传统的密码输入，应该在不久后被摒弃，1 是注册量很多，要记得密码很多，2 是没有 2FA 验证安全。 我们应该推崇的是更换密码验证的方式。 |
 |
92
ruandao 2019-06-03 16:20:42 +08:00
|
Select Language