等保测评2.0：应用身份鉴别（下）

1. 说明

 

本篇文章主要说一下应用测评中身份鉴别控制点中b、c、d测评项的相关知识点和理解，以及高风险判定方面的内容。
注：下文的应用系统不特别指都就默认为属于B/S架构。

 

 2. 测评项

b)应具有登录失败处理功能，应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施；
c)当进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听；
d)应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现。

 3. 测评项b

b)应具有登录失败处理功能，应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施；

3.1. 登录失败锁定策略

 

这个主要靠访谈、测试，当然测试的前提是配合人员同意你测试，不要随便新建账户或者用别人给你的账户测试。
如果存在这个功能一般就是连续登录失败几次后永久锁定或者锁定一段时间。

存在相关的配置页面，就在配置页面截图取证：

 

 

功能是直接写在代码中的，最好还是测试一下，一般来说登录界面会出现提示文字的：

 

 

3.2. 超时退出

存在这个功能的，有配置页面的不多：

 

 

一般都是在代码中或者配置文件中（比如asp.net的web.config）实现，不是很好找到明确的证据，最好还是实际试验下。
比如中午休息前登录，等到14点工作时，刷新下，看看是否已经注销。

 

 4. 测评项c

c)当进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听；

4.1. 高风险

 

说实话，这个以前我是不测的，因为我觉得它和传输保密性的要求重合了。
但是最新版高风险判定指引（5月28日，下同）中明确指出这个测评项可能存在高风险：

 

 

那就最好测一测，鉴别信息在这里指的是口令或者类似的字段，那么实际上就是看口令是否加密传输。

4.2. Https协议

首先查看这个网站是否使用了Https协议，如果使用了，则自然就符合。
不过如果使用Https协议，也要看一看使用Http前缀是否能正常访问，有些网站没有做好配置，导致Http和Https都可以访问。

4.3. 传输口令的Hash值

如果没有使用Https协议，那就看是否在前端对口令进行了加密。
在登录界面，输入用户名、口令提交，然后查看提交的参数是什么：

 

 

通过这个方法，如果你发现口令字段不是明文，也要问清楚其加密的方法，不过对方清楚的概率不大。
你可以输入一个简单的口令，比如1，然后拿着前端传输的口令字段的值，随便去一个在线加密网站对比下，就知道用的什么算法了。
或者你也可以看一看加载的Js文件的内容，前端进行加密一般都引用网上写好的Js文件，从这里也可以进行判断。
大概率来说，如果前端加密，一般都是使用md5算法计算出口令的hash值，然后再进行传输。

 

如果前端传输口令hash值，而后端数据库存储的也仅仅只有口令的hash值，鉴别的方法就是对比前端传入的hash值是否与数据库中存储的hahs值一致。
在这种情况下虽然前端传输的并非口令明文但是实际上还是泄露了鉴别信息。
这个时候，鉴别信息指的就不是口令，而是口令的hash值，此时，明文传输口令hahs值就是明文传输鉴别信息。
如果别人截取到口令的hash值，虽然不能够轻易获得原文，但是可以通过该hahs值和用户名通过应用系统的鉴别。

当然，你直接知道口令明文的话，就可以通过登录界面得到口令hash值，还是同样泄露了鉴别信息。

 

4.4. 加盐

 

对此的防范方法之一就是前端加密方式进行一点点改变比如加盐值（字符串）
当用户访问登录界面时，后端生成一个随机盐值（随机字符串），同时前端也得到这个字符串salt。
此时，前端可以使用以下算法对计算出一个hash值：

MD5(MD5(password)+MD5(salt))

嗯，当然，这个算法你可以自己决定，根据实际情况进行嵌套使用，使用其他的hash算法都是可以的。

然后当这个hash值传输至后端后，数据库中存储的是MD5(password)，后端也有那个随机盐值，也可以使用同样的算法算出一个hash值，进行对比，即可得到结果。
这样的话，别人截取到了这个hash值也没啥用，基本没有办法从hahs值逆向算出原文。
这样就基本实现了鉴别信息防窃听的要求。

4.5. 其他办法

比如使用timestamp方案、nonce方案或者两者都结合的形式，或者其他的什么技术方案。
这个在这里就不介绍了，有兴趣自己可以百度搜索学习下。
其实到了这一步的话，一般都会配置Https的。

 5. 测评项d

d)应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现。

5.1. 刷卡验证

