接着上一篇博客
其实我想到了一种方案:
数据库中存储的仍然不是密码明文,但是也不是MD5值,而是加密(对称加密,比如AES,DES等)的密文.
因为满足了:
(1)数据库没有存储密码明文;
(2)可以很方便地计算密码强度
(3)忘记密码很容易恢复
(4)网络传输的仍然是密码的MD5值(后台先解密得到密码明文,然后计算明文的MD5值)
优点:后台可以计算出密码明文;
缺点:黑客仍然有可能获取明文
只要
(a)黑掉数据库;
(b)获取到秘钥
但是使用MD5存储,黑客永远都无法获取密码明文
1,如果使用DES加密,秘钥保存在什么地方呢?
DES加密是对称加密，密钥的保持就是个大问题，保持在应用程序中的密钥非常容易被破解。而且des密钥一旦泄漏，就等于统统泄漏了。所以在软件中用des比较傻逼。md5 在密文够复杂的情况下，用字典法破解很难，如果再限制验证数，基本不可能被破解，当然，如果密码很简单如111 222 神马的，就当我没说
如果用加密机的话，密钥一次性上载，退一步用软件，密钥也会作严密保护。密钥还分级别，定时更换。
暴力破解MD5是比较容易的，但穷举DES密钥几乎是不可能的任务，2^56的可能。
两者破解方式不同，MD5是尝试明文，DES是尝试密钥。
编两个程序就能看出两者之间巨大的计算量差异。
DES还可以使用Triple的方式，密钥扩展为128位。
现在DES已经慢慢推出应用领域了，AES是更好的选择。
分散算法可以是任何算法，RSA,DES,MD5，甚至异或都可以。目前实际多用3DES，主要是因为硬件实现比较成熟，在大交易量的时候能够保证性能。
比如银行随机产生一个大随机数，导入加密机，作为根密钥。然后配合银行U盾的芯片编号或者POS机编号进行一次分散运算，产生一个密钥，作为这个U盾或者POS的根密钥。这种密钥一般是灌在机器的SIM卡的只写区的，是没有可能读出来的。
然后再具体交易的时候，用这个密钥配合交易时间，交易流水号等信息，再次进行分散，产生工作密钥，一般用工作密钥来加密客户密码，金额，借贷方账号等敏感信息。当报文发送到服务器端后，服务器根据设备编号，交易流水号，重新分散出工作密钥，然后解密报文信息。
这样的交互方式下，客户端和服务器端是没有DES密钥交互的。银行如果发现任何一个终端设备异常，只要将这个设备的根密钥废掉，对于整个系统没有任何影响。
而且不论加密机还是SIM卡中的密钥，都是硬件保证不可读的。
所以目前最安全的网络支付手段就是USBKEY做电子签名，千万别用什么快捷支付，只要开了这个口子，迟早被钓鱼。
2,建议
在使用MD5保存密码时,最好加入混淆的字符串:
用户名
即数据库存储的MD5值是(密码明文的MD5+用户名)的MD5值,
为什么不是(密码明文+用户名)的MD5值?因为网络传输不能传输密码明文(这是原则)
参考:http://lt.cjdby.net/thread-1302097-2-1.html