Android本地数据库JWT Cookie重置周期及忘记密码JWT实现方案咨询

1. 存储在Android本地数据库的JWT Cookie重置周期 #

没有通用的固定天数，核心根据你的业务安全等级决定：

• 低风险类应用（工具、内容社区等）：对齐JWT本身的过期时间即可，通常设为7~30天，用户活跃时可自动续期，无需主动提前重置
• 高风险类应用（金融、支付、企业办公等）：建议重置周期缩短到1~7天，额外增加设备指纹校验逻辑，检测到异地登录、设备变更等异常行为时，立刻强制重置JWT
  注意：本地存储JWT不要用明文存储，优先使用Jetpack Security加密后的存储组件，避免设备root后数据被窃取

2. 忘记密码功能方案评估与优化建议 #

现有方案的问题 #

你目前的实现存在几处明显的安全风险和逻辑问题：

• 接口router.post('/change-password', verifyAuth, resetPassword) 是登录态下修改密码的接口，和忘记密码场景完全无关，忘记密码的用户本身没有有效登录态，两个接口需要完全拆分，不要混用逻辑
• 接口router.post('/change-password/:token/:password', confirmResetPassword) 存在高危漏洞：绝对不要把明文密码放在URL路径中，URL会被服务器日志、浏览器历史记录等多处留存，密码泄露风险极高，密码必须放在POST请求的body中传输
• 你计划的跳转链接存在拼写错误：change-passowrd 需要修正为change-password，仅携带token参数的设计本身没问题

方案合理性判断与优化 #

你目前的核心逻辑（邮件发送带token的链接）是合理的，完全不需要用Cookie实现，原因是重置密码属于一次性临时场景，对应的JWT本身是短有效期的（建议设为15~30分钟，最多不超过1小时，且校验通过一次后立刻失效），无需持久化存储，前端拿到URL中的token后临时存在页面内存中，用户输入新密码后，把token和新密码一起放在POST请求body传给后端校验即可。
额外补充几个安全优化点：

• 重置密码专用的JWT要和登录态JWT使用不同的签名密钥，payload中明确标记用途为reset_password，校验时要先判断用途，避免被串用为登录凭证
• 用户多次申请重置密码时，之前生成的所有重置token要立刻失效，仅保留最新生成的一个可用
• 增加邮件发送频率限制，避免被恶意刷接口骚扰用户

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