04 | 身份认证：除了账号密码，我们还能怎么做身份认证？

Dec 16, 2019

04 | 身份认证：除了账号密码，我们还能怎么做身份认证？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

04 | 身份认证：除了账号密码，我们还能怎么做身份认证？

2019-12-16 何为舟来自北京

《安全攻防技能30讲》

课程介绍



讲述：何为舟

时长16:26大小15.06M



你好，我是何为舟。
上一讲，我们详细讲解了密码学的三种算法：高效安全的对称加密算法，解决密钥分发难题的非对称加密算法，以及提供单向加密的散列算法。
在表达了你对密码学清晰的理解之后，面试官开始相信你具备安全方面的基础知识了。于是，他准备和你探讨一下安全落地的细节。基于你之前提出的“黄金法则”，面试官问道：“黄金法则的认证（Authentication）部分不就是账号密码吗？这么简单的东西，有必要考虑得那么复杂吗？”
认证，也就是身份识别与认证（通常来说，识别和认证是一体的，因此后面我会用身份认证来指代识别和认证）。毫无疑问，对于一个安全的应用来说，身份认证是第一道门槛，它为后续所有的安全措施提供“身份”这样一个关键信息。
听完你的简单叙述后，面试官直接问道：“现在我们公司有好几个应用，每一个应用都有独立的账号体系，管理起来十分复杂。而且，内部员工的账号体系也没有建设起来。如果是你，你会怎么解决这些问题呢？”
现在你可能很难回答这些问题，没关系，带着这些问题，让我们来学习今天的内容。相信学完之后，再有人问，你都可以对答如流。
身份认证包括哪些东西？首先，身份认证不仅仅是一个输入账号密码的登录页面而已，应用的各个部分都需要涉及身份认证。在我看来，身份认证可以分为两个部分：对外认证和对内认证。
对外认证，其实就是应用的登录注册模块，它面向用户进行认证。对外认证的入口比较集中，一个应用通常只有一个登录入口。因此，我们可以在登录这个功能上，实现很多种认证的方式。这就可以用到我们之前提到的“你知道什么、你拥有什么、你是什么”。
除了应用本身需要有登录注册的模块，应用的各种内部系统同样需要涉及登录认证的功能，比如：服务器的登录、数据库的登录、Git 的登录、各种内部管理后台的登录等等。这也就是我所说的对内认证。
那么，对内认证和对外认证有什么区别呢？我觉得，它们最主要的区别在于认证场景的复杂程度。从下面这张图中我们可以看出，对外认证是单一场景下的认证，对内认证是多场景下的认证。
在了解了对内、对外认证的特点之后，我们再来聊一聊它们的应用。我了解到的目前行业的现状是，各个公司的对内认证都比较薄弱。其主要原因在于，内部的认证场景过于分散，很难进行统一管理。尤其是服务器、数据库等的认证，目前还无法做到统一。因此，对内认证是一个长期治理的过程，需要我们投入较大的精力。
正如我在第一节课中提到的，“面对一个问题时，我们总是很容易发现表面的影响，而忽视其产生的根本原因”，在身份认证这个问题上同样如此。表面上，我们要做好对外认证，防止用户的账号被盗。根本上或者说更普遍的问题是，我们要如何做好对内认证。因此，当你在考虑身份认证的安全问题时，一定要尽可能考虑得更全面。毕竟，对于安全来说，有一个小场景没做到位，很多时候，就意味着什么都没做。
身份认证主要面临哪些威胁？接下来，你肯定想问，我们该如何做好身份认证呢？不要着急，我们先来看一下身份认证都会面临哪些威胁。只要我们针对这些威胁找到对应的解决办法，就能做好身份认证了。身份认证面临的威胁主要包括无认证、弱密码、认证信息泄露。接下来，我们一个一个来看。
首先，没有认证环节是所有应用和公司存在的最普遍的问题。尤其是在对内认证的部分，我们经常会看到，很多公司的数据库、接口、管理后台在使用的时候，并不需要经过认证这个环节。
除了没有认证环节的直接“裸奔”，弱密码也是一个普遍存在的问题。我常常觉得，安全最大的敌人是人类的惰性。设计一个好记的强密码并不是一件简单的事情，这也是弱密码屡禁不止的原因。
说完了无认证和弱密码，接下来我们来聊一聊认证信息泄露。所谓认证信息泄露，就是指黑客通过各种手段，拿到了用户的密码信息和身份凭证这样的认证信息。常见的手段包括钓鱼、拖库等等。更可怕的是，很多攻击对于用户来说都是无感知的。
那么，无感知体现在哪里呢？我们可以来做一个小测试。你可以在haveibeenpwned中，输入自己的账号信息，测试一下它们是否被泄露了。如果显示“Oh no -powned!”，那就说明你的邮箱密码已经被泄露了，我建议你可以尽快修改你的密码了。
除了密码的直接泄露以外，大部分的登录系统都无法应对重放攻击。重放攻击简单来说就是，黑客在窃取到身份凭证（如 Cookie、Session ID）之后，就可以在无密码的情况下完成认证了。
总结来说，身份认证面临的威胁其实都是认证信息的泄露。这其中，既可能是应用本身就没有认证信息或者认证信息强度比较弱，使得黑客可以通过猜测的方式快速获取认证信息；也有可能是黑客通过一些攻击手段（如窃听等），从用户那获取了认证信息，从而冒充用户进行登录。
而身份认证被破解的后果，相信你也知道一些：一旦黑客仿冒了正常用户进行认证，那么就相当于获得了这个用户的所有权限。更严重的是，所有的后续操作，都会记录到这个正常用户的名下，使得后续应用进行授权和审计的时候，都很难发现黑客本身的存在。
身份认证的安全怎么保证？在了解了身份认证环节会面临的各种威胁，以及这些威胁可能产生的影响之后，你可能要问了，我们应该怎么解除这些威胁呢？我觉得，很多时候，我们解决安全问题，不只是在解决一个技术问题，还要培养外部用户和内部员工的安全意识。也就是说，认证安全并没有什么完善的技术解决方案，更多的是通过一些规章制度去强化我们的安全意识。
尽管如此，我这里也会去讲一些技术方案，让你知道一些基本的解决方案。
比如，对密码的强度进行限制（如强制使用字母、数字、特殊字符的组合密码，并达到一定长度），强制用户定期修改密码，对关键操作设置第二密码（如微信、支付宝的支付密码）等等。
当然，随着互联网的发展，我们也会不断地利用新技术去升级验证手段，帮助用户降低被“攻击”的风险。比如，通过手机验证替代密码验证（因为丢失手机的几率比丢失密码的几率低）；通过人脸、指纹等生物特征替代密码。
除此之外，我们还可以通过加密信道（如 HTTPS）来防止窃听；也可以通过给下发的凭证设置一个有效期，来限制凭证在外暴露的时间，以此来减少重放攻击带来的影响。
这里面有一点你要注意，身份认证的最大的问题还是在于身份管理。随着公司业务的不断扩张，当账号体系变得越来越复杂时，如何对这些账号进行统一的管理，是解决身份认证问题的关键。而单点登录就是一个非常有效的解决方案。
单点登录如何解决身份认证问题？那么单点登录（Single Sign On，SSO）到底是什么呢？单点登录的概念很简单：用户只需要进行一次认证，就可以访问所有的网页、应用和其他产品了。随着互联网产品形式的不断发展，单点登录的实现方式也经历了多次的升级革新。下面我为你介绍几种典型的单点登录方式，它们分别是：CAS 流程、JWT、OAuth 和 OpenID。
第一个要讲的是 CAS（Central Authentication Service，集中式认证服务）流程。
CAS 是一个开源的单点登录框架，它不属于某一种单点登录的实现方式，而是提供了一整套完整的落地方案。整体的流程如下图所示，具体步骤我会通过访问极客时间 App 的例子来为你详细讲解。
假如用户现在要访问某个应用，比如极客时间 App。
应用需要进行认证，但应用本身不具备认证功能。因此，应用将用户重定向至认证中心的页面。比如，你在登录一个应用的时候，它显示你可以选择微信、QQ、微博账号进行登录，你点击微信登录，就跳转至微信的登录页面了。
用户在认证中心页面进行认证操作。如果用户之前已经在其他应用进行过认证了，那么认证中心可以直接识别用户身份，免去用户再次认证的过程。
认证完成后，认证中心将认证的凭据，有时会加上用户的一些信息，一起返回给客户端。也就是你在微信登录完成后，回到了极客时间 App。
客户端将凭据和其他信息发送给应用，也就是说，极客时间 App 将微信的登录凭据发送给了极客时间后端。
应用收到凭据后，可以通过签名的方式，验证凭据的有效性。或者，应用也可以直接和认证中心通信，验证凭据并获取用户信息。这也就是为什么极客时间能够拿到你的微信头像了。
用户完成认证。
CAS 的流程非常经典，你现在应该理解了吧？我们后面要讲的 3 种单点登录方式，都和 CAS 的流程相似，说它们是 CAS 的“衍生品”也不为过。所以说，你一定要先掌握了 CAS 流程，然后再来看下面这 3 种。
JWT（JSON Web Token）是一种非常轻量级的单点登录流程。它会在客户端保存一个凭证信息，之后在你每一次登录的请求中都带上这个凭证，将其作为登录状态的依据。JWT 的好处在于，不需要应用服务端去额外维护 Cookie 或者 Session 了。但是，正是因为它将登录状态落到了客户端，所以我们无法进行注销等操作了。
OAuth（Open Authorization）的主要特点是授权，也是我们通常用 QQ、微信登录其他应用时所采用的协议。通过 OAuth，用户在完成了认证中心的登录之后，应用只能够验证用户确实在第三方登录了。但是，想要维持应用内的登录状态，应用还是得颁发自己的登录凭证。这也就是为什么 QQ 授权后，应用还需要绑定你的手机号码。这也就意味着，应用是基于 QQ 的信息创建了一个自身的账号。
OpenID（Open Identity Document）和 OAuth 的功能基本一致。但是，OpenID 不提供授权的功能。最常见的，当我们需要在应用中使用微信支付的时候，应用只需要收集支付相关的信息即可，并不需要获取用户的微信头像。
在实际情况中，基于各种业务需求的考虑，很多公司都倾向于自己去实现一套 SSO 的认证体系，它的认证流程如下图所示：
在这个流程中，应用的服务器直接接收用户的认证信息，并转发给认证中心。对用户来说，这个认证中心是完全透明的。但是，这个流程给予了应用过多的信任，从安全性方面考量的话，是不合理的。在这个过程中，应用直接获取到了用户的认证信息，但应用能否保护好这些信息呢？我们并没有有效的办法去做确认。
因此，我的建议是，多花一些功夫去接入成熟的单点登录体系，而不是自己去实现一个简化版的。JWT 适用范围广，在单点登录的选取上面，如果想要将用户信息做统一管理，选择它最为简单；如果认证中心只是被用来维护账号密码，由业务去维护用户所绑定的其他手机等信息，那么，采用 OAuth 更合适。
总结好了，今天的内容差不多了，下面我来带你总结回顾一下，你要掌握的重点内容。
身份认证的主要场景可以分为：对外认证和对内认证。其中，对内认证往往会因为管理的疏忽，导致很严重的问题。从威胁上来说，无认证和弱密码，是最普遍的安全问题。除此之外，各种密码和认证信息的窃取，也是黑客常用的攻击手段。对于身份认证来说，单点登录是一种集大成的解决方案。基于 CAS 流程，衍生出了很多成熟的单点登录流程，可以供你去使用。
那么，掌握身份认证的一些技巧，对我们有哪些帮助呢？首先，任何的应用都会存在对内和对外的认证，因此，这将是你提升应用安全水平的一个首要任务。其次，在复杂的应用系统和网络结构中，如何管理身份认证，既优化用户体验，又保证其安全性，对你的设计和管理能力都是一个考验。做好了身份认证，不论是在安全上，还是在个人能力上，你都能够得到极大的提升。
思考题好了，学习了今天的内容，你现在可以来思考一下面试官的问题：怎么做好认证？
这里我先给你提供一个思路。首先，你需要告诉面试官，公司目前存在哪些认证问题。这些认证问题的存在，可能导致哪些严重后果。接下来，就可以设想一下，想要解决这些认证问题，你会设计出怎样的认证体系。
欢迎留言和我分享你的思考和疑惑，也欢迎你把文章分享给你的朋友。我们下一讲再见！

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 12

