1.简介
口令是最常用的认证形式，口令是由字母、数字、特殊字符构成的字符串，只有被认证者知道。
2.明文口令
2.1 工作原理
这是最简单的基于口令认证机制。通常，系统中每个用户指定一个用户名和初始口令。用户定期改变口令，以保证安全性。口令以明文形式在服务器中存放，与用户名一起放在用户数据库中，这个认证机制工作如下：
第一步：提示用户输入用户名和口令
认证时，应用程序向用户发送一个屏幕，提示用户输入用户名和口令。
第二步：用户输入用户名和口令
用户输入用户名和口令，并按OK之类的按钮，使用户名和口令以明文的形式传递到服务器上。
第三步：验证用户名和口令
服务器通过用户数据库检查这个用户名和口令组合是否存在。通常，这是由用户认证程序完成的。这个程序取得用户名和口令，通过用户数据库检查，然后返回认证结果（成功或失败）。
第四步：认证结果
根据用户名和口令检查成功与否，用户认证程序向服务器返回相应的结果。
第五步：相应地通知用户
根据检查成功与否，服务器向用户返回相应屏幕。如果用户认证成功，则服务器通常发送给用户一个选项菜单，列出用户可以进行的操作；如果用户认证不成功，服务器向用户发送一个错误屏幕。
2.2 该方案存在的问题
可以看出，这个方法根本不安全，存在如下两个问题：
问题一：数据库中包含明文口令
首先，用户数据库以明文形式存放用户名和口令。因此，如果攻击者成功访问数据库，则可以得到整个用户名和口令表。因此，最好不要以明文形式把口令存放在数据库中，而要先加密，然后存放在数据库中。用户登录时，服务器方要先加密用户口令，然后与数据库中的加密口令比较，根据比较结果确定认证结果。
问题二：口令以明文形式传递到服务器
即使存放在数据库中的是加密口令，但口令还是以明文的形式传递到服务器。因此，如果攻击者破解用户计算机与服务器之间的通信链路，则很容易取得明文口令。下面会介绍如何处理这个问题。
3.口令推导形式
3.1 简介
基于口令认证机制的变形是不用口令本身，而是用口令推出的值，即不是存储口令或其加密形式。而是对口令执行某种算法，在数据库中，存储这和算法的结果，作为口令推导形式。用户认证时，输入口令，用户计算机在本地执行这个算法，并将口令推导形式发送到服务器，在服务器上进行验证。要使这个机制正确工作，需要满足下面几个要求：
1.每次对同一口令执行算法时，应得到相同输出；
2.算法输出（即口令推导形式）不能让人看出原口令；
3.攻击者不可能提供错误口令而得到正确的口令推导形式。
可以看出，这些要求与消息摘要非常相似，因此可以使用MD5与SHA-1之类的算法。
3.2 口令消息摘要
避免存储与传输明文口令的简单技术是使用消息摘要，下面介绍其工作方法。
第一步：在用户数据库中存放由口令导出的消息摘要
不是存储口令，而是在用户数据库中存储由口令导出的消息摘要，如下图所示：
第二步：用户认证
要认证用户时，用户和平常一样输入用户名和口令。接着，用户计算机计算口令的消息摘要，并将用户名和口令的消息摘要发送到服务器中认证，如下图所示：
第三步：服务器方认证
用户名和口令的消息摘要通过通信链路传递到服务器上。服务器将这些值传递给用户认证程序，其按照数据库验证用户名和口令的消息摘要，并向服务器返回适当的响应。服务器用这个操作的结果向用户返回适当的消息。
虽然利用消息摘要能满足所有的要求，但是这是不安全的。攻击者只要监听用户计算机与服务器之间涉及登录请求/响应对的通信。攻击者只要复制用户名和口令的消息摘要，过一段时间在新的登录请求中将其提交到同一服务器。服务器不知道这个登录请求不是来自合法用户，而是来自攻击者。因此，服务器会使攻击者认证成功，这就是重放攻击，因为攻击者只要重放正常用户的操作序列。
3.3 增加随机性
在前面的机制中增加一些随机性和不可预测性，保证虽然口令的消息摘要相同，但用户计算机与服务器之间交换的信息不同，使重放攻击无法成功，有以下几个简单方法：
第一步：在用户数据库中存放由口令导出的消息摘要
只是在用户数据库中存储用户口令的消息摘要，而不是存储口令本身。
第二步：用户发送登录请求
用户发送的登录请求只有用户名，没有口令或口令的消息摘要。
第三步：服务器生成随机挑战
服务器收到只有用户名的用户登录请求时，首先检查用户是否有效，只检查用户名。如果无效，则向用户返回相应的错误消息；如果有效，则服务器生成一个随机挑战（随机数，用伪随机数生成方法生成），将其返回用户。随机挑战以明文形式传递到用户计算机。如下图所示：
第四步：用户口令的消息摘要签名随机挑战
这时应用程序向用户显示口令输入屏幕。用户在屏幕上输入口令。应用程序在用户计算机上执行相应的消息摘要算法，对用户输入的口令生成消息摘要，并用这个消息摘要加密从服务器收到的随机挑战。，这个加密使用对称密钥加密。如下图所示：
第五步：服务器验证从用户收到的加密随机挑战
服务器收到随机挑战，其用用户口令的消息摘要加密。要验证随机挑战是用用户口令消息摘要加密，服务器就要进行相同的操作，可以用两种方法进行：
1.服务器可以用用户口令的消息摘要加密解密从用户收到的加密随机挑战。服务器可以通过用户数据库得到用户口令的消息摘要。如果这个加密与服务器上原先的随机挑战匹配，则服务器可以肯定随机挑战是用用户口令消息摘要加密。。
2.服务器也可以用户口令消息摘要加密自己的随机挑战（即前面发给用户的版本），如果这个加密得到的加密随机挑战与从用户收到的加密随机挑战相符，则服务器可以肯定随机挑战是用用户口令消息摘要加密。
第六步：服务器向用户返回相应消息
根据上述操作成功与否，服务器向用户返回相应消息。
3.4 口令加密
要解决明文口令传输问题，可以先在用户计算机上加密口令，然后将其发送到服务器上认证，即要在用户计算机上提供某种加密功能。事实上，这个功能在用用户口令的消息摘要加密随机数时也需要。但对于Internet应用程序，客户机是Web浏览器，没有任何特殊编程功能。因此，要利用安全套接层（SSL）之类的技术，即客户机和服务器之间要建立安全SSL连接，客户机要根据服务器的数字证书验证服务器身份。然后用SSL加密客户机和服务器之间的所有通信，因此口令不需要任何应用层保护机制。SSL会进行必要的加密操作，如下图所示：
这里有两个加密过程：
1.第一个加密发生在口令存放到用户数据库之前。
2.第二个加密是在用户计算机上进行的，先加密口令，再将其传输到服务器。
这两个加密操作没有直接关系，甚至可以用完全不同的方法加密，因此数据库中加密的口令不必与来自用户计算机的加密口令相同，但是，这里的只要思想都是加密口令，而不是明文形式的。
4.安全问题
组织有许多应用程序、网络、共享网络和内部网，而且这些应用程序对安全措施有不同需求，提出的时间不同。因此，每个资源都需要用户名和口令，这样，最重要和要记住和正确使用许多用户名和口令，大多数用户对所有资源使用相同口令，会大大增加口令的安全问题。
口令维护是系统管理员的一个大问题，系统管理员大约40%的时间用在生成、复位和修改用户口令。组织要指定口令策略，规定口令结构。同PBE中的盐一样，这种口令策略可以大大提高字典攻击的难度，攻击者无法从字典中通过普通单词攻击口令，但是，这样会使最终用户难以记住口令，因此，最终用户只好把口令记在某个地方，从而使口令策略的作用被完全抵消。
