import os
from hashlib import sha256
from hmac import HMACdef 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 = passwordfor i in xrange(10):result = HMAC(result, salt, sha256).digest()return salt + result

hashed = encrypt_password('secret password')

def validate_password(hashed, input_password):return hashed == encrypt_password(input_password, salt=hashed[:8])assert validate_password(hashed, 'secret password')

• 密码输入
• 密码转换
• 密码在线传输
• 常用服务分析
• 小结
• 其它

密码输入

千里之行始于足下，用户输入密码这第一步往往是最危险的。常用的攻击方法包括：

• 偷看输入的密码

  在公共场合输入密码很容易被偷看，例如使用 ATM 机取款的时候。输入密码时密码明文用 * 代替就是为了防止偷窥。但这样正常用户也不能直接用眼睛确认输入密码是否正确，通常在设置新密码时就要输入两遍来确保输入无误。iPhone 在这点做了改进，每输入一个密码字符先显示半秒钟的明文再转成 * 显示，鉴于使用 iPhone 虚拟键盘输入时，按错键的概率还是比较高的，这个折中也是在可用性和安全性上做了妥协。还有些系统为了最大限度的防偷窥，在输入密码时屏幕没有任何输出，比如 Unix/Linux 的命令行登录界面。这样就连输入的密码长度都看不出来。

• 用木马程序记录键盘输入

  现在比较流行的 QQ 或网络游戏的盗号就常用这种方式进行。安装杀毒软件来防盗号自不必说，还可以用屏幕软键盘输入密码，这样木马就记录不到键盘事件，只能通过分析鼠标点击和当时屏幕图象来破解密码。如果再进一步，软键盘的字符布局每次都随计产生，那就更加重了分析破解的难度。

• 感染应用程序或使用钓鱼手法，直接得到内存中的密码值

  不管如何防范输入的过程，一旦密码到程序里，就会以明文的形式呈现在内存中，只要恶意软件模仿安全程序（或模仿网站的外观）直接套取密码就轻而易举。现在出现的假 ATM 机诈骗也是这种手法的衍生。还有一种，不是替换或模仿程序，而是用病毒感染原程序将内存中的值读到。要防范这种攻击，必须要对原程序的完整性和合法性进行验证，只有在验证通过后，才能进行正常的登录交互操作。这个验证可以用数字签名来实现。比如 Windows 7 中所有微软的可执行文件都带有微软的数字签名。在网站上则是 HTTPS 的验证。当然，这个验证过程还牵扯到人的判断，在社会工程学上，软件要配合一些强制的措施，才能保证人不会麻痹大意中招。比如浏览器在访问非信任机构签发的数字签名的 HTTPS 站点时，会警告并且阻止用户进行访问。Windows 7 现在所有的驱动程序也都必须要有微软的数字签名才能运行。

密码转换

原始密码会经过一些转换，才能在线上传输。这跟密码的存储类似。直接传输密码明文是最不安全的。而用简单的可逆变换，或者固定密钥加密也只是增加了破解难度。最好是每次服务器随机产生一个密钥，送给客户端进行加密。

如果使用 HTTPS，那所有通过 SSL 通道的信息都经过了随机密钥加密。自然也包括了密码。HTTPS 虽然安全，可它最大的问题是性能。连接初始时密钥的协商是通过非对称加密的体系进行的，这会造成连接较慢（密钥协商好后的数据加密是纯耗 CPU 的工作，在现在的硬件条件下，并不是瓶颈）。金融在线系统一般都使用 HTTPS ，但大部分在线应用出于性能的考虑，会选择使用 HTTP 交换随机密码的方式。

随机密钥由服务器生成并发送给客户端。客户端用此密钥将密码加密，送给服务器。这里不要求加密方法是可逆的。一个较安全的做法是客户端使用 MD5 或 SHA-1 算法对密码进行不可逆转换，再用密钥加密送到 Server。现在已经有很多 Javascript 的加密库可以在浏览器端进行这样的转换工作。

密码在线传输

如果只使用 HTTP 而不使用 HTTPS，那就算密码不被攻破，还是有可能发生重放攻击。当中间人截获了转换后的密码后，他不必知道密码明文就可以用转换后的密码通过服务器的认证。

现在最新的研究是利用量子力学所揭示的粒子对的超距相关性来进行量子加密传输。可以类比古代密信的火漆封口，一旦信件被拆开，火漆肯定被破坏。收信人就会知道。量子加密很耗资源，是为了军事等绝密级别信息传输准备的技术。用于量子加密传输的信息也只会是密钥。一旦双方确认了彼此的密钥，就可以使用普通通道来传输加密后的密文了。看上去量子加密传输很象终极解决方案，可最近也传出了针对量子加密的成功攻击的 案例 。

常用服务分析

这里用抓包方式分析一下常用的网络服务的密码传输，看看它们在安全性方面做的如何

对那些既不支持 HTTPS 又不经过客户端加密，而是直接使用 HTTP 明文传送密码的网站，建议不要使用常用的密码来注册，避免安全隐患。

小结

密码的传输比 密码的存储 更加敏感和不安全，大致有三个层次的传输策略：

1. 使用 HTTPS 加密传输，非常安全。HTTPS 对服务器性能要求高，也影响登录速度。一般用在高安全性的登录上面。Google 和微软的登录都强制使用 HTTPS 确保安全第一
2. 使用随机密钥对密码进行变换后再传输，相对安全。密码明文很安全，但仍可能发生重放攻击。这种方式是性能和安全性的折中。一般的服务使用足亦，例如国内的开心网
3. 不做任何修饰，直接将密码明文通过 HTTP 传输。这种方式实现起来非常简单，但却是对用户隐私和数据的不负责任。很可惜，国内几个著名网站都是采用这种简单方式。用户的应对之道就是不要在这些网站上使用常用的密码，例如你银行卡的密码。

其它

密码在传输过程中的泄露的途径很多，你很可能完全没有意识到密码正被窃听。比如最近的一个新闻，骗子用软件对电话按键音进行音频分析，进而得到用户的密码。大概我们在用电话银行时都没有想到，按键的声音居然也是我们密码传输的一种载体吧。

最近在使用浦发银行的 400 电话服务时，惊奇地发现当系统提示输入密码时，除了听到自己的按键音外，听筒里还有其它的按键音随机的响起。因为这些背景音的干扰，居然让人输入密码时有点手足无措（声音也是种 UI 界面，只是一直被忽略，其实它对用户的重要性一点也不比图形 UI 来的低）

略一思考，这不正是防止电话按键音泄露银行密码的安全措施吗。浦发连这点都想到了，真是魔高一层道高一丈！

来源：http://zhuoqiang.me/password-storage-and-python-example.html