零信任架构实战系列：干掉密码，无密码化方案落地

密码/口令一直是企业安全中绕不开的一个话题，无数英雄在此折腰，相信不少人都有欲除之而后快的念头，那么我们是否可以干掉密码？又会有哪些挑战？本文既是对干掉密码的实践，以及如何同零信任结合。

本文共有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码的方式是相对安全的，也是我们首选方案，但需要说明但是，考虑到用户体验等问题，我们也使用了扫码等方案来适用不同场景，并非单纯的一刀切。

而每引入一个新的方案，一定会带来新的风险，比如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登陆流程

w indows2008后登录逻辑有了较大调整，引入了票据机制，整个逻辑更加复杂，但对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

Windows登录流程： https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc780332(v=ws.10)?redirectedfrom=MSDN

Radius介绍： https://en.wikipedia.org/wiki/RADIUS

历史文章

零信任架构远程办公实战

零信任架构实战系列：如何选择零信任架构

零信任实战系列：远程办公实战（视频）

硬核安全招聘，有干货有福利，还有顶配iPhone等你拿

关于我

我是何艺，从事甲方安全16年，目前负责完美世界集团安全工作，聚焦在企业安全建设、零信任、安全架构、安全分析与响应、数据安全等领域，今年开始尝试写公众号“小议安全”，坚持输出 有干货 的 原创 。

构思到写完一篇文章大概需要3-5个晚上或是1-2天周末时间，如果这篇文章对你有价值， 关注、在看、转发 三连，会是对我最大的支持，谢谢！