高效安全的对称加密算法，解决密钥分发难题的加密算法（防止对称密钥泄露），以及提供单向加密的三列算法
问题
现在公司有好几个应用，每一个应用都有独立的账号体系，管理起来失分复杂。而且，内部员工的账号系统也没有建设起来，应该怎么解决这些问题？
身份认证
分为两个部分：对外认证和对内认证
对外认证，其实就是应用的登录注册模块，面向用户进行认证。对外认证的入口比较集中，一个应用通常只有一个登录入口。因此，可以在登录这个功能上，时效内很多种认证的方式。这就可以用到之前提到的你知道什么、你拥有什么、你是什么
除了应用本身需要有登录注册的模块，应用的各种内部系统同样需要涉及登录认证的功能，比如：服务器的登录、数据库的登录、Git的登录、各种内部管理后台的登录等，也就是对内登录
对外和对内认证的区别
对外认证是单一场景下的认证，对内认证是多场景下的认证
身份认证主要面临的威胁
主要包括无认证、弱密码、认证信息泄露
首先，没有认证环节是所有应用和公司存在的最普遍问题。尤其是在对内认证的部分，很多公司的数据库、接口、管理后台在使用的时候，并不经过认证这一环节
除了没有认证环节，弱密码也是一个普遍存在的问题。安全的最大敌人是人类的惰性。
认证信息泄露
是指黑客通过各种手段，拿到了用户的密码信息和身份凭证这样的认证信息。常见的手段包括钓鱼、拖库等
查看邮箱密码是否被泄露
总的来说身份认证面临的威胁其实都是认证信息的泄露。
身份认证的安全怎么保证？
解决安全问题，不只是在解决一个技术问题，还要培养外部用户和内部员工的安全意识。也就是说，认证安全并没有什么完善的技术解决方案，更多的是通过一些规章制度去强化安全意识
基本技术解决方案
比如，对密码的强度进行限制（如强制使用字母、数字、特殊字符的组合密码，并达到一点长度），强制用户定期修改密码，对关键操作设置第二密码（如微信、支付宝的支付密码
等
当然，随着互联网的发展，也会不断地利用新技术去升级验证手段，帮助用户降低被攻击的风险。比如，通过手机验证替代密码验证（因为丢失手机的几率比丢失密码的几率低）；通过指纹等生物特征替代密码。
除此之外，还可以通过加密信道（如HTTPS）来防止窃听；也可以通过给下发的凭证设置一个有效期，来限制凭证在外暴露的时间，以此来减少重放攻击带来的影响。
随着公司业务的不断扩张，当账号体系变得越来越复杂时，如何对这些账号进行统一的管理，是解决身份认证问题的关键。而单点登录就是一个非常有效的解决方案。
单点登录如何解决身份认证问题？
几种典型的单点登录方式：CAS流程、JWT、OAuth和OpenID。
CAS（Central Authentication Service，集中式认证服务）流程
不属于某一种单点登录的实现方式，而是提供了一整套完整的落地方案。整体流程如下图所示，
1、 加入用户现在要访问某个应用。比如极客时间App
2、 应用需要进行认证，但应用本身不具备认证功能。因此，应用将用户重定向至认证中心的页面。比如，你在登录一个应用的时候。它显示你可以选择微信、QQ、微博账号进行登录，你点击微信登录，就跳转至微信的登录页面了
3、 用户在认证中心页面进行认证操作。如果用户之前已经在其他应用进行过认证了，那么认证中心可以直接识别用户身份，免去用户再次认证的过程。
4、 认证完成后，认证中心将认证的凭据，有时会加上用户的一些信息，一起返回给客户端。也就是你在微信登录完成后，回到了极客时间App
5、 客户端将凭据和其他信息发送给应用，也就是说，极客时间App将微信的登录凭据发送给了极客时间后端
6、 应用收到凭据后，可以通过签名的方式，验证凭据的有效性。或者，应用也可以直接和认证中心通信，验证凭据并获取用户信息。这也就是为什么极客时间能够拿到你的微信头像了
7、 完成认证
JWT（Json Web Token）是一种非常轻量级的单点登录流程。他会在客户端保存一个凭证信息，之后在你每一次登录的请求中都带上这个凭证，将其座位登录状态的依据。JWT的好处在于，不需要应用服务端去额外维护Cookie或者Session了。但是，正式因为它将登录状态落到了客户端，所以我们无法进行注销等操作了。
oAuth（Open Authorization）的主要特点是授权，也是通常用QQ、微信登录其他应用时所采用的协议。通过OAuth，用户在完成认证中心的登录之后，应用只能够验证用户确实在第三方登陆了。但是，想要维持应用内的登录状态，应用还是得颁发自己的登录凭证。这也就是为什么QQ授权后，应用还需要绑定你的手机号码。这也就意味着，应用是基于QQ的信息创建了一个自身账号。
OpenID 和OAuth的功能基本一致。但是OpenID不提供授权的功能。最常见的，当我们需要在应用中使用微信支付的时候，应用只需要手机支付相关的信息即可，并不需要获取用户的微信头像
在这个流程中，应用的服务器直接接受用户的认证信息，并转发给认证中心。对用户来说，这个认证中心是完全透明的。但是，这个流程给与了应用过多的信任，从安全性方面老梁的话，是不合理的。在这个过程中，应用直接获取到了用户的认证信息，但应用能否保护好这些信息呢？
建议是，多花一些公服去接入成熟的单点登录体系，而不是自己去实现一个简化版的。JWT使用范围广，在单点登录的选取上面，如果想要将用户信息做统一管理，选择它最为简单；如果认证中心只是被用来维护账号密码，由业务去维护用户所绑定的其他手机等信息，那么，采用OAuth更合适。
单点再强只是一个点，各方面强才是真的强。 简单回答一下老师今天的问题，个人觉得应当是从多方面去做这件事情：
1.程序层：程序端在传输中禁用明文，早年的sql注入其实就是web页面传了具体值；其实目前账号登录最常规的还是手机验证码，动态随机生成的，超时重发而已；
2.数据库层：密码存储以算法加密形式存储，早年大量的明文存储其实造成了许多问题
3.操作系统层：强密码且定时过期，这个其实从windows2008开始就非常典型；如：密码必须大小写区分、必须特殊字符、必须16位之类的
4.网络层：就如老师之前课程举的例子-蹭网，公共网络中密码被泄露的风险很大，国内大量的密码泄露其中不少是蹭网蹭出来的。