MS Bot Framework中把JWT存储到UserState/Azure Blob Storage是否安全？

现有流程的安全隐患 #

• 验证码无有效防护机制：未限制验证码有效期、输错次数的前提下，攻击者可通过暴力破解获取验证码，进而绑定用户账号拿到长期访问权限
• 长期JWT风险极高：1年有效期的JWT一旦泄露，攻击者可在有效期内全程冒用用户身份，且常规JWT无内置吊销机制，泄露后无法及时止损
• 存储侧权限无约束：若Azure Blob Storage权限配置不当，所有用户的长期JWT可能批量泄露，造成大范围的用户数据安全问题
• 绑定逻辑缺少校验：仅靠验证码完成Slack账号与待办账号的绑定，没有校验绑定发起方的其他身份信息，攻击者获取他人验证码后可直接绑定到自己控制的Slack账号
• 明文验证码传输风险：用户在Slack聊天窗输入的验证码是明文存储在Slack的聊天日志中，若Slack账号被盗或日志泄露，直接导致身份被冒用

优化实现方案 #

• 加固验证码校验逻辑：验证码有效期设置为3~5分钟，输错3次直接作废，每次发送验证码需要有60秒的冷却间隔，避免暴力破解和短信轰炸
• 替换长期凭证为「短期访问令牌+刷新令牌」组合：API下发有效期1~2小时的短期访问JWT，同时下发有效期1年的刷新令牌。刷新令牌加密存储在Azure Blob Storage中，短期令牌过期后用刷新令牌换发新的访问令牌，刷新令牌支持在API侧手动/自动吊销，泄露后可立刻作废，大幅降低风险
• 优化凭证存储安全：Azure Blob Storage开启服务端静态加密，仅给Slack Bot的服务账号开通最小必要的读写权限，禁止公开访问。存储的所有凭证都用用户唯一Slack ID加盐加密后再落盘，即使存储数据泄露也无法直接解析使用
• 强化绑定校验逻辑：首次绑定除了验证码，还需要用户输入待办账号绑定的手机号/邮箱，双重信息匹配后再完成Slack ID和待办账号的绑定，后续所有操作都严格校验Slack用户ID和绑定关系是否匹配
• 最小权限控制：下发的JWT仅开放创建待办的必要权限，关闭删除、修改、查询历史待办等多余权限，即使令牌泄露，能造成的危害也被控制在最小范围
• 可选替换身份验证方案：如果不想自行维护短信验证码逻辑，可以直接使用Slack官方提供的OAuth授权流程，用户点击授权链接即可完成Slack账号和待办账号的绑定，不需要传输明文验证码，安全性更高

内容的提问来源于stack exchange，提问作者Miguel