密码传输问题

密码传输问题

 

上文讲了密码在系统中的存储问题，接下来就简单说说密码在进入系统之前的传输问题。

 

一般在线系统，密码的传输要经过下面几个步骤：

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 也都必须要有微软的数字签名才能运行。

2 原始密码的转换

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

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

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

3 转换后的密码的在线传输

一般来说，为了保证安全传输，必须要用随机密钥对传输的明文进行加密转换后再传输。如果不使用 HTTPS，那就算密码不被攻破，还是有可能发生重放攻击。传输的中间人截获了转换后的密码后，就有可能用转换后的密码进行认证和攻击。

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

4 常用服务的密码传输方法

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

网站	密码传输方式	安全性
bitbucket.org	HTTPS 加密传输	高
微软 live.com	HTTPS 加密传输	高
Google.com	HTTPS 加密传输	高
开心网 kaixin001.com	HTTP 客户端 Javascript 加密传输	中
西祠 xici.com	HTTP 客户端 Javascript 加密传输	中
csdn.net	HTTP 客户端 Javascript 加密传输	中
人人网 renren.com	HTTP 明文传输	低
javaeye.com	HTTP 明文传输	低
天涯 tianya.cn	HTTP 明文传输	低

强烈建议对那些既不支持 HTTPS 登录，而且又不经过客户端加密，直接使用 HTTP POST 明文传送密码的网站，不要使用自己的关键密码来注册，避免泄露。

5 小结

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

4        使用 HTTPS 加密传输，非常安全，但对 Server 性能要求很高。也影响登录速度。一般用在高安全性的登录上面。Google 和微软的登录都强制使用 HTTPS 确保安全第一。

5        使用随即密钥对密码进行加密变换后传输，相对安全，密码明文很安全，但仍可能发生重放攻击。这种方式是性能和安全性的折中。一般的服务使用足亦。国内的开心网就使用这种方式进行登录认证。

不做任何修饰，直接将密码明文通过 HTTP POST 传输。这种方式漠视了用户密码的安全。实现起来非常简单，但却是对用户隐私和资料的不负责任。很可惜，国内几个著名网站都是采用这种简单方式。用户的应对之道就是不要在这些网站上使用有价值的密码，例如你银行卡的密码。

6 其它

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

7 2010年8月6号更新

最近在使用浦发银行的 400 电话服务时，惊奇的发现，当系统提示输入密码时，除了听到自己的按键音外，听筒里还有其它的按键音随机的响起。因为这些背景音的干扰，居然让人输入密码时有点手足无措。

略一思考，这不正是防范输入密码的声音被有心者录下，通过音频分析软件盗取银行密码的安全措施吗。浦发连这点都想到了，不知道其它的电话系统是否现在也都采用了这种措施加强安全。

其实，声音也是种 UI 界面，当输入密码时声音的反馈被混淆和加噪后，确实有些不适应。原来一直忽略的声音 UI，对人的重要性一点也不比图形UI 来的低。