这是一个创建于 2765 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如传输账号密码
第 1 条附言 · 2017-05-05 15:05:15 +08:00
看了下各位的回复，我这个是打算做数据接口的，不是前端调用。如果要加密的话，怎么加？
 |
1
Ahri 2017-05-05 12:19:58 +08:00  1
不用。不加 HTTPS 而前端加密的公司千万不要去。
|
 |
2
morethansean 2017-05-05 12:20:53 +08:00
那这样问，你在传输过程中再加一次密是要干嘛？
|
 |
3
Mitt 2017-05-05 12:21:01 +08:00
正常情况下的 https 就不需要单独加密了
|
 |
4
lovedebug 2017-05-05 12:22:34 +08:00
https 可是有降级攻击的~
|
 |
5
DoraJDJ 2017-05-05 12:24:22 +08:00 via Android
别忘了中间人攻击
|
 |
6
yoa1q7y 2017-05-05 12:26:05 +08:00
不用
|
 |
7
henices 2017-05-05 12:28:44 +08:00
公司锁了大门，个人的抽屉需要上锁吗？
|
 |
9
smartychaos 2017-05-05 12:32:23 +08:00
分情况，很多场景需要后端加密，只确保传输层安全是远远不够的。前端加密倒是可以部分取代，例如登陆密码的传输。
|
 |
10
justfly 2017-05-05 12:34:14 +08:00
有合法证书的情况下，中间人也没有办法的，只要用户不在浏览器提示证书错误的时候继续浏览，密码就不会泄漏，除非诱导用户安装指定的根证书，这种个例问题不属于 https 解决的问题的范畴。
要防止这种针对单个用户的攻击或者是对你应用的协议分析，web 前端加密没毛用，加密的 js 代码是裸的，自己写的 native 客户端在不被反编译的情况下可以用一下，这就看你们的投入产出比了。一般没啥太大意义 |
 |
12
int64ago 2017-05-05 12:36:46 +08:00
顺手能加个密就加吧，毕竟 HTTPS 只是协议层的加密，业务层不确定因素还是挺多的
|
 |
14
SourceMan 2017-05-05 12:43:12 +08:00
可以是可以的
但是这就好像我们一直说的 “过度优化”：我有 5W 条数据，怎么查询快一些 |
 |
16
Chrisplus 2017-05-05 12:56:56 +08:00
借楼求问， 使用 https 之后，账号密码一般直接传明文，还是哈希一下再传？
|
 |
19
dongoo 2017-05-05 13:04:00 +08:00 via Android
如果要的话，可以像 lastpass，本地加密后再传输。
|
 |
20
tony1016 2017-05-05 13:07:15 +08:00
@justfly naive.用 bettercap 轻松搞定你们的 https。要防止降级攻击，HSTS，甚至更严格的 PRELOAD LIST 之类。不过要看，银行一般都不会只相信 https
|
 |
21
sobigfish 2017-05-05 13:07:54 +08:00
传回服务器的不用加，在浏览器上显示的敏感信息要 防止 xss
|
 |
23
mcspring 2017-05-05 13:35:40 +08:00
问题不是这样滴，你虽然用 HTTPS 加密了传输，但 HTTPS 的证书是谁给你的？这个证书链向上的任何一级都可以解密你的传输数据！
也许你会说“人家都是颁发机构了，你防他们有什么意义？”，这个问题的回答就是他们持有根证书，但他们无法防止别人也持有他们的根证书！ |
 |
24
atc 2017-05-05 13:56:50 +08:00
单就账号密码而言，请倡导用户使用两步验证，不要只关注加密的问题，密码总会有其他途径泄露的
|
 |
25
ExploreWay 2017-05-05 14:07:03 +08:00
不太了解 https 协议，不过看大家的评论倒是学到了不少。
|
 |
26
wevsty 2017-05-05 14:16:50 +08:00 1
@mcspring
证书链向上的任何一级都可以解密你的传输数据这个认识从根本上就是错误的。 如果是自己生成的私钥，那么即使是证书颁发者也不能解密通信。 HTTPS 面临的问题是，CA 可信度的问题，预防中间人这样的攻击行为关键在于是否能发现虚假的服务器，而验证服务器身份又依赖于 CA 的信任关系。只不过目前来看，没有一种更可靠的体系来代替目前的 CA 体系。 |
 |
