这是一个创建于 4299 天前的主题，其中的信息可能已经有所发展或是发生改变。
幾個問題：
1、涉及登錄密碼仍然用HTTP，是否不夠安全？
2、如果手動輸入HTTPS網址，Chrome會出現安全警告，是否是沒有購買證書所致？
1、涉及登錄密碼仍然用HTTP，是否不夠安全？
2、如果手動輸入HTTPS網址，Chrome會出現安全警告，是否是沒有購買證書所致？
 |
1
qinix 2013-02-04 23:36:57 +08:00 via Android
没必要吧
|
 |
2
qq286735628 2013-02-05 00:03:24 +08:00
传送过程被侦听了也没啥事，又不是什么敏感信息....
网络安全中的攻防都是建立在成本上的... 没价值的东西，黑客不会花成本去窃取... 没价值的东西，客户也没必要去花费额外的成本去保护... |
 |
3
ihacku 2013-02-05 00:18:02 +08:00
2是因为证书是这个子站点的 https://workspace.v2ex.com/
1请参见/t/59436 |
 |
4
atsivsucks OP @qq286735628 你的V2EX登陆密码是不是敏感信息？
|
 |
5
Livid MOD 我们会尽快加上的。谢谢提醒。
|
|
6
qq286735628 2013-02-05 00:34:01 +08:00
@atsivsucks 我的意思是
如果你觉的帐号值得使用ssl来保护，如果@livid 觉得V2EX上面的用户密码有被监听的风险、且带来的危害很大，那就很有必要采取ssl等保护措施，提高攻击者的攻击成本，让攻击者先掂量掂量再作决定。 其实你觉得V2EX的登录密码是敏感信息的，完全可以采用另外一套密码，别和自己的金融帐号密码重复就好呀。 有很多更省的方式的，并且ssl也不是万能，如果你的密码真值那么多钱，攻击者有其他方式的。 |
|
7
Livid MOD @qq286735628 对，最安全的做法，就是为每个网站使用一个独特的密码。对自己的邮箱使用最高级别的，不和任何其他地方重复的密码。
|
|
8
atsivsucks OP @qq286735628 SSL确实不万能，不过除了中国内地的网站，要密码却不用SSL的网站我还没有见过，不知道你能不能给我找出两个看看？先谢了
“有很多更省的方式的”，网站制作者“省”，用户麻烦，什么逻辑？之前CSDN明文密码泻露，那责任是不是在用户不应该注册这种不靠谱的网站？而不是CSDN应该保障用户的安全？ |
 |
9
chrisyipw 2013-02-05 15:16:53 +08:00  1
@atsivsucks CSDN 「明文密码」泄漏和 HTTPS 并没有关系，前者泄漏是网站自身的，1）密码没混淆，2）服务器安全措施没做好；而 HTTPS 只是在用户的机器到服务器之间建立相对安全的通道，并没有解决前两个问题（一样会密码泄漏）。
在做好密码混淆、服务器防黑的情况下，用户在 HTTP 登录的时候密码被截获，这属于用户的问题，比如你在公共咖啡厅上网，任何一个网络服务都没有办法也不可能去为用户的上网环境负责，能做的只是像提供 SSL、安全令牌等「辅助服务」，但并不是「义务」。 BTW，CSDN 的不靠谱不是密码泄漏、不是没用 HTTPS，是明文储存，如果一个网站能把你的密码混淆到即使获得了，也不会影响到你别的帐号，就足够靠谱了，是不是 HTTPS 没关系。毕竟程序是人写、机器是人搭，漏洞难免。 PS：要密码却不用 SSL 的，比如 Google Reader 就不是强制 SSL 访问。 |
 |
10
keakon 2013-02-05 15:30:23 +08:00
@chrisyipw 登录时需要输入密码，这个时候是强制 HTTPS 的。登录完可以不用安全连接，此时 cookie 是存在泄露风险的，但影响不大。
|
|
12
qq286735628 2013-02-05 23:03:31 +08:00
@atsivsucks 你没明白我的意思，当我没说吧~
我赞同你说的，给网站部署ssl，加强安全性，这也是SPDY草案里面的一条，未来HTTP协议发展的趋势。 |
 |
13
luikore 2013-02-06 00:26:42 +08:00
还有个问题: cookie 没设置成 http only ...
如果 session 打劫链接能全部 escape 掉的话应该问题不大, 试试: <a href="javascript:document.location='http://v2ex.com?'+document.cookie">steal your cookie</a> |
 |
14
no2x 2013-02-06 03:49:27 +08:00
探讨一下。
如果没有 SSL 而换一个简单的做法，在 前端 直接用 javascript 去 md5/sha1 加密密码（还可以加入令牌效果的会话验证），然后传输到 后端 配对。是否会相对安全呢？至少，减少了泄露明文。 @Livid @qq286735628 @chrisyipw |
|
15
chrisyipw 2013-02-06 05:24:24 +08:00
@no2x 客户端 hash 与否不影响客户端泄密的成功率，因为加密密码常见手法是 hash + salt，salt 相关的算法不被泄漏，即使拿到完整数据库也无从得知真实密码。而客户端不管是什么，都可能被截获，什甚至看源码就知道你是 md5 还是 sha1，现在 GPU 计算那么强大，算出对应的字符串成本还算低的。
我想过一个客户端加密方案，就是随机布局的虚拟键盘，而且键值也是随机的，比如点击 a 时不是返回 "a"，而是一个值的 key，服务器收到后，再转换成对应字符，这样的话要获取明文密码就只能获取点击时的字符（如截图）或算法。这样似乎不需要 SSL 也行（没真正部署过 |
|
16
no2x 2013-02-06 15:08:46 +08:00
@chrisyipw 你这个做法跟我的类似，更复杂一点而已，但也仅仅是避免直接泄露明文。SSL 的主要作用在于数据流的加密传输，保证不会被截取窃听及伪造。
|
|
17
atsivsucks OP @chrisyipw Google的登錄頁面從來都是HTTPS啊，不知道Google Reader有何特別？
|
Select Language