用户认证与授权

用户认证与授权（精选6篇）

用户认证与授权 篇1

0 引言

复杂网络环境下, 远程服务器与用户之间的身份认证以及安全信道的构建具有重要意义[1,2]。远程用户身份认证是在非信任公共网络中确认远程个体身份的一种有效方法, 已成为保障网络通信安全的重要技术之一[3,4]。1981年, Lamport[5]首次提出基于单向哈希函数的口令认证方案。在Lamport的方案中, 为了验证用户登录请求的有效性, 远程服务器需要存储口令表。此外, Lamport的方案还存在许多安全缺陷, 比如口令表维护带来的高系统开销以及针对口令表的离线字典攻击等[6]。因此, 针对这些设计缺陷并进一步提高系统安全性, 大量学者对远程用户身份认证方案进行了相关研究。

Das等[7]于2004年提出一种基于动态身份远程用户认证方案, 远程服务器无需维护口令表, 并支持用户自由选择和修改口令;在安全性方面, Das等的方案声称可抵御身份盗窃攻击、伪造攻击、内部人攻击以及重放攻击。但在同年, Awasthi[8]指出Das等的方案存在重大安全隐患, 攻击者可以在没有正确口令的情况下成功登录系统, 使用Das等的认证方案相当于访问公开服务器。Ku和Chang[9]也于2005年对Das等的方案分析后指出, 由于用户的登录身份可动态生成且只使用一次, 此方案确实可抵御身份盗窃攻击。但同时Ku等证实Das等的方案无法抵御身份冒充攻击, 攻击者可在任意时间冒充任意授权用户登录远程服务器。Liao[10]等也于2006年指出Das等的方案易受离线口令猜测攻击, 并提出一种支持密钥协商机制和相互认证的增强方案。但在2008年, Misbahuddin和Bindu[11]通过安全性分析指出Liao等的方案无法抵御身份冒充攻击和反射攻击, 并且用户可以使用随机口令成功登录远程服务器。2009年, Wang等[12]提出一种更加高效安全的动态身份远程认证方案, 增强了口令的依赖性并支持相互认证。但Khan等[13]于2010年指出在实际应用中, Wang等的方案存在许多设计缺陷, 缺少会话密钥协商机制, 认证过程中不支持用户匿名性且不能抵御内部人攻击和盗窃智能卡攻击。针对上述安全缺陷, Khan等提出一种更加安全高效的改进方案。

2012年, Wen-Li[14]针对Wang等方案中存在的安全缺陷, 提出一种改进的基于动态身份远程用户认证与密钥协商方案, 使用会话密钥保证通信信道安全, 支持相互认证并可抵御身份冒充攻击。本文分析了Wen-Li方案中存在的安全缺陷, 并在保留原始方案优点基础上提出一种改进的基于动态身份远程用户认证方案, 有效抵御中间人攻击以及盗窃智能卡攻击, 同时保证前向安全性。

1 构建Wen-Li方案

1.1 Wen-Li方案回顾

Wen-Li的远程用户认证与密钥协商方案由四个基本阶段组成:注册阶段、登录阶段、认证和密钥交换阶段以及相互认证和密钥确认阶段。表一所示为方案中使用的符号及其含义。

1.1.1 注册阶段

新用户Ui向服务器S提交IDi和pwi请求注册, S收到注册请求后执行以下操作:

(1) 计算ni=h (IDi|pwi) , ni具有唯一性并由S保存, S通过验证ni确认智能卡的有效性。

(2) S计算

(3) S将参数h (·) 、Ni以及ni存储到Ui的智能卡中。

(4) S向Ui签发智能卡。

1.1.2 登录阶段

当Ui登录S时, 需要插入智能卡并输入IDi和pwi, 此时执行以下操作:

(1) 智能卡计算登录请求消息所需参数:

, T为当前时间戳。

(2) Ui向S发送登录请求消息:M1={CIDi, ni, Ni, T}。

1.1.3 认证和密钥交换阶段

S接收到Ui的登录请求消息M1后将会执行以下操作:

(1) S根据当前时间戳T'检查时间戳T的有效性, 若T'-T≤△T (△T为有效时间间隔) 且ni属于已注册列表, 则S继续以下操作, 否则拒绝登录请求。

(2) S计算

(3) S验证下面等式是否成立

(4) 如果上述等式成立, S计算:, 并生成

(5) S向Ui发送应答消息

1.1.4 相互认证和密钥确认阶段

Ui在T'接收到来自S的应答消息M后, 执行以下操作:

(1) 检查时间戳T'的有效性。

(2) 若时间间隔有效, Ui计算, 并验证是否与Ci相等。

(3) Ui计算, 并验证KC'是否正确。

(4) 若KC'正确, Ui计算

