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