Firefox将以HTTP明文发送密码的网站标注为不安全

oschina
 oschina
发布于 2015年10月22日
收藏 8

最新的Firefox Nightly版本中出现了一项较大的改变,这对web世界而言可能也是向前迈进的重要一步。这一版Firefox浏览器将那些展示密码字段,但不以 HTTPS协议发送密码的网站标注为不安全。地址栏会出现一个锁划了一道杠的标志,用于警告用户若发送证书则可能会不安全。

http://static.cnbetacdn.com/article/2015/1021/743128a5f9e4a73.png

如果点击这个图标,Firefox还会提供更多关于将这样的站点标注为不安全的信息,提到“通过该网站发出的信息未经过加密,可能被其他人监视”。

这对浏览器而言,只是个简单的变化,但却具备了较大的意义,先前不安全的标签只对那些无效安全证书的站点做标注,这么一来,想必会有更多的站点注意安全性问题。

当前这项特性仅在Firefox 44 Nightly版本中测试,未来应该会在正式版中普及开。

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:Firefox将以HTTP明文发送密码的网站标注为不安全
加载中

最新评论(35

zqq90
zqq90

引用来自“李嘉图”的评论

草,密码竟然明文传送,你就是Base64一下也好呀?

引用来自“黄冠能”的评论

base64是没有意义的,有心监听密码的人见到传输密码的页面不是HTTPS就知道一定能破。而且这些小动作都是JS做的,一眼就能看出加密的算法。

引用来自“webit”的评论

你觉得这样可以破么
1. 每次传输 服务器分发一个随机 token,一个公钥
2. token 每次不重复(很重要)
3. 密码+token 简单混合 然后 公钥加密
4. 服务器 私钥解密 然后剔除 token
4+. 服务器剔除的token来自于session(或类似可信来源) 而不是 cookies或是表单等其他不可信来源(重要性等同 point 2)

引用来自“黄冠能”的评论

你都用了公私钥了,就不是单纯的base64啦。你搞这一套,就相当于自己实现HTTPS,有必要费这个劲吗?搭HTTPS不是更省事吗?

请问你的第3步怎样加密?你是认为用把密码、token、公钥base64一下就是加密了呢?如果是的话,你恐怕要了解一下什么是对称加密,什么是非对称加密。用公钥进行对称加密是没有用的。如果不是的话,你的方案和base64有什么关系?

引用来自“webit”的评论

第三步 虽然不加盐加密之后的报文也会不同, 是为了防止 发重复的 报文依然有效,加随机盐之后,保证了这点,
这里举个例子,某接口宣称自己的接口注重安全, 说“你把密码MD5之后在发送”, 我就想问了 只要搞到你MD5 之后的 不就可以用了么,不需要知道原密码(PS:且不说MD5撞库难度)

然后 根据特殊条件/场景限制 有时候HTTPS 是有难度的,这里仅作给定HTTP下的讨论

再举个实际例子, 上学的时候给学校做网站,宿舍大家庭你是知道的, 盗舍友各种密码,浏览记录是多么容易的一件事情,但是学校网络中心说了 “不提供HTTPS, MYSQL只有5.1,不提供5.5,...., ” 没办法。。。

引用来自“黄冠能”的评论

我不明白你为什么突然把问题扯到了salt,之前并没有讨论salt。

把密码用MD5加密是在服务端保存非明文密码时做的,而不是前端做的。如果是前端做,就需要使用公钥私钥配合。也就是说,如果你的方案是用MD5对原始密码和公钥进行加密传送,在服务器端利用私钥还原原始密码,那么是安全的。这基本就是HTTPS的原理。如果你说用base64,就是不安全的,如果你有网站用base64加密,不妨拿出来,我破给你看。

你的方案可以增加破解难度,让只懂监听、其它什么都不懂的人难以破解,但本质上是不安全的(除非你使用MD5,不过从你上面的评论来看,我觉得你有些基本原理没有搞懂)。你有这个心思去做校园网站很好,但不要把这个拿出来做可能引起黑客注意的商业网站。
你这么说我也是醉了 例子是例子 只是说明一下 场景的可能
另外讨论的 还是之前说的 那种方式, 只不过是你理解错了,或者说我表达方式有问题
既然 不在一个频率上 (我曾试图按照你的频率来说明问题)那就没啥好继续的了
黄冠能
黄冠能

引用来自“李嘉图”的评论

草,密码竟然明文传送,你就是Base64一下也好呀?

引用来自“黄冠能”的评论

base64是没有意义的,有心监听密码的人见到传输密码的页面不是HTTPS就知道一定能破。而且这些小动作都是JS做的,一眼就能看出加密的算法。

引用来自“webit”的评论

你觉得这样可以破么
1. 每次传输 服务器分发一个随机 token,一个公钥
2. token 每次不重复(很重要)
3. 密码+token 简单混合 然后 公钥加密
4. 服务器 私钥解密 然后剔除 token
4+. 服务器剔除的token来自于session(或类似可信来源) 而不是 cookies或是表单等其他不可信来源(重要性等同 point 2)

引用来自“黄冠能”的评论

你都用了公私钥了,就不是单纯的base64啦。你搞这一套,就相当于自己实现HTTPS,有必要费这个劲吗?搭HTTPS不是更省事吗?

请问你的第3步怎样加密?你是认为用把密码、token、公钥base64一下就是加密了呢?如果是的话,你恐怕要了解一下什么是对称加密,什么是非对称加密。用公钥进行对称加密是没有用的。如果不是的话,你的方案和base64有什么关系?

引用来自“webit”的评论

第三步 虽然不加盐加密之后的报文也会不同, 是为了防止 发重复的 报文依然有效,加随机盐之后,保证了这点,
这里举个例子,某接口宣称自己的接口注重安全, 说“你把密码MD5之后在发送”, 我就想问了 只要搞到你MD5 之后的 不就可以用了么,不需要知道原密码(PS:且不说MD5撞库难度)

然后 根据特殊条件/场景限制 有时候HTTPS 是有难度的,这里仅作给定HTTP下的讨论

再举个实际例子, 上学的时候给学校做网站,宿舍大家庭你是知道的, 盗舍友各种密码,浏览记录是多么容易的一件事情,但是学校网络中心说了 “不提供HTTPS, MYSQL只有5.1,不提供5.5,...., ” 没办法。。。
我不明白你为什么突然把问题扯到了salt,之前并没有讨论salt。

把密码用MD5加密是在服务端保存非明文密码时做的,而不是前端做的。如果是前端做,就需要使用公钥私钥配合。也就是说,如果你的方案是用MD5对原始密码和公钥进行加密传送,在服务器端利用私钥还原原始密码,那么是安全的。这基本就是HTTPS的原理。如果你说用base64,就是不安全的,如果你有网站用base64加密,不妨拿出来,我破给你看。

你的方案可以增加破解难度,让只懂监听、其它什么都不懂的人难以破解,但本质上是不安全的(除非你使用MD5,不过从你上面的评论来看,我觉得你有些基本原理没有搞懂)。你有这个心思去做校园网站很好,但不要把这个拿出来做可能引起黑客注意的商业网站。
zqq90
zqq90

引用来自“李嘉图”的评论

草,密码竟然明文传送,你就是Base64一下也好呀?

引用来自“黄冠能”的评论

base64是没有意义的,有心监听密码的人见到传输密码的页面不是HTTPS就知道一定能破。而且这些小动作都是JS做的,一眼就能看出加密的算法。

引用来自“webit”的评论

你觉得这样可以破么
1. 每次传输 服务器分发一个随机 token,一个公钥
2. token 每次不重复(很重要)
3. 密码+token 简单混合 然后 公钥加密
4. 服务器 私钥解密 然后剔除 token
4+. 服务器剔除的token来自于session(或类似可信来源) 而不是 cookies或是表单等其他不可信来源(重要性等同 point 2)

引用来自“黄冠能”的评论

你都用了公私钥了,就不是单纯的base64啦。你搞这一套,就相当于自己实现HTTPS,有必要费这个劲吗?搭HTTPS不是更省事吗?

请问你的第3步怎样加密?你是认为用把密码、token、公钥base64一下就是加密了呢?如果是的话,你恐怕要了解一下什么是对称加密,什么是非对称加密。用公钥进行对称加密是没有用的。如果不是的话,你的方案和base64有什么关系?
另外,盗 cookies 这事儿。。。没办法。。
zqq90
zqq90

引用来自“李嘉图”的评论

草,密码竟然明文传送,你就是Base64一下也好呀?

引用来自“黄冠能”的评论

base64是没有意义的,有心监听密码的人见到传输密码的页面不是HTTPS就知道一定能破。而且这些小动作都是JS做的,一眼就能看出加密的算法。

引用来自“webit”的评论

你觉得这样可以破么
1. 每次传输 服务器分发一个随机 token,一个公钥
2. token 每次不重复(很重要)
3. 密码+token 简单混合 然后 公钥加密
4. 服务器 私钥解密 然后剔除 token
4+. 服务器剔除的token来自于session(或类似可信来源) 而不是 cookies或是表单等其他不可信来源(重要性等同 point 2)

引用来自“黄冠能”的评论

你都用了公私钥了,就不是单纯的base64啦。你搞这一套,就相当于自己实现HTTPS,有必要费这个劲吗?搭HTTPS不是更省事吗?

请问你的第3步怎样加密?你是认为用把密码、token、公钥base64一下就是加密了呢?如果是的话,你恐怕要了解一下什么是对称加密,什么是非对称加密。用公钥进行对称加密是没有用的。如果不是的话,你的方案和base64有什么关系?
第三步 虽然不加盐加密之后的报文也会不同, 是为了防止 发重复的 报文依然有效,加随机盐之后,保证了这点,
这里举个例子,某接口宣称自己的接口注重安全, 说“你把密码MD5之后在发送”, 我就想问了 只要搞到你MD5 之后的 不就可以用了么,不需要知道原密码(PS:且不说MD5撞库难度)

然后 根据特殊条件/场景限制 有时候HTTPS 是有难度的,这里仅作给定HTTP下的讨论

再举个实际例子, 上学的时候给学校做网站,宿舍大家庭你是知道的, 盗舍友各种密码,浏览记录是多么容易的一件事情,但是学校网络中心说了 “不提供HTTPS, MYSQL只有5.1,不提供5.5,...., ” 没办法。。。
黄冠能
黄冠能

引用来自“李嘉图”的评论

草,密码竟然明文传送,你就是Base64一下也好呀?

引用来自“黄冠能”的评论

base64是没有意义的,有心监听密码的人见到传输密码的页面不是HTTPS就知道一定能破。而且这些小动作都是JS做的,一眼就能看出加密的算法。

引用来自“webit”的评论

你觉得这样可以破么
1. 每次传输 服务器分发一个随机 token,一个公钥
2. token 每次不重复(很重要)
3. 密码+token 简单混合 然后 公钥加密
4. 服务器 私钥解密 然后剔除 token
4+. 服务器剔除的token来自于session(或类似可信来源) 而不是 cookies或是表单等其他不可信来源(重要性等同 point 2)
你都用了公私钥了,就不是单纯的base64啦。你搞这一套,就相当于自己实现HTTPS,有必要费这个劲吗?搭HTTPS不是更省事吗?

请问你的第3步怎样加密?你是认为用把密码、token、公钥base64一下就是加密了呢?如果是的话,你恐怕要了解一下什么是对称加密,什么是非对称加密。用公钥进行对称加密是没有用的。如果不是的话,你的方案和base64有什么关系?
灵魂架构师
灵魂架构师
绿坝表示准备卷土重来!
李嘉图
李嘉图

引用来自“李嘉图”的评论

草,密码竟然明文传送,你就是Base64一下也好呀?

引用来自“黄冠能”的评论

base64是没有意义的,有心监听密码的人见到传输密码的页面不是HTTPS就知道一定能破。而且这些小动作都是JS做的,一眼就能看出加密的算法。

引用来自“webit”的评论

你觉得这样可以破么
1. 每次传输 服务器分发一个随机 token,一个公钥
2. token 每次不重复(很重要)
3. 密码+token 简单混合 然后 公钥加密
4. 服务器 私钥解密 然后剔除 token
4+. 服务器剔除的token来自于session(或类似可信来源) 而不是 cookies或是表单等其他不可信来源(重要性等同 point 2)
mark,以后或许会用到.国内有些就是加密做的不好.
zqq90
zqq90

引用来自“李嘉图”的评论

草,密码竟然明文传送,你就是Base64一下也好呀?

引用来自“黄冠能”的评论

base64是没有意义的,有心监听密码的人见到传输密码的页面不是HTTPS就知道一定能破。而且这些小动作都是JS做的,一眼就能看出加密的算法。
你觉得这样可以破么
1. 每次传输 服务器分发一个随机 token,一个公钥
2. token 每次不重复(很重要)
3. 密码+token 简单混合 然后 公钥加密
4. 服务器 私钥解密 然后剔除 token
4+. 服务器剔除的token来自于session(或类似可信来源) 而不是 cookies或是表单等其他不可信来源(重要性等同 point 2)
zqq90
zqq90

引用来自“李嘉图”的评论

草,密码竟然明文传送,你就是Base64一下也好呀?

引用来自“黄冠能”的评论

base64是没有意义的,有心监听密码的人见到传输密码的页面不是HTTPS就知道一定能破。而且这些小动作都是JS做的,一眼就能看出加密的算法。

引用来自“李嘉图”的评论

至少第一眼看不懂!你要是明文,第一眼就看懂了!哈哈
是不是Base64 一眼就能看出来 Base64 和 UTF8 一样,是"编码"过程 不是"加密/签名/指纹"等概念
人生能绕几个圈
人生能绕几个圈

引用来自“linux工人”的评论

很有用啊,不向恶势力低头
firefox是真开源,而chrome的身后却是Google
返回顶部
顶部