(5) Ui向S发送密钥确认消息:M3={KC, T'}。

(6) S验证M3, 若等式成立, 则认证方案结束。

Wen-Li方案中还包括三个功能性阶段:智能卡废除阶段、用户离线口令更换阶段以及服务器在线安全私钥更新阶段。这三个阶段因与本文讨论无关, 本节将不再详述, 可参见文献[14]。

1.2 基于Wen-Li方案的安全性分析

1.2.1 离线口令猜测攻击

Wen-Li方案中, 当Ui通过公共网络向S发送登录请求消息M1时, M1中存储在Ui智能卡中的用户关键信息可能会泄露 (Ni, ni) , 攻击者可以利用这些信息实施离线口令猜测攻击获取正确的口令。

1.2.2 中间人攻击

由于Wen-Li方案中的登录请求、认证和密钥交换消息均通过公共网络发送, 包括非法用户在内的所有用户均可以截获这些消息。因此, 可以假设攻击者A对Ui和S之间的通信信道实施了监控并截获了登录请求消息M1以及认证和密钥交换消息M2, 并实施图一所示中间人攻击, 图中虚线表示相应的消息在发送到目的地之前已经被攻击者A截获。详细的攻击方案如图一所示。

(1) 攻击者A从截获的消息M1和M2中破解出h (ni) 、T'和Ci, 并计算得到Ai。

(2) 攻击者A计算出Ui和S之间的会话密钥

(3) 因此, 攻击者A可以在不具备IDi和pwi情况下冒充服务器S。

(4) 另一方面, 根据接收到的M1, S计算得到M2并发送给Ui。

(5) 攻击者A截获M2后将其发送给Ui, Ui计算得到M3={KC, T'}并发送给S。

6) 攻击者A截获M3后生成当前时间戳TA, 计算得到KCA=h (Ai‖SK‖TA) , 同时伪造消息M3*={KCA, TA}并发送给S。

(7) S接收到M3*后将验证此密钥确认消息, 由于KC=h (Ai‖SK‖TA) =KCA, 因此M3*是有效的, Ui通过认证。

从以上攻击过程可以发现, 攻击者A可以在S和Ui毫无察觉的情况下与其共享会话密钥SK, 进而在认证过程中对S冒充Ui并同时对Ui冒充S。这种中间人攻击在金融、军事等领域应用中将会造成严重后果。

2 改进方案

2.1 改进方案介绍

本文在保留Wen-Li方案优点基础上, 针对原方案安全缺陷提出一种改进的远程用户认证方案。改进方案包括四个基本阶段:注册阶段、登录阶段、认证和密钥交换阶段以及相互认证和密钥确认阶段, 如图二所示。

2.1.1 注册阶段

要想获取服务, 新用户Ui必须经过如下注册过程:

(1) Ui选择注册所需的IDi和pwi并通过安全信道提交给S。安全信道可以保证未经加密的IDi和pwi在传输过程中免受网络攻击。

(2) S接收到IDi和pwi后, 为每一个Ui分别计算:, S将保存ni用以检查智能卡的有效性。S向Ui的智能卡中存储 (h (·) , Ni, ni) , 并以安全方式向Ui签发智能卡。

2.1.2 登录阶段

当Ui登录服务器S时, 首先在读卡器中插入智能卡, 然后输入注册时选定的IDi和pwi。

(1) 智能卡计算:

(2) Ui通过公共网络向S发送登录请求消息:M1={CIDi, ni, Ni, T}。

2.1.3 认证和密钥交换阶段

(1) S在时间T'接收到Ui的登录请求消息M1后, 首先检查时间戳的有效性, 若T'-T≤△T (△T为有效时间间隔) 且ni属于已注册列表, 则S继续以下操作。

(2) S计算:

, 并验证下面等式是否成立。

(3) 如果上述等式成立, S计算会话密钥:SK=h (Ai‖T||Bi‖T') , 并生成KC'=h (Bi‖SK‖T') 。

(4) S向Ui发送应答消息:M2={KC', T'}。

2.1.4 相互认证和密钥确认阶段

(1) Ui在时间T''接收到来自S的应答消息M2后, 检查时间戳T'的有效性, 若T″-T'≤△T, 则Ui计算:SK=h (Ai‖T‖Bi‖T') , 并生成KC=h (Ai‖SK‖T') 。

(2) 其次Ui验证KC, 若KC=KC', 则Ui生成:

KC''=h (Ai‖SK‖T') , 并向S发送密钥确认消息:

(3) S接收到M3后首先检查时间戳T''的有效性, 若T'有效则S计算:KC'''=h (Ai‖SK‖T') 。

(4) S验证KC''', 若KC'''=KC'', 则M3有效, 认证方案结束。

在改进方案中还保留了Wen-Li方案中的三个功能性阶段:智能卡废除阶段、用户离线口令更换阶段以及服务器在线安全私钥更新阶段, 可参见文献[14]。

2.2 改进方案的安全性分析

本文提出的改进方案和Wen-Li方案的比较结果如表二所示, 其中O表示可以抵御, X表示不可抵御。

2.2.1 身份冒充攻击

在改进方案中, 攻击者A在登录阶段无法伪造认证消息, ni和Ni在哈希函数h (·) 作用下是分别变化的, 改变后的ni无法通过服务器S的验证, 而且若ni发生变化, Ai也将随之变化, 这一等式将无法成立, 因此攻击者无法成功实施身份冒充攻击。

2.2.2 中间人攻击

由于改进方案中的登录请求、认证和密钥交换消息也是通过公共网络发送, 包括非法用户在内的所有用户仍然可以截获这些消息。因此, 假设攻击者A对Ui和S之间的通信信道实施了监控并截获了登录请求消息M1={CIDi, Ni, ni, T}以及认证和密钥交换消息M2={KC', T'}。但是在改进方案中, 即使M1和M2泄露, 攻击者A也无法导出Ai或Bi, 这样Ui和S之间的会话密钥SK=h (Ai‖T‖‖Bi‖T') 不会泄露, 因此攻击者A无法对Ui冒充S。

另一方面, 根据接收到的M1, S计算得到M2并发送给Ui。攻击者A截获M2后将其发送给Ui, Ui计算得到M3={KC'', T''}并发送给S。假设攻击者A截获M3后生成当前时间戳TA, 但其却无法计算得到SK、KCA, 进而无法伪造消息M3*={KCA, TA}对S冒充Ui。因此, 在改进方案中, 即使攻击者或恶意用户截获登录请求消息M1以及认证和密钥交换消息M2, 也无法成功实施中间人攻击。

2.2.3 盗窃智能卡攻击

假设攻击者A盗窃了Ui的智能卡, 智能卡中包含{h (·) , Ni, ni}并记录着Ui和S之间传递的消息{M1, M2, M3}。在改进方案中, 即使从盗窃的智能卡和截获的消息中泄露{hh (·) , Ni, ni, M1, M2, M3}, 攻击者A也无法导出Ai或Bi, 同样无法得到Ui和S之间的会话密钥SK。因此, 攻击者A无法试图通过盗窃智能卡达到冒充S的目的, 改进方案可抵御盗窃智能卡攻击。

2.2.4 前向安全性

前向安全性是指服务器安全私钥x的泄漏不会影响通信双方会话密钥SK的安全性[15]。在改进方案中, 假设攻击者获得了服务器安全密钥x, 也无法计算得到会话密钥SK。这是因为会话密钥SK=h (Ai‖T‖Bi‖T') , 该表达式由单向哈希函数保护, 攻击者A无法估算, 而且时间戳T和T'也会随着会话时期的不同而改变。因此, 即使攻击者A获得服务器安全私钥x, 也无法推算出准确的会话密钥SK, 改进方案可以保证前向安全性。

3 结束语

基于远程用户身份认证技术是保障网络通信安全的重要组成部分。本文分析了Wen-Li方案中存在的安全缺陷, 提出一种改进的基于动态身份远程用户认证方案, 并对比分析了改进方案的认证原理和安全性。安全性分析表明改进方案在保留原方案优点的基础上, 能够有效抵御身份攻击, 特别是中间人攻击和盗窃智能卡攻击, 同时增强了方案的前向安全性。

用户认证与授权 篇2

OAuth协议为用户资源的授权提供了一个安全的、开放而又简易的标准。OAuth是开放的,任何第三方都可以使用OAuth认证服务, 任何服务提供商都可以实现自身的OAuth认证服务。OAuth是安全的, 该协议允许第三方应用在用户授权的前提下访问在用户在服务商那里存储的各种资源信息, 而这种授权无需将用户的用户名和密码提供给该第三方应用。

OAuth协议已经由1.0版发展到2.0版 , OAuth2.0使用更简单, 适用范围更广, 同时为Web应用、桌面应用和移动应用等提供专门的认证流程, 已经成为主流。互联网中大行其道的第 三方登录 , 基础原理 就是OAuth协议 , 国外Google、Facebook, 国内QQ、人人网、 新浪微博、搜狐微博等都提供了第三方登录服务, 众多的论坛、电商、社交网站, 都集成了这些第三方登录的功能。

2 典型流程

OAuth2.0为了支持不同类型的第三方应用 , 提供了多种授权类型 , 如授权码(Authorization Code Grant)、隐式授 权(Implicit Grant)、RO凭证授权 (Resource Owner Password Credentials Grant)、Client凭证授权 (Client Credentials Grant) 。旨在讨论认证授权的实现方案, 帮助用户理解OAuth协议, 所以选择其中最核心、最难理解、也是最广泛使用的一种授权模式———“授权码”, 进行深入的研究探讨。

设想一个论坛需要使用QQ提供的第三方登录功能的场景, 根据OAuth2.0的官方文档, 其认证、授权的完整流程如图1所示。

认证、授权过程的详细说明如下:

(1) 第三方应用请求资源所有者的授权。授权验证界面以及验证逻辑是是资源所有者提供的, 用户的账号和密码并没有提供给第三方应用。请求中一般要包含: 第三方应用的身份标识、授权类型、回调地址、申请权限范围、 状态等信息。

(2) 如果用户通过认证 ( 或者已经认证过 ) 则使用第三方应用提供的回调地址, 将授权码、状态 (如果客户端包含这个参数, 资源所有者要将这个参数原样返回) 反馈给第三方应用。

(3) 第三方应用携带授权码 , 到授权服务器申请访问令牌。请求中需要包含: 第三应用身份标识、密钥, 以及授权模式、授权码、回调地址等信息。

(4) 授权服务 器检查授 权码、第 三方用户 身份 , 如通过, 通过回调地址发放访问令牌, 以及访问令牌的过期时间等信息。

(5) 第三方应用携带访问令牌 , 到资源服务器申请相应的资源, 如用户的Open ID、用户名、头像、联系人等。

(6) 如果访问令牌有效 , 资源服务 器返回相 应的资源 。一般情况下, 获取到用户的Open ID后, 需要在论坛系统中生成一个对应的自有用户, 与Open ID绑定。

3 认证授权实现要点

集成QQ、人人网、新浪微博等公司提供的第三方登录功能, 只开发相应于图1中第三方应用的功能, 比较容易实现,其网站上都有详细的技术文档, 但如何时实现认证授权服务,资料和技术方案相对较少, 但认证授权服务器端开发也有很广泛的需求, 如公司内部多个系统间整合, 实现用户资源共享、避免重复注册登录等。

OAuth2.0的开源解决方案不是很多 , 目前Java语言较为成熟的是Apache的Oltu, 其前身是amber, 现在改名为Oltu,由Apache来更新维护。文档比较少是开源软件的通病, 这在Oltu项目上体现得尤为明显 , 其官方网站上只有短短的几行说明文字 , 以及几段 示例代码 。通过仔 细地研究 分析OAuth2.0协议、官方提供的测试代码 , 基本完成了第三方登录的认证授权服务器端算法, 下面针对其中的关键步骤进行说明。

根据认证 授权流程 , 分别使用3个Servlet: Res Owner Servlet ( 资源所有 者 ) 、Authorize Servlet ( 授权服务 器 ) 、Res Servlet (资源服务器 ) 来模拟实现相关的处理。

3.1 资源所有者

当收到第三方应用的认证申请时, 资源所有者引导用户进入用户名、密码输入界面, 用户提交信息验证通过后, 发放授权码。用户验证、发放授权码的关键代码如下:

3.2 授权服务器

当第三方应用通过认证获取到授权码之后, 携带授权码向授权服务器申请访问令牌, 授权服务器对授权码、第三方应用的身份进行验证, 如通过, 则发放访问令牌, 需要注意的是, 安全起见不要通过GET方式传递相关数据, 最好通过HTTPS协议。关键代码如下 :

3.3 资源服务器

当第三方应用获取到访问令牌后, 携带访问令牌向资源服务器申请相关的资源, 示例代码中以JSON格式返回用户ID及用户名, 第三方应用拿到用户信息后, 完成登录操作 (首次登录时, 需绑定用户)。关键代码如下:

4 安全分析

如果资源所有者认证用户身份通过后, 直接发放访问令牌, 省略流程中的 (2) 和 (3), 是不是协议更加简洁高效?究其原因是, 有以下的安全考虑:(1) 用户提供的回调地址是一个不太安全的信道, 不适合传递访问令牌这样的敏感数据, 访问令牌可能会被一些非法的监听程序获取;(2) 申请访问令牌时, 会验证第三方应用的身份, 可确保只有第三方应用才能使用授权码换到访问令牌。

第三方应用向资源所有者申请验证时, 需要提供一个状态参数 (即state), 注意第三方应用应该使用动态数据来生成这个参数, 并在资源所有者返回授权码时, 验证这个 参数 ,不然会存在SCRF (跨站请求伪造) 漏洞。

5 结语

OAuth2.0是目前国际通用的授权方式 , 其特点是认证与授权流程简单、安全, 且支持Web应用、桌面应用以及移动应用等多种类型, 在互联网中得到了广泛的应用。给出基于Apache的Oltu实现OAuth2.0认证授权的技术方案 , 对于类似开发有直接的指导借鉴意义。

摘要：分析了OAuth2.0“授权码”认证授权模式的详细流程,给出了Java编程实现认证授权服务的关键代码,并对使用中需注意的安全问题进行了分析。

用户认证协议的安全分析 篇3

关键词：Needham-Schroeder协议,规范化,Casper和FDR2

1 概述

当今, 企业、政府或个人每天都需要通过网络进行信息交换。随着网络的普及, 安全问题也日益突出。认证是安全通信的基础, 也是网络安全中最重要的一个安全目标, 所有其他的安全属性例如完整性、不可否认性、可信性等都依赖于通信双方的认证。因此, 很多安全认证协议被提出。但协议的设计极其容易出错, 使之不能正常工作。在实现和使用这些协议前, 他们声称的安全属性应该被验证, 而普通的常用的方法是模拟。模拟只能证明模拟的协议在特定的模拟环境下可以达到的安全目标。而对于正常的各种情况无法真实反应。需要一个更有效的方法来完成这个功能。模型检测就是其中之一。通过模型检测协议的安全属性可以在系统能达到的任何状态被验证。常用的工具是Ban logic[5,6], CAPl-es[2]和SPIN[3,4], 安全协议的正式验证仍然是一个新的领域。文献1和文献7采用BAN逻辑对特定协议进行了验证和分析。但由于BAN逻辑存在着初始假设没有明确依据的方法、协议理想化、语义定义不明确、对协议的攻击探测能力较弱等问题, 使得协议分析的结果还有待进一步验证。在这篇论文中, 我们采用Casper和FDR2工具对一种经典的用户认证协议进行了模型检测和验证。这种方法不是新的, 只是将这种方法应用在用户认证中是之前没有的。

2 协议描述

经典的Needham-Schroeder用户认证协议是基于对称加密和第三方仲裁机构的。整个系统的结构包括申请发起用户、第三方仲裁机构和目标用户三个部分。每个用户都有与第三方仲裁机构共享的秘密密钥。当用户之间要进行通信时, 需先通过第三方仲裁机构完成用户之间的认证。认证过程如图1所示:

A、B是用户的身份, S是第三方仲裁机构的身份, Na是用户A产生的随机数, Nb是用户B产生的随机数。Kas是用户A与第三方机构S的共享密钥, Kbs是用户B与第三方机构的共享密钥, Kab是第三方机构为用户A和B通信产生的会话密钥。我们给出对应的协议描述如下:

第一步中, 用户A向第三方第三方仲裁机构S发出申请自己想和用户B通信的请求, 第二步:收到消息的第三方仲裁机构查找与用户的共享密钥Kas, 并产生用户A、B之间通信的会话密钥Kab, 用与用户B的共享密钥Kbs加密信息Kab, A即{Kab, A}Kbs, 然后将Na, B, Kab, {Kab, A}Kbs信息用Kas加密之后发送给用户A, 在第三步中, 用户A用Kas解密收到的信息, 得到与用户B的会话密钥Kab, 将{Kab, A}Kbs发送给用户B。第四步:用户B用与第三方仲裁机构的共享密钥解密收到的信息得到Kab, A, 然后生成一个随机数Nb, 用得到的会话密钥Kab加密之后发送给用户A。第五步:用户A收到B的信息后, 用Kab解密得到随机数Nb, 计算Nb-1, 并用会话密钥加密后发给用户B, 用户B收到信息后, 得到A是合法用户, 从而认证A的身份, 认证过程结束。

3 协议的形式化验证

根据协议中用户的工作方式, 我们选择模型检查器FDR2来验证模型的安全性, 这是一个基于并发理论和CSP的模型检测器。它主要用来检查系统的安全属性例如访问控制、认证、电子商务、移动代理、web服务、AXML文档等。FDR2中的规范化语言是CSP。但使用这种语言来模型化系统是耗时的并且易于出错。所以我们使用Casper产生CSP模型。Casper传递安全协议的规范给CSP以便于被FDR2分析。它也可以用于传递输出消息到可读格式。

验证认证协议的第一步是用Casper模型化协议。协议的模型化包括两部分:带有形式变量的模板参数的协议描述和协议实际使用的场景描述。形式变量最终会被实际变量所替代。

关于用户认证协议的模板如下:

协议的描述用来规范化消息交换。第1步对应协议中的第1步, 用户将自己的身份A、用户B的身份B和随机数Na发给第三方机构。第2步对应协议第2步, 第三方机构回复信息给用户A, 用户A用密钥Kas解密消息得到Na, B, Kab, {Kab, A}Kbs, 与自己存储的Na比较看是否相等, 若相等证实信息是第三方机构发来的。第3步对应协议第3步, 用户A将{Kab, A}Kbs发送给用户B, 用户B解密信息, 得到Kab, A, 从而知道是用户A要与自己通信。第4步对应协议第4步, 用户B生成一个随机数Nb并用Kab加密之后发送给用户A来验证A的身份的真实性。用户A解密得到Nb。第5步对应协议第5步, 用户A将得到的随机数减一, 用Kab加密之后发送给用户B, 用户B比较自己存储的随机数与收到随机数之间是否差一, 若是, 认证通过。

我们只给出了一对用户之间认证的模型, 事实上, 所有用户之间的通信都是相同的, 因此检测一对用户结点的安全属性是足够的。如果对一对用户结点有效, 那么对所有用户节点都有效。这对FDR2的验证也是非常有益的。如果有很多个用户结点同时验证的话, 机器的内存会全部耗尽, 检查无法终止。

定义了协议的模板后, 需要检测的安全属性也就规范化了。在用户认证协议中, 安全属性是用户之间的认证。相应的输入文件是#specification。这个认证规范可以用下面的声明来完成:Agreement[A, B, [Nb]]协议规定A被B认证, Agreement[B, A, [Nb]]协议规定B被A认证。

正如我们之前提到的, 协议的安全验证不是在协议的模板上来完成, 而是在一个特定的场景中。对用户认证协议来说, 场景包括二个部分:协议的初始方 (想去被认证的用户) 和响应方 (第三方仲裁机构和执行认证的用户) 。场景的定义使用真实变量来给出:

在模型化协议的最后一步是关于恶意分子的规范说明, 恶意分子可以破坏协议, 它知道所有用户和第三方的身份, 由于本协议是建立在第三方仲裁机构是可信的、公平的基础上的。如果第三方机构与恶意分子勾结来产生对应的会话密钥Kis, 并产生一个随机数am, 那相应的恶意分子的场景描述如下:

完成输入文件后, Casper用来生成协议的CSP规范, 这个规范用作FDR2的输入。完成协议的模型化之后, 在linux环境中采用FDR2进行验证, FDR2验证的第一步是构造模型化系统的状态。然后指定的属性在每种状态下被验证。如果在每个状态下都可以通过验证, 则协议的属性是安全的。否则被认为是无效的。在正常的状态下即只有用户和第三方仲裁机构的情况下, 协议运行正常, 认证安全属性得到验证。在有恶意分子存在情况下或者第三方仲裁机构与恶意分子勾结情况下, 协议的认证安全属性验证错误。由此可以分析出Needham-Schroeder协议的安全性有待改进, 可以对第三方仲裁机构设置可信值来评估他的真实可信性或者采用公钥基础设施来进一步完善协议, 从而提高协议的认证安全。

4 总结

在这篇论文中, 我们演示了如何用规范化验证技术来检测一个安全协议的有效性。使用的工具是Casper和FDR2。这个方法也可以适用于任何模型检测。首先, 使用验证工具的规范化语言明确规定协议的各个部分。转换成一个验证执行的实际协议。这步很重要, 如果模型错误或者与实际协议比较缺少相关限制条件的话, 验证结果将会出错。接下来制定需要验证的安全属性。在这里我们只验证了认证属性, 其他的属性也可以被验证。最后一步是实际执行的验证情况。FDR2证明了该协议的安全性有待提高, 没有达到安全目标。接下来我们可以完成对称密钥的建立或者公钥基础设施的改进等工作, 协议的使用范围可以进一步扩展。

参考文献

[1]田建波, 王育民.认证协议的形式分析[J].通信保密, 1998, 76 (4) :8-12.

[2]John D.Aprshall, an analysis of the secure routing protocol for mobile ad hoc network route discovery:using intuitive.reasoning and formal verification to identify flaws, Msc thesis, Florida State University, 2003.

[3]Davor Obradovic, Formal Analysis of convergence of routing protocols, PH.D thesis, university of pensylvania, 2000.

[4]Todd R.Andel, Formal Security Evaluation of ad hoc routing protocols, PH.D thesis, , Florida State University, 2007.

[5]张玉清, 李继红, 肖国镇.密码协议分析工具—BAN逻辑及其缺陷[J].西安电子科技大学学报, 1999, 26 (3) :376-378.

[6]张玉清, 吴建平, 李星.BAN类逻辑的由来与发展[J].清华大学学报, 2002, 42 (1) :96-99.

用户认证与授权 篇4

关键词：tacacs,认证授权,AAA

1 省级电信运营商数据网设备远程管理现状及问题

网络设备作为电信运营商的基础生产资源, 对于企业的重要性不言而喻, 近年来随着网络安全形势的日益严峻, 网络设备的安全性一直被运营商视为重点研究和提升方向。

网络设备的安全性主要有IOS漏洞、BGP可靠性、路由冗余、访问控制、远程安全管理等, 其中以远程安全管理引起的安全问题较多, 例如远程暴力破解、操作无法审计等。

目前电信网网络设备远程管理的现状及问题主要有:

(1) 普遍使用telnet方式远程登录设备。telnet是一种非加密传输协议, 在开放的互联网上可被捕获和破解, 容易被攻击者利用。因此建议仅在可信网络中使用telnet, 在开放网络环境中采用加密协议的SSH方式。

(2) 普遍设置了访问控制源地址, 但源地址多为办公环境的大段地址。办公环境中主机、个人电脑的安全防护水平比较复杂, 比较容易感染电脑病毒, 一旦某台电脑被中木马, 将对网络设备造成管理风险。

(3) 普遍通过网管系统实现了账号集中认证, 但无法实现授权, 用户登录设备后获得统一的权限, 无法对低权限用户进行限制。

2 集约化维护环境下的问题分析

目前电信运营商的网络运维都在推行集约化, 即对原市公司负责维护的汇聚层以上设备上收至省级统一监控、维护, 在集约化维护的大环境下, 设备的远程登录维护和权限控制显得尤为重要, 现阶段的主要问题有:

账号混用, 尤其是地市维护人员, 班组人员基本共用维护账号, 对于操作审计带来极大难度。

(1) 权限设置难道较大。权限设置依赖在设备本地配置level命令集, 华为、中兴设备支持该功能, 但阿朗设备不支持。即便华为、中兴设备可在本地调整每个level账号的可执行命令, 但配置量较大, 调整某一级别账号的可执行命令时, 需要在全部设备上进行配置, 工作繁琐且易出错。

(2) 远程登录不安全、不方便。随着集约化后省公司维护工作的加重, 维护及时性要求较高, 因此维护人员需要随时随地安全的登录设备。以往通过telnet到内网某台设备, 再跳转登录的方式即不方便, 也不安全。

(3) 集约化后, 地市维护人员不再承担SR/BRAS设备的主要职责, 但仍需要部分业务配置权限。因此在技术层面上, 需要合理划分省公司维护人员、地市维护人员、监控人员的权限。

3 一次性口令认证系统的方案设计

为解决集约化维护工作中权限分配、远程安全接入、命令精确授权的问题, 山东电信利用一次性口令认证系统, 设计并部署了“数据网远程维护登录方案”。

3.1 系统架构

3.1.1 系统组网及安全设置

一次性口令认证系统通过接入路由器连接163、DCN、CN2网, 打通DCN、CN2中的主要MPLS_VPN通道, 并为跳板机UGate分配各网、各VPN的地址。

出口部署防火墙, 严格设置ACL规则, 只允许来自自163网到跳板机UGate的SSH连接。

同时, 在网络设备上设置远程登录源地址限制策略, 只允许来自跳板机UGate的IP登录。

3.1.2 系统功能组件

一次性口令认证系统主要分三个组件:

(1) 跳板机UGate

该部分主要提供远程跳板功能, 用户登录跳板机后, 再从跳板机登录网络设备。同时, 在跳板机上可为用户分配资源列表, 例如, 对某一地市维护人员, 可在跳板机UGate上分配该地市的网络设备, 此用户登录跳板机Ugate后只能访问本地市的设备。

(2) 认证组件ES

该部分是整套系统的核心, 又分两个认证模块:

1用户登录跳板机UGate时, 承担Radius认证功能。

用户登录跳板机UGate时采用动态口令的方式, 此时UGate将登录信息发送到ES进行鉴权, ES需匹配账号名、令牌卡号、令牌动态口令, 鉴权完成后ES返还信息至跳板机UGate。

因此, ES承担了跳板机Radius认证、动态口令认证的功能。

2承担网络设备的tacacs认证功能。

ES同时作为网络设备的tacacs服务器, 对网络设备的账号进行认证、授权。

(3) 数据存储

数据存储主要是存储服务器和磁盘阵列, 承担记录登录日志、操作日志的功能。

3.1.3 业务流程

管理员在一次性口令认证系统中为用户分配账号、口令卡, 用户使用口令卡登录跳板机UGate, 在跳板机中选择资源, 访问网络设备;登录网络设备时再由网络设备向ES发起tacacs认证请求, 认证通过后用户才能成功登录网络设备, 同时, 用户每执行一条命令, 网络设备都会向ES进行命令鉴权, 通过后用户才能在网络设备上成功执行命令。

其中的具体流程如下:

(1) 用户登录跳板机

(2) 提交认证要素, 帐号、静态口令+动态口令的组合

(3) 跳板机向ES发起认证请求

(4) ES认证系统完成口令比对权限鉴别

(5) ES认证系统返回认证结果

(6) 跳板机允许/拒绝用户登录, 若允许显示用户访问列表

(7) 登录跳板机, 选择可访问的资源 (网络设备)

(8) 跳板机实现访问控制

(9) 登录网络设备

(10) 目标网络设备向ES认证系统发起tacacs认证请求, 进行静态密码验证

(11) Tacacs认证成功, 目标网络设备登录成功;认证失败则退出登录

(12) 用户在网络设备上执行操作命令

(13) 目标网络设备向ES认证系统发起tacacs命令认证请求

(14) tacacs鉴权成功, 用户成功在网络设备上执行命令, 获取执行结果;tacacs鉴权失败, 则提示用户无权限执行。

3.2 账号认证、授权方案

为实现网络设备远程管理的账号集中认证、命令精确授权, 需要三个前提条件:

(1) 登录入口统一

(2) 用户唯一识别

(3) 系统和设备均支持且配置tacacs命令授权

一次性口令系统跳板机可以解决第1条问题;人手一个的口令卡可解决第2个问题;ES认证系统和网络设备均支持tacacs认证和命令鉴权, 解决第3个问题。

所以可以利用一次性口令认证系统开展账号认证、命令授权。

3.2.1 五元素

系统中含五个关键元素:账号、角色、设备管理范围、账号级别、命令集, 详细描述如下:

(1) 根据员工姓名, 分配唯一识别的帐号名和口令卡;

(2) 根据集约化维护工作的推进情况, 用户可分为三类角色:

(3) 根据网络部署情况, 数据网络设备范围如下:

根据不同的账号角色, 分为三个级别

(5) 根据账号级别的不同和不同厂家的设备, 设置命令集, 命令集有两种方式

1白名单方式, 用户仅可执行命令集中的命令, 其他命令均不能执行。例如监控人员只可执行display、ping命令。

2黑名单方式, 用户不能执行命令集中的命令, 其他命令均可以执行。例如地市维护人员不可执行bgp、aaa等命令。

3.2.2 角色授权方案

针对不同的网络, 将五元素合理组合, 即可为用户进行精确授权。以城域网设备为例描述。

3.2.3 用户远程登录方式

全省数据维护人员均需要通过一次性口令认证系统登录网络设备, 登录过程中需要两次认证:

(1) 登录UG跳板机时, 需要用户名和令牌卡动态口令认证;

(2) 登录网络设备时, 需要tacacs账号和密码。

4 基于tacacs+协议的认证授权实现方式

4.1 Tacacs+协议简介

在网络中 , tacacs+ ( Terminal Access ControllerAccess-Control System Plus) 是一种为路由器、网络访问服务器和其他互联计算设备通过一个或多个集中的服务器提供访问控制的协议, 提供了独立的认证、授权和记账服务。

目前网络设备中普遍支持tacacs+协议, 可利用该协议实现账号认证、命令授权、授权记账功能。

本文描述的账号集中认证、命令精确授权都是基于tacacs+协议实现的。

4.2 数据网主要设备类型的tacacs配置

数据网中常见网络设备的tacacs认证、授权配置思路基本一致, 大体分三个步骤:

(1) 配置tacacs服务器, 在本文中指向ES认证服务组件IP。

(2) 配置tacacs协商密钥。

(3) 配置aaa认证采用tacacs模式。

(4) 配置aaa授权采用tacacs模式。

(5) 配置命令授权级别。

但不同厂家的设备在实现tacacs认证授权细节上不尽相同, 在实践中发现其中的关键点在于账号默认级别、默认权限和命令鉴权顺序上, 这些关键技术将直接影响整个系统方案的设计, 因此下面主要介绍三个主流厂家的设备技术特点。

4.2.1 华为设备

适用于NE40、NE80、NE40X8、NE5000, 其他型号未经验证。

(1) 账号级别

华为设备账号默认划分了16个级别, level0至level15, 但默认情况下level3基本已是最高权限, level0至level2的账号限制较多。

通过tacacs认证的账号, 需要在tacacs服务器上为账号配置level级别, 此处建议均配置为level3级, 因为命令的授权可完全由ES认证服务器承担, 不依赖设备本地的账号权限设置。至于为何配置最高权限的level3级, 将在命令鉴权顺序部分描述。

(2) 认证顺序

账号认证可选择先local或者先tacacs, 为了维护安全的考虑, 可在设备上设置local账号, 当tacacs服务器出现故障时以保证维护人员登录设备。此时应该设置先local后tacacs, 因为如果设置先tacacs, 一旦tacacs服务器出现认证故障 (非网络故障) , 则系统不会切换到local认证。

(3) 命令鉴权顺序

用户登录网络设备后, 设备会自动为账号匹配一个level, 执行命令时, 系统将按照先本地后tacacs的顺序执行命令鉴权, 如果本地鉴权失败, 则命令无法执行, 不再送往tacacs服务器鉴权;如果本地鉴权成功, 则将命令送至tacacs服务器进行再次鉴权, 鉴权成功后命令才可执行。

如果为tacacs账号设置的级别过低, 当执行命令时, 可能命令在本地就被过滤掉, 无法达到由ES认证服务组件进行命令鉴权的目的, 所以建议tacacs账号均设置level3, 此时几乎所有命令都会通过本地鉴权。

(4) 命令鉴权配置

华为设备可对不同级别的账号配置使用tacacs鉴权, 例如可对level2、level3的账号配置tacacs命令授权, 其他不配置, 则只有level2和level3的账号执行命令时, 才将命令送往ES认证服务组件鉴权, 对level0、level1、level4及其他级别的账号, 沿用本地命令鉴权规则。

在实践中, 建议设置对level2和level3的账号进行tacacs命令授权。

此处还存在另外一个问题:local账号如果也设置成level3, 一旦ES认证服务组件认证故障 (非网络故障) , 则local账号执行命令将出现无法执行或者执行异常缓慢的情况, 所以建议local账号级别设置成level4或者更大。

华为tacacs认证授权配置命令参考如下:

4.2.2 中兴设备

适用于M6000, 其他型号未经验证。

中兴设备的tacacs配置与华为类似, 但也存在几点不同。

(1) 账号级别

系统默认设置15级账号, 只有level15的账号才具备最高权限, level14和以下级别的账号均不同程度受限, 且受限程度明显。这与华为设备不同, 华为level3已基本具备最高权限。

所以在tacacs服务器上为账号配置level级别时, 建议直接赋予level15。

(2) 账号认证顺序和命令鉴权顺序与华为设备相同。

(3) 命令鉴权配置

因上文所述, tacacs账号均被赋予level15级别, 所以在配置命令鉴权时, 应对level15的账号进行命令授权。

因账号最高级别为15, 而level15的账号均需要到tacacs服务器鉴权命令, 所以当tacacs服务器认证故障时, 将影响最高权限账号的命令操作, 即便是level15的local账号, 也需要到tacacs服务器鉴权, 所以实践中需要进行特殊配置:在level15的local命令集中增加“no command-authorization 15”命令, 当tacacs服务器认证故障时, 可通过local账号登录, 取消tacacs命令鉴权。

(4) tacacs协商机制

中兴设备在配置tacacs时, 会要求配置协商机制, 可选ASIC、PAP、CHAP三种方式, 其中ASIC为明文协商, PAP、CHAP为加密协商, 实践中可根据tacacs服务器的配置灵活选择, 一次性口令认证系统ES组件暂只支持PAP方式。

中兴tacacs认证授权配置命令参考如下:

4.2.3 阿朗设备

适用于7750, 其他型号未经验证。

阿朗的tacacs配置较简单, 因为阿朗设备本身不提供账号分级和命令授权功能, 其产品设计中默认含有tacacs或者radius服务器来提供账号认证、授权。

故只需要在设备上配置tacacs服务器即可。

阿朗tacacs认证授权配置命令参考如下:

5 结束语

通过部署上述技术方案, 极大提升了网络设备的安全远程维护能力, 为集约化工作提供了强有力的支撑:

帐号统一集中认证, 使得设备登录可管可控

集中授权, 使得设备登录管理, 清晰透明

建立统一认证中心, 可为以后其他系统共同使用 (提供标准认证接口) , 避免帐号混乱

参考文献

[1]中国电信一次性口令认证系统功能规范

[2]Tacacs协议技术规范

[3]华为路由器配置规范

[4]中兴路由器配置规范

用户认证与授权 篇5

信息化工程的建设在为神华带来巨大经济绩效的同时, 也对神华的管理、协调、运营和可持续发展提出了巨大的挑战。作为信息化管理的众多内容之一, 信息系统用户业务授权及合规性控制管理是其中非常重要的一个管控环节, 一旦用户业务授权存在风险可能会出现多种问题, 影响非常大。用户业务授权管理关注的核心包括很多, 如:用户在系统内所授予的授权是否合理 (授权最小化、以岗定权、不相容业务操作是否分离) ;系统中关键、敏感的操作或数据是否只能够被限定的人员所访问等。此外信息系统中用户业务授权相关缺陷或问题也是内外部审计机构关注的重点, 因此如何确认用户业务授权的合规性, 加强用户业务授权的管理, 已是当前神华面临的重要管理课题与挑战。用户业务授权及合规性控制管理系统项目 (以下简称:用户授权及合规性系统项目) 为神华集团用户授权及合规性管理奠定了坚实的基础。

用户授权及合规性系统与实现

用户授权及合规性系统项目根据中央巡视组、国资委、内外部审计要求, 以加强集团内控体系建设, 提升信息系统用户业务授权、合规性控制的管理能力与水平, 实现“管控系统化、风控集成化、运营高效化、操作自动化”为目标进行实施。通过本项目建设, 有针对性地补充了制度流程, 提高集团的整体风险防范水平;建立了完善的集团用户授权及合规性控制管理体系, 规范各层级管理和业务人员的行为, 有效防止舞弊事件发生。

在建设过程中, 为提升企业信息化应用系统角色的规范化管理, 对现有管理体系进行补充和完善, 使其更加标准化, 更能有效防范经营中的风险, 建立既符合内外部审计及管理部门要求又符合集团实际的权限管理相关管控体系。

建立集团统一的职责互斥规则库

根据外部监管、审计机构对于用户授权及合规性的要求及职责互斥的要求, 结合集团信息化应用系统现有的业务流程, 梳理了各项业务活动间职责互斥可能带来的舞弊事件, 最终设计了集团统一的一套职责互斥规则库。对于业务流程中相关业务活动存在职责互斥带来的风险不同, 在职责互斥矩阵确定了存在风险的属性, 即高、中和低三种类型;同时, 由于几个低风险的职责互斥权限授予同一个用户时, 可能导致高风险的舞弊事件发生的可能性增大。

职责互斥规则库是识别业务流程中是否存在的风险的依据、是信息化应用系统业务操作规范性的标准、是信息化应用系统用户权限合规性治理的基础, 根据内外部监管、审计要求及企业管理水平提升, 职责互斥规则库也需要进行相应调整。

实现集团信息化应用系统角色标准化

角色标准化工作是用户权限合规性治理、业务活动体系建设工作的前提, 为进一步更好地推动后续工作的开展, 完成角色标准化治理工作, 将10228个角色进行规范、整改。确定各应用系统角色命名及描述规范、建立角色管理标准化方案、并以职责互斥和最小授权的原则为标准, 确保系统中单个角色的权限符合其业务操作需求的同时保持规范性和标准化。

信息化应用系统用户权限治理

权限治理是以定义在合规性系统中的职责互斥规则库为标准和原则开展的, 通过运行风险分析报告查询出各信息化应用系统内及系统之间系统业务操作上存在的互斥风险点。依照互斥分析结果中存在的风险点, 进行相应系统用户的互斥职责和敏感权限治理, 确保职责互斥规则库合规、合理、有效的实现管控及合规性管理目标, 满足外部监管机构监督和内部控制管理提升的要求。

完成集团信息化应用系统业务活动体系设计工作

为便于用户申请信息化应用系统权限, 建立了一套统一的业务活动体系。该体系基于各系统业务流程的梳理、现有的技术角色, 梳理出业务活动的清单, 并通过合规性系统将其与技术角色进行关联。方便用户在申请授权时通过选择业务活动在系统中准确定位所需的本单位角色, 提升权限管理效率, 实现用户快速、准确及自动授权。

用户业务授权及合规性管理系统核心功能

用户授权及合规性系统通过角色标准化整改、建立职责互斥规则库、权限治理、业务活动梳理作为项目数据标准及规范化依据, 针对合规性控制管理、系统角色管理、用户授权管理、紧急访问管理这四大管理领域业务流程进行细分, 优化并制定出每一个业务子流程在未来系统产品中的解决方案以及所对应的用户类型, 解决跨组织访问、岗位角色映射等重点难点问题。其核心功能如下:

合规性控制管理

梳理被管控系统相关职责分离规则以及敏感访问规则, 在用户授权及合规性管理系统中定义这些规则以及例外处理, 报表的形式为公司管理层展现目前企业ERP等核心应用系统中职责分离潜在的风险, 并通过其特有的模拟机制, 为公司相关人员在给用户分配权限之前提供预警 (预防型控制) 。对预警结果采取系统授权变更、手工补偿控制、问题接受等不同的策略应对, 满足用户的授权需求, 同时满足内外部监管审计要求。建立起职责互斥规则库、Basis敏感事务补偿规则分配、新增补偿需求、分配补偿等一系列的维护和管控流程, 全面的保持系统用户的合规性管理要求。

系统角色管理

对角色的详细权限 (事务代码和授权对象的组合) 进行分析, 识别风险, 对风险所产生的源头进行有效的管控;对角色的命名进行有效规范, 解决角色创建和维护过程中命名混乱的问题。在角色创建过程中实现事前风险分析、角色命名标准化控制, 保证各被管控信息化应用系统角色的标准性、规范性、统一性。

用户授权管理

用户授权新建、变更、冻结、解冻、复核操作与合规性控制管理模块紧密结合, 利用该模块中定义的职责分离控制和敏感访问规则, 在用户申请授权阶段对用户所需要的权限集合进行分析, 在第一时间为相关人员提供风险预警。同时, 在授权申请、冻结/解冻申请过程中, 对于用户跨单位、跨模块的操作进行提醒, 防止误操作的发生, 提高授权类运维管理的准确性。通过针对企业用户业务授权管理需求进行分析, 提供用户便捷、自主、快速的权限选择方案, 并在合规性系统予以实现, 简化并规范各应用系统权限管理, 提升运维权限管理效率, 实现用户快速、准确、自动授权管理。

紧急访问管理

对于需要临时使用敏感权限的情况, 可以申请使用紧急访问, 系统实现了紧急账号访问申请、审批、使用、监控、复核等系统管控功能, 在紧急账号系统操作过程进行事前审核、事中监控、事后审计。

意义与价值

基于口令的安全用户认证模型 篇6

随着网络在人们生活中的不断深入, 网络安全越来越受到人们的关注。身份认证是网络安全中最令人关心的热点问题之一。通常, 用户在使用网络服务前必须向认证服务器提供一个对应的身份标识以及相应的秘密信息用于身份认证, 网络服务提供商根据认证结果决定是否提供所需的网络服务及用户权限。目前网络应用大致利用以下三种类型的秘密信息实现身份认证机制:用户拥有的, 比如利用智能IC卡存放一个足够大的秘密随机数 (128/256 b) 进行身份认证;用户知道的, 比如用户利用自选的口令进行身份认证;用户的特征, 比如用户用自身的生物特征, 例如指纹、声纹、视网膜、脸型等进行身份认证。在这三类机制中, 由于成本最低、实施方便使得基于口令的认证方式应用最为广泛。

1 相关工作

目前主要应用两种口令管理方式来增强口令的安全性:一种是一次口令 (OneTime Password, OTP) 的方式[1,2];另外一种是基于Hash函数的口令管理方式。对于一次口令的方式中用户在每次认证的时候, 所提交的认证信息都是不同的, 使整个认证过程更加安全, 从而能够较好地应用在Internet环境下。但这样的OTP认证系统每隔一段时间需要用户重新初始化系统, 这使得服务器的额外开销比较大;另外, 用户在认证时需要进行多次Hash运算, 在应用上也不够方便。

目前的研究热点主要集中在基于Hash函数的口令管理方式上, 此方式的特点是真正的口令是由Hash函数计算产生, 如Gabber等提出的LPWA[3], Ross等提出的PwdHash[4], Halderman等提出的Password Multiplier[5]和Yee等提出的Passpet[6]方案。LPWA和PwdHash方案都是将用户主口令和站点域名的Hash值作为真正的账号口令。这两个方案解决了多个口令的维护问题, 但由于Hash函数的运算速度很快, 它们容易遭到暴力破解。Password Multiplier和Passpet方案首先用主口令和用户信息经过多次执行Hash运算得到中间变量v, 并保存在本地主机上, 然后使用主口令、v和Web站点域名多次执行Hash运算得到账号对应的口令, 两次计算中都执行迭代Hash运算, 增加了计算的时间复杂度, 提高了暴力破解的难度。以上基于Hash函数的方案存在明显的安全漏洞, 只要攻击者攻破主口令, 就可以计算出用户的所有账号口令, 并且用户不能修改单个账号的口令。

Gajek等[7]提出应用每个用户使用高熵的口令并且不同的帐号使用不同的口令的方法来增强口令的强度, 但没有解决用户需要记忆多个口令的问题, 并且实现方法复杂。Bruce Schneier提出的Password Safe方案[8], 将用户所有的帐号和对应的口令存储在经Twofish加密算法加密的口令库中, 用户只需要记忆访问口令库对应的主口令就能管理所有的口令, 但将口令文件存储在本地磁盘上, 非常容易被窃取和破坏, 因此不但没有增强口令的强度和安全性, 反而增加了口令的不安全因素。

本文在挑战/响应的基础上, 结合Hash函数的口令管理技术和隧道技术提出了一个基于口令的安全用户认证模型。

2 提出的基于口令的安全用户认证模型

应用Diffe-Hellman密钥交换协议, DES和SHA-512提出了一个基于口令的安全用户认证模型, 如图1所示。此模型既能够抵抗中间人攻击, 重放攻击, 字典攻击和拒绝服务攻击, 同时还能提供完善向前保密。在此模型中客户端连接器和服务器端连接器使用彼此的公钥加密Diffe-Hellman交换参数以抵抗中间人攻击;抵抗重放攻击通过在客户端连接器和服务器端连接器使用挑战/响应方式进行会话密钥建立;引入口令处理器以增加口令的强度, 同时在服务器端引入“挂起”机制以抵抗字典攻击;抵抗拒绝服务攻击通过应用Email Server用于接受服务器发送过了的激活码;为了提供完善向前保密, 客户端连接器和服务器端连接器在创建隧道时随机选择秘密指数, 隧道创建成功后就将秘密指数删除。

提出的模型主要包含:登陆模块, 口令处理器模块, 连接器模块, 数据库模块, Email Server模块。

用户通过登陆模块输入“用户名”和“口令”, 登陆模块将“用户名”和“口令”传给口令处理器模块处理, 连接器模块将“用户名”和处理过的“口令”通过隧道方式传给数据库, 数据库将处理后的结果返回给连接器, 然后通过隧道将结果返回给登陆模块。各模块的功能如下:

登陆模块:与用户实现交互的界面, 向其他模块提出请求, 并显示其他模块的响应。

口令处理器模块:用户注册和修改口令时, 主动检查用户的口令;用户登陆时, 加密用户的口令。

由于一般的用户往往会选择短的、有意义的字母组合或日常生活中常用的号码作为口令以方便记忆, 而这些类型的口令数是有限的, 因此攻击者可以利用电脑将所有可能的口令存放在字典中, 然后快速地遍历字典进行反复猜测与比对, 并在很短的时间内就有可能猜出一个用户的口令。

主动的口令检查在用户注册和试图修改口令的时候就进行。这样就可以有效地消除脆弱的, 易被破解的口令。主动的口令检查对时间和资源也没有太大的消耗, 因为其检查的过程不是一个破解的过程, 而是利用口令本身检查其脆弱性的过程[9]。

登陆时用户的口令被当作DES的密钥用以加密用户名和口令的Hash值, 为了提高安全性这里建议Hash算法使用SHA-512。加密算法被重复25次, 得出结果中包含了11个字符长的字符串和两个字符的“Salt”。在系统校验用户口令时, 系统把经过加密后的口令与Password表中存储的加密字串进行比较, 如果相同则证明用户输入的口令正确。

连接器模块:为模块之间的通信提供加密解密功能。在模块之间建立隧道, 提供相互认证, 分配会话密钥和PFS。g和p是公共的Diffe-Hellman参数, a是A选择的秘密指数, b是B选择的秘密指数。

(1) 连接器A向连接器B发送质询RA;

(2) 连接器B收到质询RA, 计算gbmod p, 并将计算结果和RA一起用A的公钥加密, B再对加密结果{RA, gbmod p}A进行签名操作, 并将运算结果[{RA, gbmod p}A]B和质询RB一起发送给连接器A;

(3) 连接器A将收到结果进行解密, 得到质询RB, 质询RA和gbmod p , A计算gamod p, 并将计算结果和RB一起用B的公钥加密, A再对加密结果{RB, gamod p}B进行签名操作, 并将运算结果[{RA, gbmod p}B]A发送给连接器B;

(4) 连接器B将收到结果进行解密, 得到质询RB和gamod p;

(5) 连接器A和B各自计算gabmod p, 得到共享的会话密钥K, 隧道建立成功。

数据库模块:存储用户的相关信息。

数据库中包含Users, Password和Faillog表。这三个表解决了文献[10]中提到的如何既能防止字典攻击, 又能防止拒绝服务攻击的问题。Users表通过访问Password表获得用户的口令;Password表只能被Users表访问, 提高口令的安全性;Faillog表记录用户登陆失败的情况, 设置一个阈值, 与阈值比较, 超过阈值将该用户挂起不允许该用户再次登陆, 这样可以完全抵制字典攻击;并将一个生成的激活码发送给该用户的Email中, 以便用户再次激活帐号, 这样可以抵制拒绝服务攻击。三个表的关系如图2所示。

下面给出这三个表的具体的结构。

Users表用来记录用户登陆时认证和授权的信息, 其结构如下:

用户名:标识一个惟一用户, 设为主码, 这里用用户的邮箱地址作为用户名。

连接Password:用来连接Password表, 存取用户的口令。

用户标识:标识用户的安全级别。只有当用户的安全级别高于文件的安全级别时才可以对文件有“读”访问权[10]。

组标识:标识用户所属的组。

状态:标识用户帐户的有效性。有两个状态:“有效”和“挂起”。它能完全杜绝字典攻击。

激活码:激活用户帐户, 能防止拒绝服务攻击。

Password表用来记录用户的口令, 只能由Users表来连接调用和读取, 对其他任何操作透明。其结构如下:

用户名:同表1的“用户名”字段。

口令:这里实际存储的是加密后的口令。

Faillog表用来记录用户用户登陆时的一些相关信息, 其结构如下:

用户名:同表1的“用户名”字段。

次数:统计用户登陆失败的次数。

时间:记录最近一次登陆失败时间。

在此安全模型中另外还包括例外处理模块, 各例外处理模块的功能如下:

用户名不存在例外处理模块:向调用模块返回“用户名不存在”, 并进行相应处理。

状态无效例外处理模块:向调用模块返回“状态无效”, 要求用户输入激活码, 并与Users表中该用户的“激活码”字段比较, 相等时激活用户的帐号。

密码不正确例外处理模块:向调用模块返回“密码不正确”, 并进行相应处理。

Email Server:用于接受数据库发送过来的激活码, 可以防止拒绝服务攻击。

3 基于C/S方式的原型实现

本文提出的基于口令的安全用户认证模型的实现可以采用B/S方式, 也可以采用C/S方式。在此给出一个基于C/S结构的原型实现, 如图3所示, 客户端包含登陆模块, 口令处理模块和连接器模块;服务器端包含连接器模块和数据库。

3.1 用户注册

用户输入注册名, 连接器A使用会话密钥K加密用户名并将结果发送给连接器B, B使用会话密钥K解密将结果发送给数据库, 数据库检查用户名是否存在, 并将检查结果返回;用户名通过检测, 用户输入口令;口令处理器主动检查输入口令, 不允许弱口令通过;口令通过检测, 口令处理器对口令加密, 连接器A使用会话密钥K对用户名和加密后的口令进行加密, 并发送到连接器B;连接器B使用会话密钥K解密得到用户名和加密过的口令, 将用户名和加密过的口令发送给数据库, 数据库将用户的相关信息添入表中。

3.2 用户登陆

用户登陆时, 过程如下:

(1) 用户在登陆模块中输入用户名和口令;

(2) 口令处理器加密口令;

(3) 用户名和加密过的口令通过隧道传给数据库;

(4) 数据库验证用户

① 在Users表中查找, 如果用户名存在并且状态为“有效”, 则进入下一步;如果用户名不存在, 转向用户名不存在例外处理模块;如果用户名存在但是状态为“挂起”, 则转向状态无效例外处理模块。

② 通过连接Password字段, 连接Password表。在Password中查找用户名所对应的口令进比较如果相等进入第 (5) 步;否则进入下一步。

③ 在Faillog表查找用户名对应的记录。记录此次登陆失败的时间。将登陆失败次数加1, 比较是否超过最大限制次数。如果超过进入下一步;否则, 转向密码不正确例外处理模块。

④ 将Users表中用户的状态字段改为“挂起”。通过Faillog表中用户最近一次登陆失败时间生成一个激活码 (用于激活用户帐号) , 存储到Users表中用户对应的“激活码”字段并发送到用户的邮箱中, 转向状态无效例外处理模块。

(5) 验证通过, 通过Users表对用户进行初始化。

在客户端使用HOOK (钩子) 技术来加强登陆的安全性。

钩子函数实际上是一个处理消息的程序段, 每当一个应用程序调用函数GetMessage或PeekMessage而恰有一个消息即将被处理时, 系统调用钩子函数。也就是说, 当特定的消息发出, 在没有到达目的窗口前, 钩子函数先捕获消息, 亦即钩子函数先获得控制权。这时钩子函数既可以加工处理该消息, 也可以不作处理而继续传递消息, 还可以强制结束消息传递。系统为每种类型的钩子维护一个钩子链, 最近安装的钩子放在链的开始, 而最先安装的钩子放在最后, 也就是后加入的钩子先获得控制权。

由于最后安装的钩子总是放在最前, 也就是最先获得对消息的控制权。为此可以在客户端每次登陆时, 安装键盘钩子, 钩子截取用户输入的用户名和口令, 发送给口令处理模块和连接器模块, 登陆成功后卸载键盘钩子。由钩子函数来阻断键盘消息在钩子链中的传递, 将消息直接发送给消息接受窗口。本模型创建钩子的核心代码如下:

创建一个键盘线程钩子WHKEYBOARD, 在登陆窗口中SetWindowsHookEx (WHKEYBOARD, (HOOKPROC) KeyboardProc, hInst, GetCurrentThreadId () ) ;

钩子处理函数KeyboardProc如下:

登陆成功后UnhookWindowsHookEx (hook) ;

4 结 语

身份认证是网络安全中热点问题之一, 本文对基于口令的安全用户认证模型进行研究, 应用DES, SHA-512和Diffe-Hellman密钥交换协议提出一个能够有效抵抗中间人攻击, 重放攻击, 字典攻击和拒绝服务攻击, 同时能提供完善向前保密的安全用户认证模型, 并且进行了安全性分析。最后给出了一个基于C/S结构的原型实现。

摘要：对基于口令的访问控制进行研究, 应用DES, SHA-512和Diffe-Hellman密钥交换协议, 提出一个基于口令的安全用户认证模型。此模型可以抵抗中间人攻击、重放攻击、字典攻击和拒绝服务攻击, 同时还能提供完善向前保密。基于提出的安全用户认证模型应用HOOK技术, 给出了一个基于C/S方式的原型实现。

关键词：访问控制,身份认证,弱口令,哈希函数,HOOK,DES,Diffe-Hellman密钥交换协议

参考文献

[1]Lamport L.Password Authentication with Insecure Commu-nication[J].Communications of the ACM, 1981, 24 (11) :770-772.

[2]Haller N.The S/KEY One-Time Password System.RFC1760.1995.

[3]Gabber E, Gibbons P B, Matias Y, Mayer A.How to MakePersonalized Web Browsing Simple, Secure and Anonymous[J].Proceedings of Financial Cryptography′97, Anguilla:Springer-Verlag, 1997:17-31.

[4]Ross B, Jackson C, Miyake N, et al.Stronger Password Au-thentication Using Browser Extensions[A].Proceedings ofthe 14th USENIX Security Symposium[C].2005:17-32.

[5]Halderman J A, Waters B, Fehen E W.A ConvenientMethod for Securely Managing Passwords[A].Proceedingsof the 14th International Conference on World Wide Web[C].Chiba:ACM Press, 2005:471-479.

[6]Yee K P, Sitaker K.Passpet:Convenient Password Manage-ment and Phishing Protection[A].Proceedings of the SecondSymposium on Usable Privacy and Security[C].New York:ACM, 2006:32-43.

[7]Gajek S, Sadeghi A R, Stuble C, et al.Compartmented Secu-rity for Browsers-or How to thwat a phisher with trustedcomputing[A].Proceedings of the 2nd International Confe-rence on Availability, Reliability and Security[C].Washing-ton DC:IEEE Computer Society, 2007:120-127.

[8]Schneier B.Password Safe[EB/OL].http://www.schneier.com/passsafe.html.

[9]董光宇, 高安全等级操作系统及网络服务的标识鉴别机制[D].北京:中科院软件所, 2002.