用户名与口令的风险011121.docVIP

使用用户名与口令的风险 基于用户名与口令的系统安全分析 使用口令具有风险 随着信息安全需求的不断增长，安全传输已经是企业的基本需求。在涉及到资金购买的环境中，授权验证系统首先应被考虑到。随着时间的推移，在企业环境中用户名和口令的机制并不是最安全有效的。 当我们分析口令提供的机制时，我们可把它分为两个阶段。第一个阶段是身份识别阶段，确认你是谁；第二阶段是身份验证阶段，获取身份信息并验证身份信息。在对信任方分配权限之前身份应该被验证。一个简单的身份验证过程通常是弹出窗口，提示用户输入用户名及口令，当然口令只有用户自己知道。身份信息在没有验证的系统中没有多大的价值。既然身份信息总被用于不同类型的信用来提供安全，在当前的信息技术环境中，这个基于口令的身份验证过程只是一个基本的、容易实施的安全解决方案。 口令存在的问题 我们经常把创建口令当作是最终用户的责任。最终用户被要求创建一个口令，他们能够记住但别人不能猜到，从而留下一个难以解决的矛盾：在创建一个不容易猜到的口令的同时他们自己也不容易记住。而且，这个问题是经常存在的，导致用户很麻烦，这些因素严重影响到当前身份验证系统的强度和效率。 多年前口令管理就不采用用户随意自建口令了（让用户自己随意设置他们自己的口令），因为这经常导致口令强度下降。一旦我们强行使用户设置高强度口令，通常用户会采用便条记口令，因为他们自己也记不住。 如果我们仔细分析当前的身份验证或口令系统，很容易判断出验证系统中固有机制存在先天性弱点。下面将讨论当前身份验证系统的不足之处。 口令输入和接口 在许多实例中，输入的口令很容易泄密，只需通过键盘上的手势就大致能猜出来了。甚至一些程序员可以通过程序记录用户录入的内容。键盘输入记录器能记录所有的输入信息，因此能很容易获得用户名和口令信息。在另外一些环境中，软件保存有用户口令，因此，应用所提供的身份和验证信息是来自于应用程序而不是最终用户。 口令传输 一旦用户输入口令后，传送到验证机制里是安全还是不安全的呢？不幸的是，在大多数环境中是不安全的。在你被要求提供口令登录特定的WEB网站时，有多少次您的浏览器使用的是安全的模式？另外，许多提供商使用加密传输时，只是很弱的加密或加密的位数受到限制。在当前的身份验证机制中口令的安全传输经常被忽视。 口令验证 口令是怎样被验证来说明确实是真实的用户？通常，口令采用缓存技术，因此旧的或非法的口令可以代替正确的口令使用。在有些环境中，软件采用行为验证，通过访问控制和许可进行验证。这可能跳过身份验证机制，允许已经过期的身份成功访问受保护的资源。 口令存储 口令在系统中是怎样被存储的？有四个级别的存储：明文、加密、隐藏明文，隐藏并加密。在过去许多软件工具已经采用简单的加密存储，但他们一般采用强度不高的加密或允许从系统外获得文件。一些简单的强行破解程序很容易解密。许多流行的程序的破解程序已经被开发出来了，如多种版本的UNIX、Windows NT、95、98、2K的用户口令和缓存口令均被破解了。其它一些程序也很轻松地从浏览器或应用中获取口令，如Word、Excel、甚至是Zip文件。 口令的相关说明 在身份认证舞台上口令无可争议的是最大的风险域，但是他也是我们已经能够控制的、广泛使用的安全措施之一。如果我们的用户继续使用强度不高的口令，无论我们的口令在传输、存取、验证、输入过程中都保持高强度也没什么用，因为我们的口令会被泄密出去。黑客们根本不需要知道你的实际运营系统，也不需要用用户名与口令来试图进入系统。 口令是身份验证的常用方法。其中最大的问题就是用户被允许随意指定自己的口令。在某些场合，用户可能让机器或管理员帮助生成口令。 但为什么我们还在继续使用令人头痛的口令呢？主要有以下几方面原因。口令是经济有效的安全机制之一；他们通常是免费的并已经被集成到几乎所有的信息支持里了；口令是非常简单的和易于使用的；大多用户都能接受，因此他们没有实施障碍。 多数口令验证系统以相同的方式工作，因此可以对许多验证系统进行统一管理。尽管口令可能不是最安全的，但总比什么都没有强得多。 和口令相联系的问题包括：安全性、穷举尝试穷举尝试 所谓动态口令技术是对传统的静态口令技术的改进，它采用双因数认证的原理，即用户既要拥有一些东西如系统颁发的token（something you have）,又要知道一些东西如启用token的口令（something you know）。当用户登录系统时，输入token的口令，还要token上所显示的数字Token上的数字是不断变化的，而且与认证服务器是同步的。双因素认证比基于口令的认证方法增加了一个认证要素，攻击者仅仅获取了用户口令或者仅仅拿到了用户的令牌访问设备，都无法通过系统的认证。而且令牌访问设备上所显示的数字不断地变化，这使得攻击变