28
zealot0630 2017-05-05 14:27:34 +08:00 via Android 1
在客户端对密码做 hash 是世界上最蠢的
打个比方，你把大门钥匙锁在家门口保险箱里面，然后出门拿着保险箱钥匙 大门钥匙=hash 后密码 保险箱钥匙=原密码 服务器（大门）只认 hash 后的密码，从原密码可以轻松得到 hash 后的密码（打开保险箱） 然而 一旦黑客拿走了你的大门钥匙，他还需要保险箱钥匙么？ 黑客直接拿你 hash 后的密码登录服务器就拥有你所有权限了，根本不需要去拿原密码 |
 |
29
wshcdr 2017-05-05 14:35:13 +08:00
HTTPS 有三个作用：1.身份认证 2.传输保密 3.传输过程中的数据完整
|
 |
30
XDA 2017-05-05 14:42:00 +08:00
# 搭车问个问题，买了 Symantec 的泛域名证书，怎么用在对外提供的服务接口上？
|
 |
31
ryd994 2017-05-05 14:47:25 +08:00 3
我就问一点：要是自己加一层更好，为什么 TLS 不自动帮你加这一层？
是该有多自(sha)信(bi)才会觉得自己的姿势比业界学界的专家们几十年的结论更高？ 这可不是单纯的理论，黑客白客一直都在不停的攻防。也就国内网银还玩插件这傻逼玩意。BoA https，密码直接传。 |
 |
33
hsmocc 2017-05-05 14:53:39 +08:00 via iPhone
加密后，爬虫抓数据会困难点
|
 |
34
imherer 2017-05-05 15:02:17 +08:00
感觉能加最好还是加一下。
|
|
35
ryd994 2017-05-05 15:04:09 +08:00
|
 |
