密码以MD5值存储在数据库更安全

 1,为什么数据库中保存的是密码的MD5值,而不是明文?

首先我们确认的一点是:MD5肯定比明文要安全一些(当然肯定不是最安全的)

如果数据库存储的是明文,如果数据库被黑了,那么明文密码泄露之后,普通用户都可以很容易登录.

但是如果存储的是MD5值,就算泄露了,普通用户也没法登录.因为页面上登录时要求输入明文.

当然程序员可以直接调用登录接口,传递密码MD5值也可以登录.

另外一点:明文包含更多的信息(相对于其MD5值),比如明文可能是银行密码,或者包含出生日期等,这些都是敏感信息.使用MD5之后,这些敏感信息就会被抹掉.即信息量减少

如果使用明文存储,那么登录时,网络传输的是密码明文.

2,遇到的问题

若数据库存储的是密码MD5值,那么密码强度就不方便计算.

因为密码强度是根据密码明文来计算的,而不是密码的MD5值,但是数据库中存储的是密码的MD5值.

根据MD5值是没法计算密码强度的,因为MD5值不可逆,即根据MD5值没法得到明文.

所以此时密码强度应该在前端校验

3,原则:

(1)在网络传输中,不能传输密码明文;

(2)密码明文不能落地,即密码明文不能存储在任何地方,包括数据库,浏览器cookie

(3)就算数据库被黑,黑客也没法计算出明文

其实我想到了一种方案:

数据库中存储的仍然不是密码明文,但是也不是MD5值,而是加密(对称加密,比如AES,DES等)的密文.

因为满足了:

(1)数据库没有存储密码明文;

(2)可以很方便地计算密码强度

(3)忘记密码很容易恢复

(4)网络传输的仍然是密码的MD5值(后台先解密得到密码明文,然后计算明文的MD5值)

优点:后台可以计算出密码明文;

缺点:黑客仍然有可能获取明文

只要

(a)黑掉数据库;

(b)获取到秘钥

但是使用MD5存储,黑客永远都无法获取密码明文

4,如果使用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做电子签名，千万别用什么快捷支付，只要开了这个口子，迟早被钓鱼。

5,建议

在使用MD5保存密码时,最好加入混淆的字符串:

用户名

即数据库存储的MD5值是(密码明文的MD5+用户名)的MD5值,

为什么不是(密码明文+用户名)的MD5值?因为网络传输不能传输密码明文(这是原则)