CodeIgniter中找回密码的token需用random_bytes(32)生成并哈希编码，存库绑定用户ID和UTC过期时间，验证时先查库再用hash_equals比较，链接须urlencode且使用HTTPS。
找回密码链接里的 token 是怎么生成的
CodeIgniter 本身不内置“找回密码”流程，token 完全由开发者控制生成逻辑。框架只提供基础工具（比如 random_bytes()、bin2hex() 或 uniqid()），你得自己拼出安全、可验证、有时效性的链接。
常见错误是直接用 uniqid() 或 mt_rand()，这类值可预测、无熵、易碰撞，攻击者可能批量猜出有效链接。
推荐做法是：用加密安全的随机字节 + 哈希或编码，再存入数据库绑定用户 ID 和过期时间。
-
random_bytes(32)是 CI 3.1.11+ / CI 4 的首选，PHP 7+ 原生支持，不可预测 - CI 3 旧项目若 PHP openssl_random_pseudo_bytes(32) 作降级方案
- 生成后务必用
bin2hex()或base64_encode()转成 URL-safe 字符串（避免+、/、=引发路由或解析问题） - 不要把原始 token 明文存库；如需校验，建议存
hash_equals()可比对的哈希（如password_hash($token, PASSWORD_DEFAULT)），或直接存明文但加索引+严格过期检查
为什么不能用 md5(time().rand()) 生成 token
这种写法在老教程里常见，但存在三个硬伤：
- 时间戳可被估算，
rand()在 PHP 中默认非加密安全，输出空间小，暴力枚举几万次就能撞中 -
md5不是随机数生成器，它是确定性哈希——输入可控，输出就可控 - 生成值不含用户上下文，无法防止 token 被截获后跨账户滥用（没绑定
user_id）
真实场景中，攻击者用 Burp Suite 抓包重放 + 脚本扫 token=xxx 参数，几秒内就能跑出有效链接。这不是理论风险，是已知攻击链。
CI 3 和 CI 4 在 token 存储与验证上的关键差异
CI 3 没有统一的 token 管理服务，你得手动建表（如 password_resets），字段至少含：email、token、created_at、expires_at；验证时靠 $this->db->where() 查，再手写过期判断。
CI 4 更灵活，可配合 Time 类和实体模型简化逻辑，但要注意：esc() 不自动处理 token 字段（它不是用户输入内容），而 hash_equals() 必须用于防时序攻击的字符串比较——别用 == 或 === 直接比对 token。
- CI 3 示例片段：
$token = bin2hex(random_bytes(32));
，插入前记得$this->db->escape()或使用查询绑定 - CI 4 推荐用
Time::now()->addMinutes(30)生成expires_at，避免手动算时间戳 - 无论哪个版本，验证 token 时必须先查库确认存在且未过期，再比对值——顺序不能反，否则可能绕过过期检查
生成链接时路径拼接容易漏掉的细节
最终发给用户的链接形如 https://example.com/auth/reset?token=abc123，但实际构造时容易踩坑：
- CI 3 的
site_url('auth/reset')默认不带查询参数，得手动拼：site_url('auth/reset').'?token='.urlencode($token)；漏urlencode()会导致含+的 base64 token 解析失败 - CI 4 的
url_to('auth-reset').'?token='.rawurlencode($token)更稳妥，rawurlencode()保留斜杠不编码，适合完整 token 字符串 - 别把 token 放在 URL path 里（如
/reset/abc123），CI 路由默认不支持长随机字符串匹配，容易 404 或误匹配 - 邮件模板中务必用完整 HTTPS 链接，避免客户端因混合内容拦截跳转
最常被忽略的是：token 生成、存储、发送、验证四个环节的时间必须用同一时区（推荐全部用 UTC），否则“30 分钟有效期”在跨时区部署时可能变成 25 分或 35 分，导致用户刚点开链接就失效。
