17370845950

用户登录校验需在应用层用bcrypt等强哈希算法加密密码并恒定时间比对，MySQL仅作安全存储后端；账号字段应唯一且避免枚举，查询须参数化防注入，禁用数据库内密码比对。

用户登录校验的核心是安全、准确地比对用户输入的账号密码与数据库中存储的信息。MySQL 本身不直接参与应用层的登录逻辑，而是作为凭证存储后端——关键在于如何设计存储结构、加密方式和查询验证流程。

密码不能明文存储

MySQL 表中绝不能以明文保存用户密码。推荐使用强哈希算法（如 bcrypt 或 Argon2）在应用层完成加密，再存入数据库。MySQL 内置的 SHA2() 或 MD5() 不适合密码存储，因缺乏盐值（salt）且计算过快，易被暴力破解。

• 注册时：用 bcrypt 对用户密码加盐哈希，将完整哈希字符串（含 salt 和成本因子）存入 password_hash 字段
• 登录时：查出该用户的哈希值，用相同算法重新哈希用户提交的明文密码，再恒定时间比对（避免时序攻击）

账号字段需兼顾唯一性与安全性

建议使用独立的 username 或 email 作为登录标识字段，并设为 UNIQUE 约束。避免用自增 id 作登录凭证，防止枚举风险。若支持多方式登录（如手机号/邮箱），可统一归入一个 login_id 字段，并加索引提升查询效率。

• 建表示例：CREATE TABLE users (id INT PRIMARY KEY AUTO_INCREMENT, login_id VARCHAR(255) UNIQUE NOT NULL, password_hash VARCHAR(255) NOT NULL, ...);
• 查询语句应只按 login_id 精确查找一条记录，避免模糊匹配或 OR 条件拼接（防 SQL 注入）

验证逻辑必须由应用层完成

不要依赖 MySQL 的 WHERE password = SHA2(?, 256) 这类写法——这等于把密码哈希逻辑交给数据库，既难控制盐值，又绕过应用层的安全策略（如失败次数限制、IP 封禁）。正确做法是：

• 先用参数化查询根据 login_id 查出用户记录（含 password_hash 和状态字段如 is_active）
• 检查账户是否启用、是否被锁定、是否过期
• 再用 bcrypt 库比对密码，成功则生成会话（Session / JWT），不成功则记录失败日志并触发风控

补充安全建议

仅靠密码验证远远不够。生产环境应叠加基础防护：

• 登录接口限流（如 5 次/分钟），防止暴力试探
• 敏感操作前要求二次验证（短信、邮箱、TOTP）
• 密码重置链接带短时效签名 token，不用明文密码或 hint
• MySQL 连接使用最小权限账号（仅 SELECT/INSERT/UPDATE 当前业务表），禁用 root 远程登录