提建议

03 | 密码学基础：如何让你的密码变得“不可见”？

05 | 访问控制：如何选取一个合适的数据保护方案？

 写留言

精选留言(33)

小晏子
2019-12-16
试着答一下思考题，目前公司认证主要纯在的问题是对内认证偏弱，各种服务器环境密码过于简单，而且口口相传，很容易泄露，也很容易遭受内部攻击。要解决这个问题，我认为公司内部需要建立起一套对内认证的安全体系，首先，对于内部系统的登陆，可以使用跳板机的形式，绑定员工账号，员工使用其个人用户名密码登陆，其次，建立权限等级，不同员工绑定不同权限组，做到安全隔离，最后，可以建立账号监控体系，定期监控登陆日志，做风险分析报警等，防范风险于未然。
展开
作者回复: 赞
共 2 条评论
15
leslie
2019-12-16
填鸭式直接赶完了落下的课，发现有些问题有注意却没有去真正明白且换位思考。极客时间做秋冬课程调研时曾经问过我，我当时就提出安全是目前极客时间最空白的内容却又是最需要的，年末终于出来了。前几个月学全栈梳理课程时尤为感受到安全的重要性，虽然很多时候我们会由于职业的关系在某方面去做一些安全策略，可是安全不是仅仅是局部的数据库、程序开发、网络防火墙，而是贯穿整个计算机系统的。单点再强只是一个点，各方面强才是真的强。简单回答一下老师今天的问题，个人觉得应当是从多方面去做这件事情： 1.程序层：程序端在传输中禁用明文，早年的sql注入其实就是web页面传了具体值；其实目前账号登录最常规的还是手机验证码，动态随机生成的，超时重发而已； 2.数据库层：密码存储以算法加密形式存储，早年大量的明文存储其实造成了许多问题 3.操作系统层：强密码且定时过期，这个其实从windows2008开始就非常典型；如：密码必须大小写区分、必须特殊字符、必须16位之类的 4.网络层：就如老师之前课程举的例子-蹭网，公共网络中密码被泄露的风险很大，国内大量的密码泄露其中不少是蹭网蹭出来的。以上就是个人对此在这些年工作中最典型看到和接触到问题：网络和安全这块确实偏弱，刚看完胥峰老师的书，希望课程中能和老师交流学习，提升这块的能力，更好的应当安全风险。谢谢老师的分享。
展开
作者回复: 你好，感谢你的留言。看起来你是确实有体会过安全的强需求的。课程会一点一点的覆盖主要的知识点，每节课的思考会集中在某个方向上，你也可以自己串联一下。希望能够帮助到你～
共 2 条评论
9
。
2019-12-16
老师，你好，咨询个问题。应用服务和中间件（这两个以下简称服务）部署在公司的机房里，服务通过nginx对外暴露。nginx在机器A上，其余服务在机器B~N，公司的安全人员要扫描所有机器上的应用。个人感觉如果机器B~N上做好防火墙设置，只需要关系机器A上的安全问题就可以了，机器B~N不对外暴露，在应用服务层面就没有安全问题了。请问是否是这样
展开
作者回复: 嗯，这么做，一定程度上能缓解安全问题。比如nginx如果只暴露80端口，那么B~N的漏洞则主要集中在Web漏洞上。但是，内网并不是绝对安全的，通过Web漏洞，也可以实现内网穿透，访问内网的其他服务。如果你的防火墙只是做在A和BN之间，那么对于这种横向渗透，就起不到防御作用了。
6
胡波 allenhu
2019-12-16
老师，哪个haveibeenpwned网站显示的结果准确吗？我自己的gmail邮箱都显示"oh no" , 可是google并没有给我汇报这个gmail密码已经被泄露了啊？
作者回复: 还是比较准确的。不过因为它没有显示具体细节，很可能是很早期的密码被泄露了。
共 3 条评论
5
xiao豪
2019-12-16
老师，请问LDAP是属于哪种，适合在什么场景下使用？
作者回复: 内部认证用LDAP的多一些。LDAP比较独立，它自身包含了单点登录和群组管理的功能，可以方便公司内部作为组织架构的基础数据库支持。
5
雷霹雳的爸爸
2019-12-20
https://haveibeenpwned.com/ 这个，并不表示邮箱账号泄露了吧，我鬼子文实在是差，但是看下来它的解释，大概还是这个账号对应得标识，或者作为标识，在哪些已经被他收录的安全事件中涉及到了吧，当然有可能，这些安全事件中得网站中我用的和这个标识得email站密码一样，那我自然就中枪了，或者是由于OAuth认证关联信息，然后又被利用等等，这个其实希望老师能详细给解释一下，我最早是用1password时候给我导向到它家的，我还以为是1password宣传自己的产品...另外老师能点评一下1password这家得工具和服务么
展开
作者回复: 因为它没有披露密码，所以无法证实。但我认为haveibeenpwned的准确率还是可以的，只不过可能泄露的是很久很久之前的密码。 1password这类密码管理工具还是很好用的，至少我认为是目前个人用户保存密码的最佳解决方案。别人毕竟专门做密码存储的，方案的安全程度肯定比个人自存密码来得靠谱。
4
哈德韦
2020-07-15
老师好，怎么理解使用了 JWT 后，就无法注销了？ 1. JWT 都有过期时间，过期后就自动注销了； 2. 如果 JWT 存放在客户端（cookie 或者 local storage），用户点注销，客户端只要删除保存好的 JWT 就行了； 3. 如果“注销”是指从服务器端将用户“强踢下线”，那么可以把密钥更新。（需要实现用户粒度的密钥管理）以上是我对使用 JWT 注销的理解，请问是否有误？
展开
作者回复: 是的。说的其实就是第三种，用户粒度密钥管理实现成本上很高，一般都是统一密钥，所以无法注销。
共 2 条评论
3
008
2020-03-15
课程提到的对外认证和对内认证才明白我们的一直理解的认证那么片面，特别是我们还把数据库密码明文写在配置文件里，想想都可怕，最近刚做的服务运维相关的应用，可以管理所有服务状态及配置，因为没有统一的内部认证系统，一直处于裸奔状态，心虚的很，所以一直在思考如何落地统一认证，也同时纠结于认证系统是否需要同时考虑授权，比较偏向于仅考虑App层面的授权（即是否可以访问该App），而每个App内的授权不在统一认证系统里做统一管理。不知道业界一般是如何考虑认证、授权、用户信息管理的。
展开
作者回复: 一般内部都是会采用SSO管理所有的内部员工权限的。对于数据库、服务之类的，会在依据服务特性去进行封装，比如使用堡垒机登录服务器，通过网关连接数据库等。
3
丽莎
2019-12-16
我们现在已经越来越习惯用这种通过微信/微博或者其他CAS来认证登陆的场景了，我一直好奇的难点是，在CAS完成认证过程后，登陆凭据是如何从CAS服务器转移到欲登陆的APP中的。我们知道Cookie等内容都是严格遵循浏览器的同源策略的，就算使用30X跳转，设置的Cookie也只能存在CAS域名内。我惟一想到的方法是在Reloacation的URL后面跟上认证凭证，请问我的想法对吗？老师有没有额外的资料可以补充给我阅读，谢谢。
作者回复: 就是通过跳转实现的。不过在网页中，一般是会生成一个form表单，表单的内容就是各种凭证，然后提交的时候，相当于以POST请求跳转到新页面，这样传递信息的长度也不受限制。具体可以看一下，SAML，网页时代比较流行的单点登录机制。
共 2 条评论
3
曙光
2020-03-11
老师，CAS流程和企业简单SSO之间的区别还是没弄懂，CAS的第5步“将认证信息发给应用”和企业简单版的第3步“返回认证凭据相关信息”，应用都会接收到认证信息，是不是都存在“过多的信任”问题？
作者回复: 认证凭据的时效性和有效范围是可控的，通常只能在一段时间内认证某一款应用，因此可以下发给应用。但账号密码属于隐私信息，一旦泄漏，就可以认证全部应用，因此会存在风险。
2
麋鹿在泛舟
2019-12-25
请问kerberos属于哪种认证和其他几种注意什么差异呢
作者回复: kerberos也算是单点登录的一种，不过更多的应用于面向服务的认证。比如分布式集群中，如何认证每一个服务节点都是可信的，通常会使用keerberos。
2
tt
2019-12-16
老师讲解了JWT和OAuth在应用场景上的区分，拓宽了思路。之前只是理解JWT是OAuth流程中token的一种特殊形态: 1、内容是客户端可理解而不是不透明的； 2、内容可以自带数字签名而不需要去认证中心验证。
展开
作者回复: 嗯，整体上来说，相似的地方会比较多。主要的区别还是在最终的目的上。
2
程序员二师兄
2020-03-24
好奇的我赶紧进网站试了一下自己的账号，还好“Good news — no pwnage found!”
1
轩呀
2020-03-23
课程中说到了人脸认证，今天在QQ空间里看到了有人发的一款工具，只要一张照片就可以做到点头，眨眼，张嘴等动作，那么对于一些需要验证人脸的应用，应该怎么防御呀
作者回复: 这个就是人脸算法上需要进行的对抗升级了。现在高级的人脸算法，还是有破解难度的，它会对真实的背景环境、纹理信息等进行识别，不是人脸那一块正确了就行。
1
业余爱好者
2020-01-22
认证环节的问题一般都是认证信息的泄露，所以保证认证信息的机密性是非常重要的。在业界一般采用单点登录实现身份认证。cas是集中式认证服务的简称。它有很多变种，像jwt,oauth,openid等。
1
律飛
2019-12-28
目前公司存在的主要问题是管理层和开发人员安全意识薄弱，缺乏安全技术知识，在前期需求分析和设计中对安全几乎不考虑，在后期开发中缺乏系统考虑。另外对内认证偏弱，各种服务器环境密码、admin帐户过于简单。要解决这个问题，我认为公司应该购买本课程，提高管理层和开发人员的安全意识，学会基本的安全知识。另外应进行安全体系建设，建立安全制度，明确职责和权限。
作者回复: 哈哈，谢谢支持，有问题欢迎留言交流～
1
Geek_4996c9
2023-01-04 来自广东
公司对外的认证是jwt 对内认证也比较完善，连接服务需要通过跳板机，程序的账号密码是写在nacos，展示的时候会加密处理，因为公司人比较少，一人一个账号（因为发生过乱改生产数据库的事情），做好了权限隔离。但是对redis的处理就简单了，直接跳过了鉴权，但是服务是在内网环境，没有提供公网服务地址。不好的点在于流程不够规范，本地可以连生产数据库去跑一些数据，也可以很容易能拿到管理员账号。内部服务之间的接口调用没有鉴权，应该也不需要吧？
展开
黄福超
2022-09-02 来自广东
目前公司的服务器密码过于弱，但是有一定的认证，也有一定的隔离，但是没有对应的监控体系，也没有定期的修改服务器密码
周Sir
2022-07-05
jwt的token存在服务器redis，想让用户下线或者注销时，设置token过期即可。
AFlymamba
2022-06-23
1、对外认证互动营销业务，走 OAuth 获取用户在第三方平台相关数据，比方微信公众号授权，借助 openid 做唯一性记录，然后生成业务的 jwt，后续客户端访问服务端每次都需要携带业务 jwt，否则认定为 401。通常还会做业务补偿，比方让用户输入号码，为业务服务，比方说工单（用户能提供号码）反查，根据号码做短信推送等。 2、对内认证 vpn、定期强制让内部开发更新密码、密码组成有要求。 3、用户体系没做大一统管理，单独服务做认证的话其实问题还好访问令牌失窃问题。一是访问令牌具有时效性，过期无法用。其次限定客户端 ip 等。
展开

