《网站用户口令处理安全性测评报告》的一些不专业地方 ——引用自（kussa的）百度空间

《网站用户口令处理安全性测评报告》的一些不专业地方

2012-06-03 9:40

最近看到一个《网站用户口令处理安全性测评报告》（http://news.ccidnet.com/art/11809/20120529/3899193_1.html），里面提到“被测网站中仅有15个网站对用户口令做了hash，其余的85个网站均可在服务器端直接或解密后，获取用户口令原文。从网站类型来看，电子商务类、招聘类、婚恋类网站普遍没有将用户口令进行形态变化的安全意识……”这样的报道被不少媒体转载和解读。报告中有个非常不专业的地方真是让我大跌眼睛，有些话不吐不快。   对“原始口令明文传输”的指控这个无可厚非，谁这么用了谁对不起用户。   但我主要针对里面提到的所谓“原始口令加密传输”，这明明是最标准最安全也最通用的口令传输方式，却被莫须有的罪名，得到“电子商务类网站中没有一个网站采取了最安全的用户口令处理模式”的结论。   我们看看在使用加密隧道的情况下，报告的作者（以下简称作者）认为应该怎么做呢？   建议网站使用“口令hash+加密信道”的“口令散列值加密传输”模式 用户口令认证过程的通信，应采用加密信道进行传输，或将关键数据加密后才能在常规信道中传输； 服务器只应存储用户口令的散列值，而不能存储口令原文或可解密的口令密文； 尽量在口令信息传输前就进行单向散列处理，而不是传输到服务器上再进行处理；   罗罗嗦嗦背景交代完毕，我来反驳：   结论：作者的观点犯了一个在登录设计上常见的错误，按照作者的方式设计的登录方案恰恰是有安全隐患的。我来细致阐述一下这个的来龙去脉，争取做到没技术背景的人都能看懂：   1.首先，用户登录就要把登录凭证（密码信息、更准确说应该是口令信息）提交到网站，网站判断是否用户提交的正确，来确定是否让这个用户登录。   2.这样有了密码信息就能替这个用户登录了，所以这个信息非常敏感。   3.在用户像网站传递密码信息时，显然不能传明文密码，否则被监听了就悲剧了，需要加密传输（否则就是作者提到的“原始口令明文传输”）。   4.加密传输的方式就是用SSL在网络上建立一个加密隧道（这个隧道在传递网页请求时被称作HTTPS），用户把数据放入这个隧道，在传输之前就会被自动加密，然后密文经过网络（没法被解密）传输，到达网站，再被自动解密恢复成明文进行密码比对。   5.但是在加密隧道中，该传递什么呢？既然功能上是用户把密码信息传递给网站，而隧道又是安全的，那用户就可以把密码直接放到隧道中传输。   6.有一些人对第5条表示反对，认为即使在隧道里，也应该传加密或者变化的信息，而不应该直接传密码。这也是作者在上面的主张。   7.所谓密码校验，就是拿用临时提交的密码信息和咱们持久存储的密码信息做比对，这里不可避免的涉及到一个临时提交和网站的持久存储。   8.最会造成问题的其实是网站持久存储密码这事，用户会担心网站的工程师可以看到存储下来的密码信息，然后拿着这些密码信息再以用户的身份登录。   9.而实际上已经有非常好的方案来消除用户这个顾虑，网站存储的是密码的哈希变换，即用户的密码是p，网站存储的是h=hash（p），这里的hash函数是单向不可逆的，任何人只能从p算出h，不能从h算出p，这样即使是内部人员，看到的也是h，即使网站数据库被泄漏到外面，攻击者也只能看到h，都不能恢复出p来（优快云就是没做好这些，存的明文密码，导致数据库丢失后，攻击者可以直接拿到登录凭证，大量用户隐私泄漏）。   10.在做密码校验时，用户提交的密码信息从加密隧道中解出后，直接进入到处理程序，程序会对接收的密码在算一遍哈希，h‘=hash（p')，然后比对h'和h，就可以看出用户提交的密码是否正确了，整个过程没有人的参与，用户的密码在处理过程中只是程序里临时出现的一个变量而已，专业的互联网公司有义务禁止使用任何方法将这个临时值传出程序以外或者记录下来。   11.一些人主张在隧道里应该传递的是密码哈希(h)而不是密码明文，然后校验的时候拿这个h去和库里的比对。但这恰恰是错误的，因为我们存的是h，用户传的是h，那这个h就成了p了。一旦h泄漏，就可以通过这个接口把h传递到网站，然后成功通过校验。而现在，我们不接受h只接受p，攻击者又不能从我们存储的h中恢复出p，这样才是安全的。如果“存哈希值、传原文”，那么“原文”才是登录凭证，哈希值不是，就不涉及到保存登录凭证的事情（传递登录凭证是一定要的，否则就不叫登录了），反过来如果“传哈希、存哈希”，就相当于网站在存登录凭证了，那么优快云的事情同样会出现在使用这样方案的网站上。   12.那用户传h=hash(p)，后台存储i=hash(h)可以吗？可以，但没意义，这样h就是上面的p，i就是上面的h，还是相当于在隧道中传输明文密码，更准确的说还是相当于在加密隧道中传递原始登录凭证。   13.除了传递hash，在隧道中对登录凭证加密是不是有意义呢？一方面，加密之前的信息在登录校验时还是要被网站反解的，“原始口令加密传输”下能得到的这种方式下照样能得到，再加密相当于穿两层内裤，没有任何实质意义；另一方面，和12一样，加密后的数据才是登录凭证，这样仍然是直接在加密隧道传递登录凭证，和所谓的“原始口令加密传输”没有区别。   14.上面的处理方法是几乎成了工业规范，不止国内的网站，google、yahoo、facebook等都是这样直接在隧道中传递密码明文的，我很想看看作者怎样点评国外的网站的，或者解释下这些网站出于什么目的这么一致的选择作者认为不安全的传输方式。   一些额外的:   15.有些网站给用户的登录接口都是的HTTPS的，也支持未加密的HTTP链接，除非用户使用hack手段故意让自己的密码明文发给网站，否则都会走加密隧道的。这样的设计在我看来可以改进，但算不上安全问题。   16.有些网站不是使用标准的SSL隧道，而是自己实现加密隧道，甚至加密算法、协议都是自己定义并保密的。这样在外行看上去更安全，但“经过保密的由几个工程师设计并实现的加密方法”和“公开的，经过大量专家设计并被公众检验的加密方法”比起来，无论是实践中还是业界共识上，都是后者更靠谱。