Solaris操作系统的用户认证.docVIP

Solaris操作系统的用户认证: 第1部分 本文介绍了Solaris操作系统的用户认证与授权技术，并通过代码示例说明如何实现口令的加密与存储。 简介 认证与授权 口令存储与加密算法 用户口令的读取 口令加密 用户影子文件的读取 将各部分合并在一起 结束语 致谢 参考资料 简介 通常我们的程序需要检验用户的身份，尤其是我们需要执行有潜在危险或特权操作时，这一点尤为必要。例如，大多数Solaris用户所熟悉的登录，只有我们正确输入用户名和口令后，方可使用系统；而另一个常见例子就是，当屏幕加锁后我们需要解锁。 在本系列文章中，我们将介绍如何在程序中利用口令和其他方法验证用户身份。在本文的第1部分中，我们将讨论验证原理，并通过基于口令技术的身份验证的示例来加以详解。而在第2部分中，我们将了解如何利用PAM技术（插入式验证模块）来使我们的程序更加灵活。 身份验证与授权 人们在讨论口令时通常会涉及两个术语，即身份验证与授权。但它们往往会被误用，在此我们对其定义如下。 身份验证发生于计算机校验用户身份时：当用户用正确口令登录后，操作系统会授权给用户。另一方面， 授权将决定用户是否有权限执行既定任务或访问系统特定资源。 既然我们可以通过认证，那么我们的所做就没有必要被授权才可以完成。例如，我们以普通用户登录后，通常不会对其他用户的文件造成影响：即使我们的身份通过难证，我们也没有足够的权限。而倘若我们是管理员用户，我们则有权限随心所欲的使用系统。为简单起见，我们忽略了RBAC（角色访问控制）和权限细粒化。对RBAC感兴趣的读者可参考 System Administration Guide: Security Services 。权限细粒化详见 Programming in the Solaris OS With Privileges。 虽然有多种途径可实现身份验证（如，生物测定、身份证等等），但本文只讨论口令验证。 口令存储与加密算法 如果用户输入的响应询问口令需要与正确口令相比较，则正确口令必须存储在系统中的某个文件中。在Solaris系统中，用户口令存储在文件 /etc/shadow中，但之前一直存储在 /etc/passwd文件中（由于其名称）。由于多种原因， /etc/passwd须可供所有用户读取。为避免口令被破译，UNIX平台（Solaris即为其中之一）中的系统V变量可把口令存储在 /etc/shadow中，只可供超级用户读取。（注意，前述内容假定口令存储于本地文件中。而许多大型站点往往使用NIS, LDAP, or NIS+将用户口令存储于集中式存储库中。） 存储在 /etc/shadow中的口令使用单向哈希算法进行加密，因为如果以明文格式，即解密格式存储口令，则欠失理智!所谓单向哈希算法加密是指无法从加密口令得出口令。在Solaris 9 12/02之前，加密算法都基于DES（加密算法标准）的各种变体，采取各种措施来阻止硬件中对密钥的搜索。 自1977年DES面世以来，随着计算机处理速率的显著提高，暴力破译DES加密口令所带来的威胁也与日俱增，并且其口令长度局限于8位字符。为减缓威胁，Solaris 9 12/02采用了一种新型编码，促进了一些更为强大的加密算法（如MD5和Blowfish）的广泛使用。由于在新型编码中增加了密钥长度和算法复杂度，欲暴力破译使用新型加密算法编码的口令，需要比破译DES加密口令高出几个数量级的时间。 谈到这里，读者不禁会问：我们该如何决定用哪种算法来加密口令？为了回答这个问题，我们需检查几个影子文件的内容。下面是作者一台计算机中的影子文件内容的例子： rich:TISFHhgBSAtgU:13608::::: shadow(4)手册页详细说明了这些字段。我们主要关注于头两部分：第一个字段是用户名，第二个字段是加密后的口令。如果口令的第一个字符不是 $，那么此口令使用的是基于DES的加密。加密后的口令共有13个字符，其中前两个字符是salt，salt是用于扰乱DES算法的4096种算法中的一种，而余下的11位字符即为加密口令本身。如果第一个字符是$，一直到下一个$间的这些字符则表明所使用的加密算法，而处于第二和第三个$间的字符即为salt。 而在作者另一台计算机中，使用的是另一种加密算法。下面是对应的影子文件内容: rich:$2a$04$NZJWn7W2skvQRC5lW3H7q.ZTE8bz4xbCAtU1ttzUOy63si3phphUu:13613::::: 可以看出，第一个字符是$，表明使用的是另一种加密算法（在本例中，我们用2a来标识算法，即为Blowfish）。标识符到各自库的映射（及它们的特定算法）定义在 /etc/security