Django弃用内置认证、用手动哈希密码查询登录会缺失什么？

明确结论：只要你满足两个基础前提——一是密码没有明文存储、用和工业标准对齐的慢哈希算法做加密（不是简单MD5/SHA1这类快速哈希），二是完全沿用Django自带的加密session框架存凭证、没有自己写未签名的明文cookie，那系统的基础安全底线是能守住的，不会一上来就全盘崩溃。但你绕开内置认证流程自己实现的话，会漏掉大量内置机制帮你自动兜住的安全防护：

• 时序侧信道漏洞防护缺失：你如果用objects.get(email=xxx, password=手动哈希的输入值)作为查询条件匹配用户，数据库查询的执行存在天然的时间差——当查询条件的部分内容匹配上时，数据库返回结果的响应时长会比完全不匹配稍长，攻击者可以通过反复测量响应时长的差异，逐位爆破用户的密码哈希。而Django内置的check_password()方法采用固定时长的常量时间校验逻辑，无论密码匹配与否，完整走完哈希校验流程的耗时基本一致，从根源上堵死了这个时序攻击路径。
• 会话固定攻击防护缺失：Django内置的login()方法在认证通过的瞬间，会主动作废当前的旧session ID，生成全新的session密钥并把原有session数据迁移过去，从机制上防止攻击者提前植入固定sessionID、等待用户登录后劫持会话的会话固定攻击。如果你只是简单往现有session里写入用户ID的标识，不做session key的轮换，就会把这个防护环节完全漏掉。
• 密码哈希的自动迭代升级能力缺失：Django内置的密码校验逻辑，会在用户登录时自动检测当前存储的密码哈希是否符合最新的安全参数要求（比如哈希算法类型、迭代轮次），如果参数过旧会自动重新计算符合最新标准的哈希值并覆盖存储。你自己实现校验逻辑的话，永远不会触发这个自动升级流程，哪怕后续Django版本更新了更安全的默认哈希参数，你的系统所有用户的密码哈希会一直停留在初始的弱参数配置上。

除了安全层面的缺口，你还会失去Django认证体系对接全生态的便利能力：

• 权限体系的无缝衔接：如果没有和django.contrib.auth的标准用户模型关联，你自建的用户表哪怕字段完全一致，也无法和内置的Group、Permission模型打通，后续要实现角色权限管控、视图级别的权限校验、模板层面的权限判断，全部要从零重写逻辑，没法直接使用生态里现成的权限组件。
• 全链路的请求上下文适配：Django内置的AuthenticationMiddleware会在每个请求的处理流程中自动加载当前登录用户，把用户对象挂载到request.user上——不管是内置的视图装饰器、第三方插件、DRF的权限校验逻辑，还是模板引擎的语法，都是默认依赖这个上下文对象的。你如果自己手写session存登录凭证，没有走标准流程把用户注入到请求上下文，所有依赖这个对象的组件都会直接失效。
• 安全生态的插件适配能力：Django生态里的多因素认证、第三方OAuth登录、单点登录、登录异常检测、账号锁定策略等成熟插件，全部是基于标准认证流程的扩展钩子开发的。你自己实现的登录逻辑根本对接不上这些插件，要实现上述功能只能从零开始写，维护成本极高。
• 审计与合规能力的开箱支持：内置认证体系自带的登录事件记录、密码过期提醒、失败登录计数等能力，只需要少量配置就能满足多数合规场景的要求，自己实现的话这些功能全部要单独开发。

补充：很多开发者觉得完全绕开内置流程可以获得更高的可控性，但实际上Django认证模块的设计从十年前开始就已经在填你现在踩的这些坑了。哪怕你需要高度自定义的用户模型，只要继承内置的AbstractBaseUser、对接内置的认证后端，就能完整保留所有安全能力和生态适配性，完全没必要用纯ORM查询、自己管session的方式从零实现登录逻辑。

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