在各种线上应用中，用户名密码是用户身份认证的关键，它的安全重要性不言而喻。一方面，作为保护用户敏感数据的“钥匙”，一旦被破解，系统将敞开大门完全不设防。另一方面，密码这把“钥匙”本身就是非常重要的数据：用户经常会在多个应用中使用相同或相似的密码。一旦某一个应用的密码被破解，很可能，坏人就因此而掌握了用户的“”，这个用户的其它应用也相当危险了。 这篇博文就重点讨论对于密码原文本身的存储的安全性考虑，而系统自身的安全性不在此文的范围之内。
那么，对于如此重要的用户密码，究竟该怎样在系统中存储呢？
“君子不立危墙”，对于用户密码这个烫手的山芋，一个极端的选择是系统完全不接触密码，用户的身份认证转而交由受信任的第三方来完成，比如 OpenID 这样的解决方案。系统向受信任的第三方求证用户身份的合法性，用户通过密码向第三方证明自己的身份。
这样，密码完全不经过系统，系统也就不用绞尽脑汁保证密码的安全了。这个作法对用户来
说还有个额外的好处：再也不用为每个应用注册帐号了，同一个 OpenID 就可以登录所有支持 OpenID 的系统了。
好虽好，可在今天这样一个各自为战，划分地盘的网络战国时代，作为一个自主的系统，自己的用户资源居然不能掌握在自己的手上，而要与别人分享，甚至 “受制于人”，这多少有点让人难以接受。（据称，现在全球有 27000 个 Web Site 支持 OpenID 登录，虽然还在持续增长中，但在茫茫“网海“中无疑还是属于小众）
好吧，既然网络大同时代还没来临，系统还是要自己负责用户的认证，那密码该如何存储呢？按照安全性由低到高，有这样几种选择：
1 密码名文直接存储在系统中
这种方法下密码本身的安全性比系统本身还低，系统管理员可以直接看到所有用户的密码名文。除非你是做恶意网站故意套取用户密码，否则不要用这种方式。 密码名文经过对称转换后再存储的
这跟上面的直接明文的方式没有多少本质改进，任何知道或破解出转换方法的人都可以通过相应的逆转换得到密码原文。
2 密码经过对称加密后再存储
用户密码明文的安全性等同于加密密钥本身的安全性。对称加密的密钥会同时用于加密和解密，所以它会直接出现在加密代码中，破解的可能性也相当大。而且，知道密钥的人很可能就是系统管理员，所有人的密码原文他都能算出来。
3 密码经过非对称加密后再存储
密码的安全性等同于私钥的安全性。密码明文经过公钥加密，而要还原名文，则必须要私钥才行。因此只要保证私钥的安全，密码名文就会安全。私钥可以由某个受信任的人或机构来掌管，普通的身份验证只需要用公钥加密就可以了。
电子监管码设备实际上，这也是 HTTPS/SSL 的理论基础。这里的关键是 私钥的安全 ，如果私钥泄露，那密码名文就危险了。
以上 4 种方法的一个共同特点是可以从存储的密码形式还原到密码的明文。
如果你注册了一个网站，当你忘了密码后，网站可以很贴心地通过你注册的 email 告诉你原来的密码是什么，那么，它肯定就是用了上面的4种方法中的一种了。这时候你就得小心了：既然网站能知道你的密码明文，那网站的工作人员就可能知道你的密码明文，任何攻入了这个网站的人也有了还原你密码明文的可能，甚至于，网站本身就是恶意的钓鱼网站。
所以，最好的保存密码的方式是以连系统自己都不可能还原明文的方式来保存，也就是常用的利用哈希算法的单向性来保证明文的信息以 不可还原的有损方式 进行存储。
这大类的各个方式按安全性由低到高为：
4 使用自己独创的哈希算法对密码进行哈希，存储哈希过的值。
哈希算法的要求很高，一般来说，自己独创的哈希算法肯定没有公开的经过时间检验的算法质量高，除非你是天才。
5 使用 MD5 或 SHA-1 进行哈希然很存储。
MD5 和 SHA-1 已经被破解。这意味着虽然不能还原密码原文，但很容易到一个能同样生成相同哈希值的密码原文的碰撞。还有一点，这两个算法相对速度较快，这就意味着对暴力破解来说消耗的资源少。 所以建议不要使用它们。
6 直接使用更安全的 SHA-256 等成熟算法。
这个只是在一定程度上增加了暴力破解的时间。如果遇到简单密码，通过常用密码字典的暴力破解法，很快就可以还原密码原文。
加入了随机 Salt 的哈希算法。
密码原文（或进过hash后的值）和随机生成的 salt 字符串混淆，然后再进行 hash，最后把 hash 值和 salt 值一起存储。验证密码的时候，只要用存储的 salt 值再做一次相同的 hash 再与存储的 hash 值比较就可以了。
这样一来，就算用户使用简单的密码，但进过 Salt 混淆过的字符串就是一个很不常见的串，一般不会出现在密码常用字典中。Salt 的程度越长，暴力破解的难度就越大。
具体的 hash 过程也可以进行若干次叠代，虽然 hash 叠代会增加碰撞率，但也增加暴力破解的资源消耗。
最后，就算真被暴力破解了，被破解的也只是这个随机 salt 混淆过的密码，破解者不能用它来登录该用户的其它应用（如果其它应用也用了自己的随机 salt）
上面这几种方法都不可能还原密码的明文，这意谓着，就算是系统管理员也不知道密码原文。这也意谓着，这个世界上只有你知道你自己的密码。网站再也没有办法提醒你原来的密码是什么了。对于那些真的忘了自己密码的用户，网站可以提供一个重置密码的功能，帮用户随机生成一个临时密码，让用户通过这个临时密码来登录到系统中重新设置新的密码。
下面的 python 程序就是使用了 salt hash 来加密密码明文
import os from hashlib import sha256 from hmac压脉带 import HMAC def encrypt_password(password, salt=None): """Hash password on the fly.""" if salt is None: salt = os.urandom(8) # 64 bits. assert 8 == len(salt) assert isinstance(salt, str) if isinstance(password, unicode): password = password.encode('UTF-8') 加固显示器assert isinstance(password, str) result = password for i in xrange(10): result = HMAC(result, salt, sha256).digest() return salt + result |
|
这里先通过标准随机库生成 64 bits 的随机 salt，使用了标准的 SHA-256 做为基本的 hash 算法，使用标准 HMAC 算法作为 salt 混淆。并且进行了 10 次混淆 hash。最后将 salt 和 hash 结果一起返回。
使用的方法很简单：
hashed = encrypt_password('secret password') |
|
下面是验证函数
洗手液机def validate_password(hashed, input_password): return hashed == encrypt_password(input_password, salt=hashed[:8]) |
|
锚
它直接使用 encrypt_password 来对待检验的密码进行相同的 salt 混淆 hash 并与出口存储的值比较。
使用示例：
assert validate_password(hashed, 'secret password') |
|
上面的实现虽然只有简单几行，但借助了 python 标准库的力量，已经是一个可用于生产环境的高安全的密码存储方案了。
总结一下用户密码的存储：
如果可能，不要存任何密码信息
让别人来帮你做事（OpenID）
如果非要自己认证，也只能存 有损的密码信息 。通过单向 hash 和 salt 来保证密码明文只存在用户手中
绝对不能存可还原密码原文的信息 。如果因为种种原因一定要可还原密码原文，请使用非对称加密，并保管好私钥
密码传输问题
上文讲了密码在系统中的存储问题，接下来就简单说说密码在进入系统之前的传输问题。
一般在线系统，密码的传输要经过下面几个步骤：
1 用户在网络浏览器上输入原始密码：人 ——> 键盘 ——> 浏览器内存 2 原始密码做一定的转换：内存中的原始密码 ——> 内存中的转换后的密码
3 转换后的密码在线上传输：内存中转换后的密码 ——> 网络 ——> 系统nnn
这其中的每一步都有可能导致原始密码的泄露，也有相应的应对之法应对。
1 输入原始密码
2 原始密码的转换
3 转换后的密码的在线传输
4 常用服务的密码传输方法
5 小结
6 其它
7 2010年8月6号更新
1 输入原始密码
在一个存储和传输每个环节都很安全的环境下，最危险的就是用户输入原始密码这第一步。常用的攻击方法包括：
偷看输入密码值
在公共场合输入密码很容易被人故意偷看，例如使用 ATM 机取款的时候。一般输入密码的字符明文用 * 号代替，这种做法就是为了保证密码明文不被肉眼偷窥。不过这样以来，用户也不能直接看到自己输入的密码是否正确。iPhone 在这点上做了小改进，在输入一个密码字符时先显示明文，过大约 0.5 秒再转成 * 显示，鉴于使用 iPhone 虚拟键盘输入时，按错字母的概率还是比较高的，这个折中也是在可用性和安全性上做了妥协。有些系统，为
了最大限度的防偷窥，在输入密码的时候屏幕不输出任何东西，比如 Unix/Linux 的 Console 登录。这样一来，就连输入的密码长度都看不出来。当然，在设置新密码的时候，相应的，一般也要通过输入两遍密码来保证没有任何输入错误。
木板削削削 用木马程序记录键盘输入
现在比较流行的 QQ 或 网络游戏的盗号就常用这种方式进行。安装杀毒软件来防盗号自不必说，还可以做的是用屏幕软键盘输入密码，这样木马就记录不到键盘事件，只能通过分析鼠标点击和当时屏幕图象来破解密码。如果再进一步，软键盘的字符布局每次都随计产生，那就更加重了分析破解的难度。
模仿或感染应用程序，直接得到内存中的密码值
不管如何防范输入的过程，一旦密码到程序里， 就会以明文的形式呈现在内存中，只要恶意软件模仿安全程序（或模仿网站的外观）直接套取密码就轻而易举。现在出现的假 ATM 机也是这种手法的衍生。还有一种，不是替换或模仿程序，而是用病毒感染原程序，将原程序内存中的值读到。要防范这种攻击，必须要对原程序的完整性和合法性进行验证，
在验证通过后，才能进行正常的登录交互操作。这个验证可以用数字签名来实现。比如 Windows 7 中所有微软的可执行文件都带有微软的数字签名。在网站上则是 HTTPS 的验证。当然，这个验证过程还牵扯到人的判断，在社会工程学上，软件要配合一些强制的措施，才能保证人不会麻痹大意中招。比如浏览器在访问非信任机构签发的数字签名的 HTTPS 站点时，会阻止用户进行访问。Windows 7 现在所有的 Driver 也都必须要有微软的数字签名才能运行。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议