尽管业界已经达成共识，在传输用户password等须要保密的信息时，尽可能採用HTTPS/SSL协议传输。

但我们还是能够看到少数没实用HTTPS/SSL加密的站点或应用。

新浪微博的登录页面和MySQL是两个样例。接下来我们具体分析它们的password传输和保存机制。

步在计算token的过程中，须要对password作一次SHA1加密的哈希值。而在mysql.user表中。仅仅有对password作两次SHA1的哈希值。

破解方法

尽管MySQL的机制比新浪微博的要安全一些，但它仍然存在安全隐患。这个机制的短板在于password的存储。存储password的两次SHA1算法的哈希值并不能有效防止彩虹表法破解。

非常多黑客手上都有SHA1算法哈希值的彩虹表。他们仅仅要把这种彩虹表里的哈希值再作一次SHA1加密就能够了。

MySQL採用这个机制也能够理解。

假设黑客能够侵入mysql.user表格。那么他自然也能侵入MySQL数据库中的其它表格。

通常黑客破解的password的目的是盗取他人的数据。也就是黑客一旦侵入了mysql.user表格，那么他无需破解password也就能盗取数据了。

MySQL採用上述password保护机制有它的理由。其它系统假设也採用同样的机制，就要细致考虑当中的安全隐患了。

小结

一个系统的password保护机制是否安全取决于两个方面，即password传输的安全性和password存储的安全性。新浪微博和MySQL都没有採用HTTPS/SSL传输password。为了防止黑客在password传输过程中窃听password。它们仅仅能在传输过程中加盐然后用SHA1算法加密。因为password在传输过程中须要加盐，为了能够正常验证password，因此在存储password时仅仅能存储没有加盐的SHA1算法的哈希值。

因此password的存储成为整个机制的短板。

笔者曾写过一篇博客讨论怎样安全地存储password。感兴趣的读者请參考http://blog.csdn.net/cadcisdhht/article/details/19282407。

我们没有必要在抛弃HTTPS/SSL的前提下试图去设计更加复杂的加密算法或者通讯协议。上述提到的两个方案是新浪微博和MySQL的程序猿们花了大量精力设计出来的机制，尚且还有明显的漏洞。我不觉得每一个程序猿都有自信说自己比新浪微博或者MySQL的程序猿更加优秀。

HTTPS/SSL在传输过程中用证书加密。不须要加盐来提高传输的安全性。这样在存储password的时候就能够採用加盐的机制，比方简单地採用加盐的SHA1算法。也能够採用Bcrypt或者PBKDF2。如此以来，在password的传输和存储两个环节都取得非常好的安全性。

假设安全性对一个系统是至关重要的因素，那么就採用HTTPS/SSL吧。

尽管部署HTTPS/SSL的系统有些麻烦，申请可信赖的CA的证书还要花钱，但和安全漏洞的潜在风险相比这些代价还是值得的。