36
RqPS6rhmP3Nyn3Tm 2017-05-05 15:06:27 +08:00 via iPad
要看有多敏感。如果 1Password 只有 https 加密了，我看没人敢用。
|
|
37
ryd994 2017-05-05 15:06:33 +08:00
@mcspring 无法保护好私钥的 CA，乱签证书的 CA，结果看 WoSign 就知道
真要无法相信 CA，你有何必用 HTTPS ？自己发明一套宇宙无敌安全协议不是更好？ |
|
38
ryd994 2017-05-05 15:10:40 +08:00
用作数据接口的话，你是说想要加密防协议泄露么？
分发客户端的前提下，最终都是能逆向客户端取得的，成本问题而已 基础的话做下 pinning，防止客户自己替换 CA 中间人自己 复杂的话你还是先考虑下客户端防逆向 |
|
39
ryd994 2017-05-05 15:19:30 +08:00
@BXIA 那是因为
1.服务器不完全可信，我会担心 1password 的 admin 看我密码。而 CA 想要中间人我，还要控制网络 2.不需要向其他人传输，密码只有我需要知道。我不需要信任链，只需要 PSK 1password 的应用场景和 TLS 截然不同，不能一概而论。要是自己加密就能可靠的话，GPG 应该比 TLS 更流行才对。 实际上 1password 的安全性最终还是取决于 HTTPS：如果 HTTPS 破了，下到的是带后门的客户端，什么都泄露了 |
|
40
lovedebug 2017-05-05 15:19:47 +08:00
@mcspring 这样理解其实不太对。证书公钥主要是用来加密后续数据传输使用的私钥。只有公钥拿不到对称密钥也不能解密数据。
|
|
41
lovedebug 2017-05-05 15:22:26 +08:00
@ryd994 其实你理解的不对。 国内银行的 U 盾实现的双向证书认证，可以有效的避免被攻击。因为客户用自己的私钥加密的数据，并将公钥通过服务器的公钥加密后交还给了服务器，由于公钥不是众所周知的，相对安全不少。
|
|
43
lovedebug 2017-05-05 15:25:35 +08:00
@ryd994 HTTPS 赖以为生的是 CA 的可信性，可惜现在大厂也会出错，verisign 之类的也发生过。 如果不相信对方的证书有效性，可以自己发起 OCSP 验证。
|
|
44
lovedebug 2017-05-05 15:27:03 +08:00
@ryd994 chrome 浏览器更强大，谷歌强制要求所有证书被谷歌的服务验证，so，可以通过 google api 验证证书,保证证书的唯一性和有效性
|
|
45
ryd994 2017-05-05 15:37:04 +08:00
@lovedebug U 盾和浏览器插件是两回事。U 盾是硬件密钥，由可信硬件来处理加密过程。私钥在任何情况下都不在硬件外存在。而浏览器加密，不就是纯软件 TPM 么？纯软件 TPM 除了 debug 用途外，没有实际安全意义。
“并将公钥通过服务器的公钥加密后交还给了服务器”你的理解是错的。双向 TLS 是 TLS 协议的一部分。客户端证书和服务端证书一样，由 CA 保证。要是由客户端发公钥，服务端不检查证书链的话，等于单向 TLS，因为只要破了服务端 TLS 就能中间人客户端证书。 至于 U 盾，虽然不一定是双向 TLS，但一样会检查客户端证书。 要是哪个银行是客户端发什么公钥服务端就用什么的话，大概是安全审计脑子被驴踢了。 “由于公钥不是众所周知的，相对安全不少” 黑人问号？？？公钥当然是扩散的越广越安全啊。藏着掖着你就等着被中间人吧 我的公钥就在 https://github.com/renyidong.keys 任何人都可以随意获取 我一直以来就两个观点： 1. 能上 TLS 的都上 TLS 2. TLS 不够的，上硬件密钥 |
|
46
tony1016 2017-05-05 15:42:01 +08:00
@ryd994 不要把国外的银行拿出来套中国的国情，也不要简单觉得 HTTPS 那么安全。TSL 核心是安全的没错，但是 TSL 到 HTTPS 的过程涉及很多问题，所以即使没有 CA 的问题，也会被降级攻击，普通用户根本意识不到。你可以研究研究 bettercap 的做法，我亲自试过，gmail 密码随便取。不想学工具，就看看视频
|
|
47
ryd994 2017-05-05 15:43:08 +08:00
@lovedebug OCSP 不是用来解决那个问题的。OCSP 是保证私钥泄露时可以 revoke。
你说的问题，是由 Certificate Transparency 审计保护的。各大 CA 都在签发系统内加入了 CT，任何证书都有连续 id，且会向 CT 备案。wosign 的事情就是查 CT 查出来的。敢绕过 CT 的 CA，恐怕比 wosign 死的还惨。 google 那是另一套系统，和 PKI 系统并行而已，然而这和要不要自己加密有什么关系？ |
 |
48
paradoxs 2017-05-05 15:44:46 +08:00
不加密的话, 用 Mitm 不就能看到你 POST 数据包的结构了?????????
我惊讶了. 难道这个不是问题? |
 |
49
wangxiyu191 2017-05-05 15:46:19 +08:00
@zealot0630 前端 hash 可以一定程度上保证就算服务器被攻陷，用户的密码明文不会泄露。这个意义在于，如果用户在其他网站使用了同样的密码，不至于被撞库。
|
|
50
lovedebug 2017-05-05 15:54:35 +08:00
@ryd994 没有讨论加密，只是陈述下目前证书存在的问题和解决方案。OCSP 除了 revoke 也是在证书过期时发布，可惜浏览器不是时刻都查 OCSP 的，存在缓存或者使用 CRL，中间有一个空档期。
各大 CA 在自己家加的是 Audit Log, 谷歌强推的是 CT log，虽然还是在 beta 中。 |
|
51
lovedebug 2017-05-05 15:57:22 +08:00
@ryd994 双向认证客户端证书签发者不一定是公开的 CA，只要服务器端将客户端的签发证书置于自己的 truststore 中就能完成部署。
|
 |
