| 编辑推荐: |
本文介绍了密码的背景和危害、方案设计和架构及如何同零信任的场景结合， 希望对您的学习有所帮助。
本文来自于LiREEBUF，由火龙果软件Linda编辑、推荐。 |
|
密码/口令一直是企业安全中绕不开的一个话题，无数英雄在此折腰，相信不少人都有欲除之而后快的念头，那么我们是否可以干掉密码？又会有哪些挑战？本文既是对干掉密码的实践，以及如何同零信任结合。
一、密码是一剂良药吗？
（1）密码/口令起源
正文开始前，为避免混淆先明确，本文内所说的密码实则是登陆口令，特指静态密码，而非对通讯或内容加密的对称或非对称密码。
相传在《左传》中，2000多年前的吴国与楚国在交战时，吴王的船被楚军截获，十分着急的吴国士兵在一个漆黑的夜晚，派了3个士兵乔装成楚兵，潜入进去楚军，为了避免黑夜认错人，按照事先约定好的，以“余皇”为暗号进行身份确认，后夺回了吴王船只。
从此，“暗号”开始在军中使用，一般在对敌战争中能见度不高时，用来辨别敌我，后来又称“暗号”为“口令”沿袭至今。（故事未经考证）
（2）密码的“危害”
从上述故事可以看出，密码的安全机制是在于，密码只有拥有者和验证者才知晓，通过对密码的校验来识别身份，如果密码泄露了，就可以伪装身份，先进大多数网站、系统的认证也是如此，账号和密码背后代表了你的身份和权限。
常规情况来说，密码应该是安全的，理论上不会被其他人知道，但真实的情况却不是这样，密码成了现在最容易攻击的一大薄弱点，大体上针对密码以下攻击方式都会导致密码失效：
弱口令：弱口令是非常普遍的情况，本质上是违反人要追求便利的心理，违反了人性；
密码盗取：有多少看客曾经将密码放到txt中，或记录在便签纸上？或是中个木马通过键盘记录，都很容易导致密码被盗取，而密码复杂性在这类场景下毫无意义；
撞库攻击：一般不会有人对每个网站都设置独立的密码，原因还是违反了人性，所以一旦某一个网站密码被泄露，账号很容易在其他网站中被撞，大概率会登陆成功，在外暗网内的密码社工库已经达到惊人的规模了；
拖库攻击：直接从服务端上把账号和密码盗走，方式多样，最终结果都是数据库被拿走，用户对此是毫无感知的，至于密码复杂的意义在于服务端有没有进行加密，加密可以增加被爆破的难度。
从上述情况可以看到，密码被盗是大概率事件，就算你有良好的习惯，也无法保障其他地方不出问题。
而在企业中，密码带来的安全风险就更严峻，很多APT案例，都是以获取到管理员密码为里程碑，比如去年驱动之家供应链攻击，如下图：
（图1）腾讯御见分析报告
在针对驱动人生的攻击中可以看到，前期准备、横向移动的阶段性成果，都是以获取到管理员账号密码为里程碑，并且在目标达成后很快就实施了后续的攻击，迅速达成战果。
这类型的攻击在企业安全事件中也是层出不穷，导致密码讽刺的由应该提供保护，变成了加害方，密码不再是安全要素而是风险要素。
二、去密码化方案分析
那么我们能否干掉密码，用更安全的方式来替代它呢？答案显然是可以的，而且这个目标应该是多数企业应该达成的目标，会是一个长期趋势。
（1）密码在企业中的应用
在尝试干掉密码前，有必要先了解清楚密码在企业中的应用范围，对方下药疗效才更好。如果按照密码使用对象来区分，会有下面几类对象：
面向客户
业务密码：QQ、游戏账号之类
面向员工
办公PC密码
企业邮箱密码
业务IM密码
网络准入密码
VPN密码
代码仓库密码
业务系统密码
OA网站密码
面向管理员
网络设备密码
服务器登陆密码
安全设备登陆密码
管理后台密码
......
面向系统服务
API-KEY：服务API调用认证
数据库密码
......
这四类对象，需要采用的解决方案各不一样，这篇文章会先聚焦在企业内部用户“员工”和“管理员”这两类角色上，业务账号安全、服务口令安全留在后续再做探讨。
（2）密码挑战
在面向员工和管理员的密码安全问题上，企业安全已经奋战很多年了，各大公司都采用过很多方式，例如下面场景方式：
密码复杂策略：通过域控、后台密码策略等方式，强制要求密码满足复杂度要求，比如我知道业界某知名公司要求密码长度在15位以上，15位以下被视为弱口令；
密码生命周期：要求定期密码进行更换，以及禁止使用之前曾经用过的密码，防止密码来回使用，目的就算密码被泄露了，也只在密码生命周期内可用；
主动爆破：包括不限于直接用密码破解机对域控密码进行破解，用扫描器进行爆破，用基线系统进撞密码，目的是主动发现弱密码；
社工库撞库：前几年法律不完善时，为了降低社工库危害，很多企业安全团队会自己下载社工库后去撞公司员工账号，目的也是为了主动发现被泄露的密码；
除此外还有口令管理制度、安全意识培训，这些并没有什么用的方式...
上述方案在人性面前，都是naive，多年的企业安全经验上，有违人性的规则，必然会被绕过，比如：
密码复杂度策略：类似这样“123456qwerty!@#$%^”看似安全的复杂密码，或是写在电脑旁的便签纸上，更为了方便贴在显示器下广而告之；
密码生命周期：每次都要设新密码，记不住怎么办？在密码后通过+1、-1方式来循环；
最终你会发现，规则有多强，人的创意就会有多高。
（3）替代密码方案的选择
那么什么样的密码才是安全的呢？我总结了个密码四要素，相对应的强密码就是他的反面，可以用来做评估参考，如下：
弱密码要素
可知：可以被获取到；
可预测：可以通过其他信息预测到，比如生日，姓名；
可重放：可以被重复使用；
单一维度：维度单一，一输皆输。
强密码要素
不可知：不能或难以被获取；
不可预测：强随机性，不能或难以被预测；
不可重放：一次有效，无法被重复使用；
多维度：维度多样化，需要多维度组合，某一个维度被盗不影响整体安全。
基于上述标准，引入现在场景的密码替代技术，可以快速评估密码替代方案是否安全、健壮，如下：
上表可以看出，大众普遍认识的生物识别并不安全，而多数运维使用的证书登陆也并不安全，至于以前手机上常见的手势方式验证就更弱了。
传统的OTP+PIN码的方式是相对最安全的，也是我们首选方案，但需要说明但是，考虑到用户体验等问题，我们也使用了扫码等方案来适用不同场景，并非单纯的一刀切。
而每引入一个新的方案，一定会带来新的风险，比如OTP+PIN的方式安全依赖密钥种子和算法安全性，本文假定这些方案都被用最优方式落地，因此不做进一步衍生讨论了。
三、去密码化方案设计
明确了需求、挑战和密码替代方式后，就可以开始进行去密码化方案设计了，在方案设计上需要考虑：需求是否能被满足、是否可以扩展、是否具备弹性、是否稳定、以及易用，同时设计时也需要考虑后续如何落地的问题。
（1）需求实现
需求实现上一个重要考虑是不是能支持员工、管理员使用的密码场景，通过对密码场景进行梳理分类，会发现需要支持的认证方式主要有下面几类，只要支持了这些认证方式，对应的系统、场景也就可以支持到了。
Form网页认证：
OA网站
内部业务系统
后台管理网站
知识库等
PAM认证：
Linux类服务器认证
Windows KDC认证：
Windows类系统
Radius认证：
网络准入、无线网准入
网络设备认证
VPN认证
私有协议：
企业IM认证
exchange客户端认证
（2）统一认证系统架构
为了提高用户体验，降低成本，建立统一的认证中心是很有必要的，尤其是集团化的公司，随着分公司、人员和业务的增多，如果是分散的架构，会导致要投入的人力成本大幅增加。
等部署实施完，随着人员在不同公司、业务之间的流动，又会加剧管理的复杂度，最终因用户体验下降，项目难以被推进。
（图2）统一认证系统架构
绿色-核心区
Auth服务：认证系统核心，用于算法、密钥种子、密钥生成方式；
Auth-DB：用于存储用户、认证代理、授权等相关信息；
红色-认证代理和认证接口
Form认证代理：用于提供web系统OTP认证接入；
PAM认证代理：用于Linux类系统使用OTP认证接入；
Windows认证代理：用于Windows类系统使用OTP认证接入；
auth接口：私有协议或是特殊场景下使用auth接口来获取认证信息；
Radius：对接Radius服务，用于网络设备、准入、VPN类的OTP认证接入；
蓝色-用户区
激活服务：用户自助系统，用于用户自主激活，PIN码设置，手机更换，找回等；
软、硬令牌：OTP载体，实际上由于智能手机的普及，通过手机软令牌会给用户更好的体验，硬件令牌往往用于一些特殊场景；
黄色-管理区
系统管理后台：用于权限分配、用户锁定、禁用、认证代理管理等功能
（3）认证代理实现
在认证代理实现上，区分不同认证代理是为了解决不同认证场景，本质上都是将认证请求转发到auth中来认证，例如Form网页认证代理，将输入的账号和密码转给auth服务进行验证，返回认证结果给业务网站。
除form外，其他几类认证都有开源或是相关解决方法，现将常用的几类实现原理简要进行介绍，如果需要进一步研究和实现的可以根据文章后面的参考链接，进一步学习。
PAM认证代理
可拔插验证模块（PAM）是Linux自带的功能，是为了通过统一的接口、配置，以可扩展方式实现不同的认证接入。
（图3）PAM框架
在PAM框架上，对于相关的认证管理、账号管理、会话管理、口令管理都进行了封装，开发者不用关心底层使用的服务模块，可以比较快速的实现，网上也有很多样例可以参考。
（图4）PAM配置架构
我们只需要按照PAM标准，开发好对应的SO通过PAM配置文件，指定什么样的应用使用OTP认证，比如远程登陆，或是本地登陆，su之类。
Windows认证代理
Windows的OTP认证代理实现相对比较复杂，原因是windows不像Linux提供了比较好的认证接入方式，需要通过劫持方式来嵌入OTP的认证，但这类方式并非完美实现，主要逻辑如下：
（图5）2003交互式登陆流程
上图是windows 2003、XP版本的windows认证逻辑，区别在于左边的是走的本地认证，右边的走的域认证，嵌入OTP认证后的逻辑如下：
CTRL+ALT+DEL：进入交互式认证，启动GINA（账号密码输入框）
GINA：输入用户名和密码后，转发至本地LSA进行验证，如果是域的话会转给域LSA由AD进行认证；
New process：认证通过后，由OTP agent劫持认证状态，转入OTP的认证，认证通过后放行认。 
（图6）windows2008登陆流程
windows2008后登录逻辑有了较大调整，引入了票据机制，整个逻辑更加复杂，但对OTP类的登录来说，过程还是一样，走完windows认证后进行劫持，再通过OTP认证。
但这类方案不是完美方案，会导致用户需要两次认证，体验并不好。如果有更好的解决方案，请发消息给我。
Radius认证
远程认证拨号用户服务（RADIUS）主要用于网络接入设备和认证服务器之间承载认证、授权、计费和配置信息。通常用于网络设备认证、VPN认证和网络准入等认证，支持PPP、CHAP、EAP等协议。
（图7）Radius认证代理
在OTP集成中通常有认证代理转发模式，即不对认证协议进行改造，而是将认证逻辑请求转到认证服务中进行验证，或是改造原生逻辑将OTP的认证逻辑嵌入其中。
密码代填方案（差）
先说明密码代填不是一个好方案，一般是用于解决一些老旧商业系统无法支持OTP的情况，这类系统由于是黑盒模式，又不提供接口或是SDK，导致接入改造难度比较大。
（图8）密码代填
这类场景在万不得已的情况下可以考虑密码代填方式，好处是实现相对容易，但问题是由要代填密码，也就是说会导致保存明文密码。
这类方式一旦认证代理如果出了问题，可以绕过验证，以任意人账号登录后面的系统，风险还是比较高的，通常不得已不要使用这类方式。如果一定要用可以通过对明文密码加密、密码随机化，密码一次性使用等方式来加强保护，但本质上还是不安全，并非是安全的方案。
有一些身份认证的乙方公司会使用这类方案来做集成，如果遇到这类要考虑下安全风险。
（4）用户身份绑定
统一认证架构后，令牌其实已经变成了唯一认证来源，不管想做什么，都需要令牌来。包括零信任中设备->用户->应用的信任关系，也是依赖于令牌。也就是说账号和OTP令牌实际是用户在网络空间中的投射。
考虑到近万员工已经不可能一对一来支持，或是通过管理员下发令牌来进行身份绑定和激活了。因此需要把激活过程变成自助模式，通过对员工实体身份对校验来进行激活绑定，以及结合员工状态来自动实现禁用、回收等工作。
该环节需要考虑比较多的是，怎么证明你就是你的问题，以及如何让用户好理解，引导上尽可能的方便不要造成用户的困惑，以及设备更换后，需要重新绑定等问题。
四、与零信任场景的结合
本质上这个无密码化方案是完全可以和零信任架构脱钩，独立运行，但有了零信任架构会带来用户体验上的很多好处。
方案开发和落地是两个事情，里面有巨大的鸿沟，尤其是当你实施时，需要面对大量用户时会面临很多技术和非技术的挑战，例如：
（图9）实施挑战
不开心：你要改变我的习惯，不开心，用不惯请你改回来；
没头脑：令牌怎么激活？帮助文档在哪里？你能不能帮我搞？
业务为王：业务出了问题你负责吗？我业务出问题了，就是上你们的搞的。
你爸爸：要集成？厂家不支持，厂家要费用，厂家没时间，厂家已经倒闭了...
上面这些是在涉及用户的安全方案落地中常见问题，而要做无密码化方案，势必要改变用户习惯，需要业务配合接入，而业务也要考虑自己的业务稳定性，这些挑战都需要运营、开发、业务携手来克服。
通过零信任架构，在一定程度上可以解决或减轻上述问题，主要原因是零信任集中了各类系统的入口，统一了身份，从而也可以天然可以统一认证方式了。
（图11）零信任集成架构
类似上述架构，Form类认证的网站业务可以全部放在网关后，服务器登陆维护可以用网页版堡垒机方式进行集成，移动办公和零信任终端agent集成等，关于这部分内容之前写的零信任实战远程办公中有写，感兴趣的可以看文末索引回顾，就不重复了。
用户体验好不好是安全方案能否落地的关键因素，尤其是在互联网公司，一个不小心就会被在论坛上喷，造成很大的压力。
通过零信任可以统一用户体验，账号、令牌、权限的激活均变为一次性操作，然后结合大量的自助引导，以用户体验为目标的UI设计，自助化的流程系统等，以一套标准培养用户习惯，最终达成预期目标。
五、结束语
这个方案是零信任架构中一个附带成果，个人觉得对企业安全来说，能解决密码安全问题可以给安全带来较大提升，而方案从设计、开发到实施落地，间隔了很长时间，团队也付出了很多努力，最后的一个体会就是，尽量避免违反人性去推动安全。
最终，某天我们终于发布了取消静态密码登陆的通告，将集团用户都切换到无密码化的环境中，解决了多数密码场景。
但要认清现实的是，实际情况还是有很多问题在等待解决，比如exchange客户端问题、数据库密码问题，API密钥问题，OTP和自动化运维的冲突问题等。
而大范围的使用过程中，还需要考虑HA问题、分布式架构等问题
|
