产品安全，保障所交付产品的保密性、完整性和可用性。
单点登录
- 用户输入用户名和密码，SSO 单点登录验证通过后，返回一个票据（Ticket）
- 用户通过 Ticket 访问其他的应用系统
好处：
- 避免各业务自行重复建设，在很大程度上简化业务的工作量。
- 可以统一强化对用户隐私的保护，避免用户隐私（口令、双因子保护口令、生物特征等）因分散存储、保护不当而泄露;与HR系统关联，离职销户，消除员工离职后的风险
登录的 Ticket 机制有会话机制和持续认证机制
认证机制：会话（适合 TO B 的业务）
- 用户单点登录 SSO 验证通过获取 Ticket 后
- 利用 Ticket 访问 产品网站（应用系统）
- 应用系统将 Ticket 提交到 SSO 验证是否合法
- 得到合法结果后就与用户建立会话
- 在会话的有效期间,用户和应用系统不再访问 SSO
如何保证会话的安全呢？
黑客获取的信息是有效Ticket信息
客户端：
Ticket 信息sessionId 在 cookie 中，如下图所示：
服务端：
每个 sessionId 在数据库中的信息如下所示：
服务端可以根据 sessionId 根据 ip、 user-agent 、userId 信息进行对比，如果不一致则请求重新登录，使得即使黑客获取到 sessionId ，但是由于IP不一致或User-Agent有差异,导致会话认证不通过，可跳转到认证入口要求重新认证，这样在黑客没有窃取到原始的用户名和口令的情况下，可以防止恶意登录。
如果员工出差，或者连接的无线，则可以仅做 user-agent 限制；如果对安全性要求比较高的应用，就可以加上 ip 限制。
黑客获取的信息是无效的信息
- 启用HttpOnly和Secure属性：启用了HttpOnly属性之后，可以防止其被JavaScript读取到，使用document.cookie无法获取到其内容；启用Secure属性之后，则只能通过HTTPS传递。
- Cookie中尽量不要存储敏感的数据，不得不存储的时候，建议考虑加密措施
**黑客仿造成功登录 SSO **
每个应用可以设置自己的会话超时时间（比如30分钟），在会话有效期内如果存在请求，则会话超时会重新计算（也就是顺延）。在会话超时后，应用系统会通过重定向跳转到SSO，重新进行认证。
- 登录大多数办公应用，很少需要输入口令进行身份认证，登录的频次取决于SSO设定的默认有效时间；
- 登录敏感度比较高的应用，一般需要输入口令进行身份认证，并且会话很快就失效。
认证机制：持续认证（适合 To C 业务）
在某些场景中，如手机APP访问后台服务器，这种传统的一次性认证并不一定是最佳的，为了保证用户体验，一次性认证后的会话有效期需要设置得特别长，这就带来了新的风险：如果会话凭据（Cookie或Session）被窃取，则用户的身份就会被盗用，给用户带来各种损失。鉴于此，我们可以采用持续的消息认证机制（也可以和会话机制配合使用），每次请求都执行身份认证。
采用密码学上的认证加密机制，典型的如 AES-GCM（Advanced Encryption Standard-Galois/Counter Mode）
AES是一种常用的对称加密算法，GCM（Galois/Counter Mode）是在加密算法中采用的一种计数器模式，带有GMAC消息认证码。
加密不是认证
- 不带认证码: 加密解密过程可以理解为多轮转换或洗牌，就算密文被篡改，也是可以被解密的，只是解密出来的数据是乱码，计算机并不能区分这个是否是乱码（只能人眼区分），或者是否具有可读的意义。
- 带认证码: 解密函数在解密过程中如果发现被篡改，会直接抛出异常。
口令安全：不直接发送明文口令
用户的口令属于用户的个人隐私，如保护不当，会与法律或监管要求、合规要求冲突，口令泄露之后，
- 会给企业的声誉带来严重影响，如被坏人利用，则可能给用户个人带来资金安全等损失；
- 由于用户往往在不同的网站使用相同的口令，黑客可以使用这些泄露的口令，假冒用户身份，尝试登录其他网站，造成损失范围的进一步扩大（俗称“撞库”）。
因此，对用户口令，需要执行特别的保护措施。
- 增强口令强度
基于口令所使用的字符集（字母、数字、符号）和口令长度，看能够组合出多少种可能，这个数字的数量级越大，暴力破解所需要的时间就越长，强度就越高。如果给定一个口令，使用现在最先进的GPU破解时间需要100年（或更高的数量级）以上，则该口令为高强度.
可以参考如下：
- 密码短语，就是将几个单词拼接在一起，并替换部分字母，例如：IL0veTheL@zyD0g（助记词：我爱这只懒狗）。
- 诗词助记密码，比如：Csbt34.Ydhl12s（助记词：池上碧苔三四点，叶底黄鹂一两声）。
- 前端 慢速加盐散列
慢速加盐散列在对抗暴力破解方面，有非常明显的效果。但服务器侧的资源是宝贵的，消耗在这种延时的运算中非常不值得，为了解决这个问题，我们可以将延时运算转移到用户侧去。这种百毫秒级的延时，对用户的影响是几乎可以忽略不计。
用户侧浏览器利用 bcrypt、scrypt、PBKDF2 函数，慢速加盐散列得到最新的密文 p1 发送到后端
密文字符串（p1） = bcrypt(用户名+口令+固定字符串) 延时300～500毫秒
后端加盐散列 p1 的结果 p1 和随机字符串 s1存储到数据库中
密文字符串（p2）= SHA256(p1 + 随机字符串s1)
- 生物特征指纹保护
生物特征，包括指纹、声纹、虹膜、面部特征等，属于用户的个人隐私，如果处理或保护不当，会与法律法规或监管要求、合规要求冲突。与口令相比，这些隐私需要更强的保护措施。
不上传生物识别图像，只上传经过处理的生物特征值，而不是原始图像
如果上传用户的生物识别图像（指纹图像等），则无论是否加密，图像都有可能泄露（例如被收买的员工，利用组织授予的权限将数据导出）；且由于生物识别图像不能修改，一旦泄露，将造成不可挽回的损失。如果是用于手机等智能终端的身份认证，则建议指纹比对仅在硬件层级完成，指纹数据不出手机。
为了保护经过处理的生物特征值，隐私数据，可以考虑通过如下方式：
- 通过对称加密（AES 128或以上）存储用于比对的生物特征。
- 认证过程需要携带及验证时间戳（timestamp），防止重放攻击（黑客通过截获的生物特征伪造请求）