52
taozhijiangscu 2017-05-05 15:58:17 +08:00
通常 HTTPS 就不用了，不过很多重要数据会做签名。
|
|
53
ryd994 2017-05-05 15:58:18 +08:00
@tony1016 你的视频给的不是 gmail
我找了 gmail 视频，用的 IE6 吧那是？ facebook HSTS bypass 那部分我也找了，这不就是 includeSubdomains 的作用么？ 而且，这和不要自己加密有什么矛盾么？ HTTPS 不能解决的问题，凭什么自制的宇宙无敌加密协议能解决？ 能破 HTTPS 就能破各种自己的加密：挂个 javascript，把密码框复制一份就好了，随你怎么加密。 |
|
55
ryd994 2017-05-05 16:03:23 +08:00
@lovedebug 我说的是服务器一定会检查客户端证书，这和你说的 truststore 不矛盾，truststore 本质上是预分发的证书 pinning
我不同意的是 “公钥通过服务器的公钥加密后交还给了服务器”和“由于公钥不是众所周知的，相对安全不少” 公钥不需要用服务器公钥加密也是一样，在长度和算法一样的前提下，安全性没有本质上的区别 公钥是不是众所周知也和安全性无关，要是知道公钥会降低安全性的话，应该先质询一下用的非对称算法 |
|
56
ryd994 2017-05-05 16:06:40 +08:00
@lovedebug 证书或是单纯 RSA，本质上都是一样的，就是可信硬件。
我还见过自带键盘的智能卡读卡器，同样的，也有（好像是工行吧） U 盾自带按键和显示屏，显示屏显示单号金额，确认按键。这都是可信硬件。和浏览器加密完全不是一个范畴。 该上该硬件的上硬件，不要用浏览器加密自欺欺人 |
|
57
lovedebug 2017-05-05 16:09:50 +08:00
@ryd994 同意你的看法。 公钥众所众知是对单向的访问意义更大。双向访问客户端的证书被众所周知就意义不大了。前一句 “公钥通过服务器的公钥加密后交还给了服务器” 是完成证书交换时做的，描述的不合适。应该是服务器讲自己的证书给客户端并要求客户端提供证书以用于验证。公钥的安全性看是 SHA1 还是 SHA2 了，SHA1 已经不安全了
|
|
58
lovedebug 2017-05-05 16:12:52 +08:00
@ryd994 浏览器加密本身就是伪命题，TLS 协议安全就安全，除非能互相协商出加密的算法，oracle 还是 IBM 好像有加密的软件，带来的问题是这个加密的密钥怎么传递
|
 |
59
Quaintjade 2017-05-05 16:26:13 +08:00
@ryd994
现在国内银行的网银插件也开始转变了吧，主要只是安装 U 盾的驱动和添加国产根证书。 至于为什么要用 U 盾而不是直接依赖系统证书，我想一方面是用户系统可能被安装其他根证书，另一方面可能是所谓“国家金融安全”的考虑。 毕竟事实上现在客户端上的证书体系是由 Google,Mozilla,MS,Apple 等国外机构主导的，算法也是国际组织提出和审核的，而且出现过试图加塞带后门曲线的事情。所以国内做的事情是使用国产算法（虽然原理上和 ECC 之类类似），但协议设计仍参照公开的行业标准（例如 X.509 ）。至于有没有意义就另说了。 |
|
60
ryd994 2017-05-05 16:41:49 +08:00
@lovedebug TLS 其实是整个流程的抽象化，任何一个环节都可以替换。比如加密算法，比如证书验证。协议上 psk 也是可以的，虽然没人用罢了。自己发明一套无非再造轮子。很多人没这个能力。
@Quaintjade U 盾参见我上面说的可信硬件。硬件和浏览器加密完全是两回事。U 盾密钥不存在与内存，除非硬件设计失误，否则密钥根本不可能泄露。如果是配合硬件的浏览器加密，我放心。 国产算法不是指的国密吧？双证书体已经成为笑话了。内裤上交国家，一百个放心呢。 加后门的是 openssl 的实现，算法是可靠的，实现出了问题。国产加密，用户量不够，时间太短，问题只会更严重。 算法和协议谁发明的不重要，都是公开发过论文的，有问题的迟早要被捅出来的。 |
 |
