密码代填是一种帮助用户实现自动登录的方式，它通过自动模拟用户填写账号密码的方式来进行登录，严格来说它不属于单点登录范畴，由于国内不少企业采用这种方式来登录日常应用，所以也成为了一种广泛应用的实现单点登录的形式。有人说密码代填很落后，有人说它有特定的应用的场景，那么“密码代填”到底安全吗？是否值得采用？本文就来深入探讨一下。
一、“密码代填”的几种常见方式
“密码代填”顾名思义就是程序代替用户填写登录信息表单，实现自动登录的过程。主要有以下几种实现方式。
**1\. 通过应用提供的接口获取账号密码**
某些应用提供了特定的登陆接口，让第三方调用并传递用户名密码，然后就能实现登陆。即，在原本的登陆页面之外，额外提供了一个接口传递账号密码实现登陆。**这种方式下密码信息会直接通过网络传输，安全性完全无法保证，这种方式非常原始，不提倡。**
**2\. 通过POST接口直接提交表单**
第二种方式是当用户点击应用时，身份认证服务提供商（IAM or IDaaS） 执行一段javascript脚本，直接调用应用的登陆接口，并将账号密码信息，通过POST表单提交的方式，直接向应用传递，直接登录应用。在整个的流程里，服务器通过执行一段javascript脚本，直接传输账号密码，是不会打开应用登录页面的。
**这种方式实现起来最为简单，本质上可以理解为机器绕过了浏览器登陆页面，直接登陆了用户身份。**
但随着大众网络安全意识的不断提高，现在越来越多的网站开始通过各种方式屏蔽机器直接登陆。其中最为常见的一种方法就是在登陆页面加载的时候**添加随机Token**——在登陆表单提交的时候，除了必要的身份信息，还需要携带此随机Token，防止机器直接提交账号密码获取用户身份，如下图所示，**像 Github这样的应用就****无法****使用****这种方式登录：**
**3\. 通过浏览器插件提交表单**
第三种方式是 IAM 提供浏览器插件，与第二种方式“直接调用 Login 接口”不同，**浏览器插件会完全模拟用户手动的登录操作，可以分解为三个步骤：**
第一步，用户自主打开应用登录页面；
第二步，浏览器插件自动工作，自动填写账号密码表单；
第三步，浏览器插件自动点击登录按钮。
**这种方式的优势在于模拟了整个的用户行为，能够适用于绝大多数的网页端应用，包括上文的 GitHub，插件先打开应用页面时就获取 Access Token等登录参数。**
**它的劣势在于插件开发和维护成本比较大。**当应用的登录页 UI 改变时，需要及时更新插件的参数（表单位置、登录按钮位置等），并且需要企业所有用户在 IE、Chrome、Safari 等浏览器中自助安装对应的插件。而在不支持安装浏览器插件的移动端，也无法用这种方式实现密码代填。
二、密码代填是否值得采用？
总的来说，以上三种密码代填方式都需要先将终端用户的账号密码存储在身份认证服务商（IAM）的服务器中，**用户登录过程中不可避免地传递账号密码，****安全性较差**。这也是为什么越来越多的应用开启了二次认证（比如短信验证码、滑块验证等形式）来阻止密码代填操作。
**然而在实际应用场景中，「密码代填是否值得采用」，这一问题并不能“一刀切”下结论，这完全取决于企业应用场景的限制和安全性要求。**
一般情况下，我们推荐企业选择标准SSO协议的方式进行单点登录。在可以使用SSO的场景下，SSO是绝对优于账号密码的登录方式的。**但并不意味着所有的场景都能够使用SSO。**据统计市面上绝大部分的ToC的应用都是不支持SSO，比如大家平时使用的各种博客、贴吧、网盘等网站，由于是面向个人用户的，一般只会支持账号密码登陆，不会支持标准SSO协议；还有很多企业内部自研的内部系统，一般是服务于具体业务，不需要对外网开放，一般不会专门预留工期用于SSO的适配。在这些场景下，密码代填的方式能够帮助客户记住账号密码，实现快速登录。
**如果企业由于各种客观条件限制，只能选择使用不够安全的密码代填，那么就需要采用足够安全的密钥管理服务（Key Management Service，简称KMS），来保证生成和管理非对称加密的公私钥的过程，以及加密存储敏感信息的安全性。**
玉符基于零信任安全模型对KMS服务进行了精心设计，可以帮助企业更好的保护这些敏感信息，包括但不限于以下措施：
-
对每个敏感信息独立加密存储，在每个敏感信息创建的时候，KMS会自动分配一个新的256 bits对称加密用密钥，保证即使未来单个信息被攻破也不会影响其他信息。
-
使用最新的密码学规范（例如RSA-256），并保持更新，支持密钥轮转；
-
所有私钥永远不会明文暴露在外部服务或持久化存储（例如数据库）；即使网络数据被监听拦截、数据库被窃取，黑客也无法获取私钥信息。
-
有价值的敏感信息也只会在服务运行时缓存在受保护的内存空间内（安全界限范围Security Barrier），不会存在于服务器的硬盘上（全面禁用SWAP虚拟内存）。即使黑客攻破服务器的文件系统（filesystem）也无法获得有用信息。
-
整个KMS服务的启用基于Shamir’s Secret Sharing算法，受5个主令牌（Master Tokens）保护，每次必须有3个或以上的令牌同时输入才能激活（unseal）服务。即使整个服务器的内容被偷窃，偷窃者也无法成功启动KMS服务来获取数据。
-
加入防篡改机制，服务运行过程中会对所有加密数据的完整性进行检测。一旦有黑客对底层加密数据有任何修改都会导致进程自动封锁。
-
……
三、安全性更高的单点登录实现方案
再来解释一下 SSO 协议在安全性上的具体优势。标准的SSO协议有很多，像基于XML的SAML协议，在OAuth2.0上的身份验证层OpenID Connect协议等等，它们都是通过受信服务器和应用服务器之间的Token交互实现的，其中运用了密码学的算法知识，从而保证整个登录行为的安全性（关于单点登录中的Token认证可以参考这篇文章[《IDaaS技术解析 | 单点登录 Token 认证》](http://mp.weixin.qq.com/s?__biz=MzI3MDUwOTMxNg==&mid=2247483900&idx=1&sn=dd4af373a53bec93ea5c79261f4ca3d9&chksm=eaceb597ddb93c81d4e88620974262286942927979b1fd33589152d3e803d393d7a8a7974987&scene=21#wechat_redirect)）。
**与密码代填相比，通过标准SSO协议实现单点登录，不需要知道用户的实际密码，只需要知道需要登录的账号名即可，从根本上避免了密码泄露的风险**。而用户也无需再通过复杂的密码策略来保证账号的安全，甚至用户本身都不需要知道应用系统的密码，再也没有了忘记密码的烦恼。
**引入标准的SSO协议的另一大好处在于，员工的登陆行为可管控。**企业IT管理员可以查看到用户在什么时间什么地点登陆了什么应用，结合风控报警体系后，可以有效杜绝不正常的登陆行为，保护企业账户安全。
四、小结
综上，密码代填虽然在安全性上不够稳妥，但是在特定的应用场景下依然是最便捷的单点登录的实现方式，也建议企业使用更加可靠的 KMS 服务减少敏感信息泄露的风险。
当然，为了长远的系统安全考虑，只要条件允许，我们建议企业使用安全性更高的标准 SSO 协议对接的方式实现单点登录。
点击进入玉符官网了解更多单点登录、身份访问管理解决方案
相关阅读
-
[一文看懂单点登录协议：CAS、OAuth、OIDC、SAML](http://mp.weixin.qq.com/s?__biz=MzI3MDUwOTMxNg==&mid=2247484031&idx=1&sn=0ce43da3bd8b4ffbb60e99bc5d47d2bc&chksm=eaceb614ddb93f0292dcfe2628d2366715f7d2d945620030a5484e160c4df0d78186785fd5a5&scene=21#wechat_redirect)
-
[单点登录实现后，各个系统的账号同步怎么做？](http://mp.weixin.qq.com/s?__biz=MzI3MDUwOTMxNg==&mid=2247483918&idx=1&sn=8fd0271aaf2aa1727cf6eaca41a44cac&chksm=eaceb665ddb93f7357e93dd593876cf133ccebaeee221240cabdb82814ee431aacd60118dedf&scene=21#wechat_redirect)
-
[企业灵活用工，账号管理难？棘手的问题交给 IDaaS 处理](http://mp.weixin.qq.com/s?__biz=MzI3MDUwOTMxNg==&mid=2247484012&idx=1&sn=cef624c8f875c8b34270b0ae7a1c4138&chksm=eaceb607ddb93f11a46ac1214814fea77ab9d522e1fd1329e8508830541e0ce6dd3a5aa7f3ac&scene=21#wechat_redirect)
-
[社会化登录是什么？企业是否应该实施？](http://mp.weixin.qq.com/s?__biz=MzI3MDUwOTMxNg==&mid=2247483996&idx=1&sn=d5fc6e7aea2dea4e056ab1384467c092&chksm=eaceb637ddb93f2171a051cfa45c7291125796943933cf9cecc3162e5815b89d3a2419bc0f74&scene=21#wechat_redirect)