某些系统（比如高速公路相关），会在使用用户名、口令验证的同时，增加刷卡验证的方式。
这样的话，双因素肯定是符合了，但是刷卡验证是不是使用了密码技术，就不清楚了，我不知道刷卡验证的原理。

5.2. 指纹验证

有些银行系统会增加指纹验证的方式，同样，符合双因素，但是有没有使用密码验证，不清楚。

5.3. 加密狗

这个肯定算符合，就不说了。

5.4. 谷歌验证器

其实和等保测评2.0：Oracle身份鉴别（下）中5.2节介绍的认证方式差不多，谷歌验证码生成的时间间隔是一般是30s。
服务器中的应用系统和手机中软件按照同样的算法（当然还包括密钥），同时计算出某个验证码，每30s重新计算1次。
这样服务器和手机都不需要联网，直接对比算出的值就可以了，比短信验证的方式要感觉要好一些。

5.5. 高风险

 

3级系统，且可通过互联网进行访问的应用系统未使用双因素认证，可判定为高风险。
这里说明下，如果使用了双因素但未使用密码技术，不算高风险，因为这里没有提到。
不过到4级系统，如果不使用密码技术，就可以判定成高风险了。

其实要修正的话，要么是属于内网、专网系统，或者对登录后台的Ip地址进行了限制。
或者使用了两次以上的认证，比如要先登录VPN，然后再登录应用系统。
要么就是口令比较强，也可以酌情降低风险……

 

 6. 高风险判定

6.1. 写不写判定理由

现在我们主要根据最新版的高风险判定指引进行高风险项的判定。
其实我在写报告的时候一直有些疑惑，就是判定的理由是否一定要写出来。

举个例子：

 

 

从上图可以看出，6.1.2高风险条款对应的测评项如果不符合，但物理环境可控的话，可以判定为中风险，这是没有什么疑惑的。

但是这里有两个思路：

1. 物理环境可控，不属于满足条件a，可以直接判定为中风险；
2. 物理环境可控，属于补偿措施a，是一种对高风险的修正，所以我需要把修正的过程体现出来。

按照思路1，就直接在测评报告的“表 5-1 安全问题风险分析表”那写个中风险的结果，不需要在报告中体现判定的理由；
按照思路2，就需要在测评报告的“整体测评结果分析”那把这个理由写出来，也就是修正（从高降到中）。

还有一类高风险项，满足条件和措施有不重合的地方，比如4.5.1的b项，假如属于补偿措施的b项中描述的情况，那肯定要把这个理由写出来，这个没什么疑惑的：

 

 

为什么纠结判定理由写不写呢？因为高风险判定是报告抽查时的红线，而判定指引中有不少测评项的满足条件和补偿措施是重合的。
如果你因为测评项的结果不满足某个满足条件，所以直接判定成中风险，到时候检查你报告的人没有get到你的思路那咋办……

所以理论上这种情况是可写可不写，不过好像最好还是都写清楚比较好。

6.2. 怎么写

两种方法，一种在测评项的结果记录中直接把修正的理由给写了，比如：
未能够对非授权设备私自联到内部网络的行为进行检查或限制，但重点区域出入控制严格，非受权人员访问重要区域有专人陪同等措施。
另外一种就是放在整体测评中进行描述。

后来某位网友给的意见是如果修正的理由涉及到整体测评，比如“未能对非法内联进行检查或限制，但物理可控“这种情况。
就属于层面间的修正，应该再整体测评中进行描述。

而如果修正的理由和控制间、区域间、层面间没啥关系的话，就直接在测评项中进行描述，比如：

 

 

如果Linux等非Windows的系统没有部署防恶意代码软件，可以通过补偿措施的a项进行修正。
这个就是控制间、区域间、层面间没有啥关系了，还不如直接在测评项的结果记录中直接描述。

对于这种类型的修正理由，感觉理论上还可以不在测评项、整体测评中描述，直接放在表 4 1修正后的安全问题汇总表中：

 

 

测评报告的两个基础是资产表、记录表。
调研得到资产表，从资产表中选择测评对象，然后进行测评得到记录表。
然后再对记录表中数据进行分析，得到其他的一系列表格和最终结论。
虽然资产表里体现了操作系统是linux，但是没在记录表里体现，直接放进表 4 1修正后的安全问题汇总表中，感觉不太好，有点非主流。

本文始发于微信公众号（疯猫网络）：等保测评2.0：应用身份鉴别（下）