61
hoythan 2017-05-05 17:34:25 +08:00
...一般密码是不走的吧?token 机制这么难吗?
|
|
62
Quaintjade 2017-05-05 17:48:39 +08:00
@ryd994
我指的就是国密，并不是说这种做法是对的，只是提一下这么做的理由。就是国家想让你把内裤上交国家，不要不知不觉交给了外国。 加后门的算法指的是 Dual_EC_DRBG。 有问题迟早被捅出来，问题是“迟早”是什么时候？ 1 个月？ 1 年？ 10 年？ Dual_EC_DRBG 被发现是因为疑点太多，然而如何确保 NSA 没有更加精心设计的后门？ |
|
64
ryd994 2017-05-05 18:05:13 +08:00
@Quaintjade 不会啊……用 PKI 提交签名的是 csr，没有上交内裤。比起主动主动上交，我还是选择拒绝一下，那个……呃……矜持，矜持。
OpenSSL 实现都是公开的好么？大家这么多年都没能看出来，那只能说明 NSA 水平高。这是 NSA 的技术水平单挑世界安全人士的水平啊。人家挑的过，有什么办法。 真理部水平够的话，怎么不去给 OpenSSL 提交代码啊？开源软件谁知道网络对面是不是人。说人家歧视中国人的，取个外国名字用外国邮箱，后门不也能插进去么。 国密自己闭门造车实现一套就能比众目睽睽的开源软件更好？呵呵 不能保证 NSA 没有更复杂的后门，难道就能保证国密没有了？哦，不需要，公开的后门嘛。 比起人家 NSA 插个后门还要偷偷摸摸还会被爆出来，国密直接公开插入，根本不怕被爆出来，真是高明。 且不说，上交的内裤给谁拿去了还不好说呢。现在已经有实名制资料拿出来卖的了。都是内鬼在干。 我的内裤就是我的内裤，谁的别想碰，包括国家。 |
|
65
Quaintjade 2017-05-05 18:09:32 +08:00
@Quaintjade
再举个例子：差分分析攻击（ Differential cryptanalysis ）在 90 年代被公开发表，然而实际上 DES 在 70 年代被设计时，研究人员就已经发现了这种攻击方法，然后被 NSA 要求严格保密。也就是说过了 20 年才被重新被人发现。 https://en.wikipedia.org/wiki/Data_Encryption_Standard#NSA.27s_involvement_in_the_design 所幸的是 NSA 建议了 S-Box 来抵抗差分攻击，而不是买通研发人员保留这漏洞。 |
 |
66
SuperFashi 2017-05-05 18:19:05 +08:00 via Android
一般要是加密的话应该是 https 里再用 rsa 来加密一下密码。
|
 |
67
ghostheaven 2017-05-05 18:22:13 +08:00 via Android
在服务端禁用不安全的协议和算法，时刻关注安全相关新闻，这样就足够了。额外的加密没有价值，一个普通的网站 NSA 才不会有兴趣，一般黑客也破解不了 https 协议。再说，一个用户被装了不安全的 ca 也影响不了全站其它用户，要赔偿也就赔他一个人。
|
|
68
Quaintjade 2017-05-05 18:37:02 +08:00 via Android
@ryd994
你说的是实现，我说的是算法本身。 实现里加塞的后门容易发现，算法里加塞的后门就不一定了，所以实现的设计上基本可以搬抄，算法得自己搞。 自己搞有没有漏洞对国家并不重要，只要中国比外国先知道漏洞就行，因为本来的目的就不是保护你的内裤不暴露给所有人，而是不让(可能地)暴露给国外。 至于算法加塞后门，我想说连 NSA 都能做，中国当然也做得到。想想王小云 2005 年提的针对 SHA-1 的 2^63 次攻击，2017 年 Google 实际碰撞时还是这个数量级。 |
 |
69
firefox12 2017-05-05 19:28:59 +08:00 via iPhone
前端加密也不是完全不可取。最早的做法 md5 连续做 30 次 再和网页的里一个变量做一个 md5。安全性也是不低的。服务器里寸的是密码 md5 30 次
|
 |
70
tt0411 2017-05-05 19:45:28 +08:00
大多数场景没有必要
|
|
71
ryd994 2017-05-05 19:49:06 +08:00 via Android
@firefox12 这属于智障加密协议
黑客中间人把你 md5 30 次的结果直接抄下来，下次绕过你的网页，直接伪造请求就好 在任何情况下，都不要相信客户端，服务器收到的数据才是客户端的验证信息。因为客户端请求总是有办法伪造，即使套了 https |
 |
