这是一个创建于 1951 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，关于登录验证，之前发过一个帖子，询问前端验证码是否有意义，当时问那个问题有两个考虑，其一是我不了解 js 模块经过混淆后在生产级别的安全性，其二是我觉得后端生成验证码的话理论上可以成为饱和攻击对象，基本靠部署引擎拦截，跟业务无关了。(因为我没有被这么攻击过，纯粹是猜想)
当时回帖里诸位认为前端验证码搞不起，我也就放弃了。
这个贴想问一下各位的验证码细节上都是怎么实现的，因为想要无状态部署，各位看看我现在的方案行不行。我现在用的方案是后端生成验证码的同时生成 hash 作为令牌，与验证码图片一同发送至前端。(比如一个简单的算法，将随机生成的验证码重复一次再经过 sha1)，而前端进行验证码检验的时候，通过验算决定是否放行。
感觉理论上只要 hash 算法保密应该这套系统就是安全的？
当时回帖里诸位认为前端验证码搞不起，我也就放弃了。
这个贴想问一下各位的验证码细节上都是怎么实现的，因为想要无状态部署，各位看看我现在的方案行不行。我现在用的方案是后端生成验证码的同时生成 hash 作为令牌，与验证码图片一同发送至前端。(比如一个简单的算法，将随机生成的验证码重复一次再经过 sha1)，而前端进行验证码检验的时候，通过验算决定是否放行。
感觉理论上只要 hash 算法保密应该这套系统就是安全的？
 | 1 sampeng 2020 年 12 月 20 日 via iPhone 验证在服务端进行，客户端只是体验 |
 | 2 eason1874 2020 年 12 月 20 日 无状态，加盐加时间戳能防破解，但是在有效期内有重放问题，适合的场景不多。 |
 | 3 lpts007 2020 年 12 月 20 日 via Android “而前端进行验证码检验的时候，通过验算决定是否放行。” 这意思还是前端判断是否正确？ |
 | 4 imdong 2020 年 12 月 20 日 via iPhone 方案一(常见) 将验证码存于用户 Session 之中(具体方法有很多)，验证后删除。 方案二(和你的做法相似) 生成的验证码进行加密或不可逆哈希(应该加盐防止彩虹表攻击)，然后应该绑定一个时间与唯一 ID，如一分钟内有效，验证成功后将唯一 ID 存起来，一分钟内不允许使用，防止重放攻击。 |
 | 5 jzmws 2020 年 12 月 20 日 @imdong 相对来说第二种更好一些, 0202 年基于 session 认证有很多坑, 前后端跨域在 chrome 80 以上同步不到 session 配合配合 redis 就很方便了 ,不用去管理验证码失效的问题 1. 获取验证 把图片显示给前端的同时,并且带上当前验证码存储的 key 值 2.前端提交时候 用验证码的 key 值和输入内容 3.通过 key 去取 redis 中内容和输入比较 |
 | 6 ntdll 2020 年 12 月 20 日 前端是不可信的，任何在客户端运行的代码都不可信，服务端不能假定任何输入数据是没有被篡改过的。 因此如果是前端通过某种离线算法验证，那么整套验证机制就形同虚设了。未经授权的访问都可以通过相同的路径访问，因为服务端无法区分。 |
 | 7 westoy 2020 年 12 月 20 日 哪有啥真正的无状态啊， 你就算用 secure cookie 做 session, 用户改个密码要多个设备同步登出不还得服务端保存一个 token 做检验嘛 |
 | 8 johnsona 2020 年 12 月 20 日 via iPhone @westoy 我之前总监就被网上博客忽悠瘸了，要什么无状态，自己也说不清楚，服务端不存状态的话，很多业务场景没办法给他做 |
 | 11 black11black OP @lpts007 表述错误，意思是前端发送这个请求时，(后端)完成检验 |
| 12 black11black OP @johnsona 这有啥说不清楚的，当然要无状态，要不然服务可用性怎么拉上去？ |
| 13 johnsona 2020 年 12 月 20 日 @black11black 不是说你这个业务，我是说有的业务，比如有的人说 jwt 好，不用存后端，无状态，验证签名就好了，还可以存数据，不会被窜改，可以横向扩展，那退出登录怎么做，revoke jwt 还是要加一个黑名单，这就有的人乱搞的无状态 |
| 15 black11black OP |
| 16 black11black OP @johnsona 分布式 session 具体实现上怎么操作？维护一个进程间通信协议？或者 nginx 绑定 ip ？ |
 | 17 wellsc 2020 年 12 月 20 日 @black11black 可以用 redis 实现，和缓存差不多道理的 |
| 18 johnsona 2020 年 12 月 20 日 via iPhone @black11black 百度 |
| 19 johnsona 2020 年 12 月 20 日 via iPhone @black11black 感觉你想的太复杂或者可能受 tomcat 影响吗 |
| 20 johnsona 2020 年 12 月 20 日 via iPhone @black11black 你怎么跟产品解释说不做退出登陆，产品会觉得这么简单的功能 |
 | 21 Oceanhime 2020 年 12 月 20 日 可以看看 vcaptcha 的离线验证方案, 和你的意思感觉差不多？ https://www.vaptcha.com/document/faq.html#%E7%A6%BB%E7%BA%BF%E9%AA%8C%E8%AF%81%E6%A8%A1%E5%BC%8F%E5%8E%9F%E7%90%86 非利益相关 |
| 22 black11black OP @johnsona 不不，退出当然可以做，我的意思是即使后端没法验证退出，实际上倒不构成安全问题 |
 | 23 ysc3839 2020 年 12 月 21 日 via Android 我最近也有类似需求，最终选择的方案是 Encrypted JWT，有效期设为 2 分钟，使用后加到缓存中避免重放攻击。 登录后也是返回 JWT，退出登录的话是禁止多处登录，然后数据库里面存一个 token valid since 时间戳，每次登录或者退出登录直接更新这个。 |
| 24 johnsona 2020 年 12 月 21 日 via iPhone @black11black 我当时就这么搞的，我让前段退出直接删除 token 就行了，我不要面子的吗？他们不懂还以为我不行，而且前段删除 token，这个 token 还没 revoke 呢 |
| 25 black11black OP @ysc3839 token valid since 是指维护一个进程间共享缓存，退出登录以后把这个 token 设为 invalid ？ |
| 26 ysc3839 2020 年 12 月 22 日 via Android @black11black 只是存时间戳，在此时间戳之前签发的 token 都无效。 |
Select Language