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值，还是同样泄露了鉴别信息。
4.4. 加盐
对此的防范方法之一就是前端加密方式进行一点点改变，比如加盐值（字符串）。当用户访问登录界面时，后端生成一个随机盐值（随机字符串），同时前端也得到这个字符串salt。此时，前端可以使用以下算法对计算出一个hash值：
MD5(MD5(password) MD5(salt))
嗯，当然，这个算法你可以自己决定，根据实际情况进行嵌套使用，使用其他的hash算法都是可以的。
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级系统，如果不使用密码技术，就可以判定成高风险了。
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修正后的安全问题汇总表中，感觉不太好，有点非主流。
精彩推荐