72
czb 2017-05-05 22:09:51 +08:00 via Android
@mcspring 你没有理解非对称加密 CA sign 的是你的 public key, public key 本来就是可以公开的, CA endorsement 这个签署过程从来就没有你的 private key 出现过，所以只有你一个人才能解密通过你的 public key 加密的内容。
|
|
73
firefox12 2017-05-05 22:41:17 +08:00 via iPhone
@ryd994 仔细看看 黑客看不到 30 次 hash 的结果。他只能看到一个 hash 加随机后的结果。没有虹表以前还是安全的。有了虹表 把和随机数的加密次数加大，每次都加随机数还是安全的
|
 |
74
bugmenot3 2017-05-05 23:53:49 +08:00
一般来说，没有必要多此一举（字面意思）。
但是也有应用场景，比如端到端加密。 |
 |
75
nlimpid 2017-05-06 01:19:27 +08:00
没意义。以登录为例，难道不是直接传明文帐号密码给服务端校验么？
|
 |
76
breeswish 2017-05-06 01:24:00 +08:00
客户端 hash 在 https 场景下是没有意义的。如果已经能进行 https 降级攻击了，那么顺便插一段脚本监听你文本框的输入又有何难？
|
 |
77
hyuwang 2017-05-06 03:39:21 +08:00
本地加密并不是全无意义
比如 heartbleed 或者上次 cloudflare 那种问题 |
|
78
ryd994 2017-05-06 05:04:57 +08:00 via Android
@firefox12 黑客根本不 care 原密码是什么你懂么？
伪造请求就可以了，重放攻击 更何况没有证书链的情况下，随便中间人，查个 JavaScrip 钩子什么都看得到。这不是玩笑，而是真实案例： http://www.williamlong.info/archives/3658.html 而且提出这样的算法说明你对 hash 完全没有理解 hash 是值域小于定义域，因此 hash(hash(x))的值域一定小于 hash(x)。而且继续 hash 下去值域只会继续见效。会不会收敛到单一值我不知道，但 hash30 次的值域肯定大不了。 值域小有什么问题？碰撞啊，要是值域只有一个值的话不就是百分百碰撞了么？不用黑客搞你，你自己就把自己搞死了 |
|
80
firefox12 2017-05-06 07:54:29 +08:00 via iPad
@ryd994 这里的防御当然指的是防御窃听攻击。arp 攻击。重放攻击在这里没效果，每次使用都会有随即字符串，攻击不了。
hash30 次的值域 ，只是简单的对抗最简单的虹表，hash 的值域也足够大，对于普通攻击者足够。 ssl 号，但是证书的发放才是大问题。赛门铁克被 google 吊销了证书，因为他发了 google 的一天证书，这种攻击才是更可怕的。你一点办法都没有。 |
 |
81
twl007 2017-05-06 08:09:12 +08:00 via iPhone
https 只是保证传输过程中加密而已 并不是加密数据 只是加你不要传输的数据 如果后台需要数据加密那还是要去再加密一次
|
 |
82
pimin 2017-05-06 09:26:09 +08:00 via Android
|
|
83
Quaintjade 2017-05-06 13:31:18 +08:00 via Android
@firefox12
你用的是哈希算法，而非可逆加密算法，随机字符串有何意义？ 你这次发了个随机字符串 salt1 给用户，用户返回给你连同密码哈希后的 h1，你存下来。下次用户登录时你不是还得发给用户这个 salt1，然后用户返回给你 h1 吗？ 既然如此，中间人直接返回给你 h1 就能登录了。 |
|
84
firefox12 2017-05-06 16:35:23 +08:00 via iPhone
@Quaintjade 谁告诉你的？每次操作服务器都随机一个 slat 服务器是保存原始密码 hash30 次的结果。这个随机数就是保证了 你重放是没效果的。你用上次的 slat 出来的结果 服务器一比较不一样 直接拒掉了。
|
 |
85
caola 2017-05-06 18:04:18 +08:00
如果想做得足够安全，可以考虑：
HTTPS + HSTS preload + OCSP + HPKP + DNSSEC + QUIC(可选) 如果还要在内容上加密，可以考虑 php 的 mcrypt 加密后用于接口的数据传输。 接收端就解密就行了。 |
 |
86
Hardrain 2017-05-09 11:34:46 +08:00
如果是前端则不必要
如果是后端(服务器(数据库)存储的敏感信息)还是有必要的 |
Select Language