kerberos协议与票据
kerberos协议与票据
windows用户密码存储在SAM文件（安全用户管理）中
当我们登录系统时，会对我们的密码进行hash加密后与数据库中密码对比、
（SAM文件保留了计算机本地所有用户的凭证信息）
NTLM（NT Lan Manager）协议
早期SMB协议在网络上传输明文口令。后来出现 LAN Manager Challenge/Response验证机制，简称LM，它是如此简单以至很容易就被破解。微软提出了WindowsNT挑战/响应验证机制，称之为NTLM。
是一种基于挑战、应答的wins早期认证机制，安全性不高，从windows2000开始默认不再使用。
认证流程
winlogon.exe -> 接收用户输入 -> lsass.exe -> (认证)
（lsass进程，这个进程中会存一份明文密码，将明文密码加密成NTLM Hash，对SAM数据库比较认证）
认证过程是将我们输入的密码转化成NTML hash 与SAM 文件中的NTML hash对比
windows下两种hash加密方法
LM hash
一种对称加密hash
参考：https://www.cnblogs.com/-qing-/p/11343859.html
明文--->转化为大写--->转化为十六进制，如果不到十四字节需要用0x00补充到十六字节--->分割成两个七字节分别作为密钥对魔术字符串（KGS!@#$%）进行DES加密，然后拼接在一起形成LM Hash。
LM hash的不足：
1.输入密码后 大小写不敏感
2.可以猜测到密码是否大于七位
3.‘魔术字符串’已知，容易破解
NTML hash
将输入的密码进行十六进制编码后转化为Unicode，再用MD4加密得到结果
admin -> hex(16进制编码) = 61646d696e
61646d696e -> Unicode = 610064006d0069006e00
610064006d0069006e00 -> MD4 = 209c6174da490caeb422f3fa5a7ae634
具体过程
1.客户端向服务端发送用户信息
2.服务端收到后判断该用户是否在本地账户列表中，如果没有认证失败，如果有随机产生一个16位随机数，称为‘Challenge’，
使用用户名对应的NTLM hash加密Challenge生成Challenge-1，存放在服务端内存中，然后将Challenge发送给客户端
3.客户端收到Challenge后用密码对应的NTLM hash加密后得到Response（ 表现形式为Net-NTLM hash），将它发送给服务方
4.服务端验证Response和Challenge-1 相等则验证成功
kerberos协议
Kerberos 是一种网络认证协议，其设计目标是通过密钥系统为 客户机 / 服务器应用程序 提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下， Kerberos 作为一种可信任的第三方认证服务，是通过传统的密码技术（如：共享密钥）执行认证服务的
三个实体：Client Server KDC(Authentication Server --AS 和 Ticket-Grant Service --TGS)
AS :用来认证用户身份
TGS：授权服务访问
Server：提供服务
Client：请求服务
具体过程
第一步:用户登录、请求身份认证
这个阶段用户输入账号密码，在客户端密码被一个单向hash函数加密成Client密钥
用户向AS发送请求
随后AS确认存在该用户，就将数据库中该用户对应的密码也用同样的单向hash函数加密，得到Client密钥，，与用户登录时生成的相同。
AS发回给Client的内容
1.用Client密钥加密的Client/TGS SessionKey（client ，TGS间的通讯）
2.用TGS密钥加密的TGT（用 krbtgt的HTLM hash加密）
（TGT中有：Client/TGS SessionKey、Client ID、Ticket的有效时间、Client的网络地址）
Client收到后因为有Client密钥所以可以解密得到Client/TGS SessionKey
第二步：请求服务授权
Client向TGS发送的有
要服务的ID （Service ID） 和 上一步AS给的TGT
还有用Client/TGS SessionKey加密的{Client ID,Timestamp}
然后TGS返回给Client的信息有
MsgF:使用[Client/TGS SessionKey]加密的[Client/Server SessionKey]
MsgE:Client/Server SessionKey（用Service密钥加密）、Client网络地址、Ticket有效时间、Client ID
因为Client有Client/TGS SessionKey 可以的到 Client/Server SessionKey
然而 Client/Server SessionKey因为是用Service加密，所以对Client不透明
第三步：发送服务请求、Server响应请求
MsgE:就是上一步的MsgE,
MsgG:用Client/Server SessionKey加密的{Client ID,Timestamp}(用来向ss证明，自己有来自TGS的key)
SS收到客户端的服务请求之后，先利用自身的[Service密钥]对Msg E进行解密，提取出Client-To-Server Ticket, 在3.2步骤中，提到了该Ticket中包含了[Client/Server SessionKey]以及Client ID信息。
SS使用[Client/Server SessionKey]解密Msg G，提取Client ID信息，而后将该Client ID与Client-To-Server Ticket中的Client ID进行比对，如果匹配则说明Client拥有正确的[Client/Server SessionKey]。
而后，SS向Client响应Msg H(包含使用[Client/Server SessionKey]加密的Timestamp信息)。
Client收到SS的响应消息Msg H之后，再使用[Client/Server SessionKey]对其解密，提取Timestamp信息，然后确认该信息与Client发送的Authenticator 2中的Timestamp信息一致。
黄金票据（Golden Ticket）
在认证的第一步Client通过AS认证后，AS会给Client发送Client/TGS SessionKey和TGT ，因为Client/TGS SessionKey不会保存在KDC中，而TGT的产生是用krbtgt 的NTLM hash加密（固定）的，所以假如知道了krbtgt的NTML hash就可以伪造TGT，然后这样有了黄金票据，在Client和TGS交互的时候，只要拿出伪造的TGT，和随便一个Client/TGS SessionKey生成的{Client ID,Timestamp}就可以跳过AS的验证，不用验证账号和密码
特点
需要知道krbtgt的NTML hash
不用到AS那去验证
可以获取任意服务
白银票据（Silver Ticket）
在认证的第三步，Client要向Server发送ST 和 Client/Server SessionKey加密的{Client ID,Timestamp} ，然后服务端用自己的Key（Server的NTML hash）解密得到 Client/Server SessionKey，然后用Client/Server SessionKey解密得到{Client ID,Timestamp} 。
如果Client知道了Server的NTML hash就可以伪造出一个ST ，而 Client/Server SessionKey在server收到之前是不知道的，也可以伪造，从而绕过了KDC，直接获取服务。
特点
需要知道server的NTML hash
不需要和KDC验证
只能得到特定的服务
