有没有什么前端验证码的成熟方案?

2023-08-31 00:52:06 +08:00
 LeeReamond

首先,前端验证码和可靠二字完全不搭边我理解。但是后端验证码的话,后端首先需要进行一个 CPU 计算生成图片的过程,然后还需要维护一个对应状态,感觉成本有点高了,相比之下前端验证码对于后端来说就是无限轻量了。

有没有一种可能性是走两套方案,先前端再后端?比如注册验证这种场景,现在国内一般都是要调 API 发手机验证码的,为了保护 API 几乎都需要前置经过某种验证才能调用 API ,那么有没有可能,在前几次验证码时是前端验证,后端 API 根据用户 IP 或者什么其他信息维护一个屏蔽表,调用次数达到一定程度后再使用稍微安全一些的后端验证码这样?

这样前端的安全性要求其实也不高,能拦截 90%低端程序员就可以了。 有这样的项目吗?

3975 次点击
所在节点    程序员
37 条回复
yankebupt
2023-08-31 01:37:05 +08:00
你自己就可以做一个
首先图片是可以预生成的,你可以一次生成它 100W 张,扔服务器,扔CDN甚至让客户端预下载了都行
然后你根据系统时间给出一个分段随机序号
让客户端填完了把明文和序号发回来
根据系统时间规则是因为对方如果 replay attack 会在 5-10 分钟内失效
如果你想让客户端自己能判断对错,把明文的 Hash 也发过去让他自行验证。对面抓包看代码永远只知道 hash 不知道该填什么
必须看图
还不用维护状态
yankebupt
2023-08-31 01:39:23 +08:00
对了,扔 CDN 的话加个报复保护的 ip 限流……有很多人 cdn 被 D 的。
dusu
2023-08-31 01:44:58 +08:00
既然你觉得生成费劲成本高
给你个笨但是又高效的办法
为啥不提前生成一批验证码图片文件(总量为 36^长度)
不暴露路径的情况下
后端只需要生成 token
然后前端随机来用呢?
当然 还有很多可以优化的空间
例如 o 和 0 可以去掉等等举一反三…
yankebupt
2023-08-31 01:52:36 +08:00
@dusu 这个方法和我刚才说的方法都有一个问题,就是 replay 攻击。
都是可以填一次验证码,然后 5-10 分钟内利用一个序号无限申请,因为没状态……
我那个还应该加上一条,不仅应该根据系统时间,还应该根据请求 ip 分段,最大程度防止 replay 。
geelaw
2023-08-31 04:26:28 +08:00
@yankebupt #1 (经典计算机的)客户端不能自己验证,通常来说验证码的长度不足以阻挡离线枚举。

如果是注册验证,一个简单的避免重放的思路是让验证码和注册信息绑定。当然我没有仔细想过这样做的问题,标准解决方案才是正道。
0o0O0o0O0o
2023-08-31 08:08:31 +08:00
如果一定需要验证码,我建议且只建议 OP 购买并接入成熟服务,不要自研,你仅仅有图片验证码的概念就去自研的话约等于给攻击者送礼,包括 #1 - #4 。
zachlhb
2023-08-31 08:13:16 +08:00
可以用友验,极验这种服务的,前后端同时验证
yyf1234
2023-08-31 08:26:43 +08:00
极验不
yyf1234
2023-08-31 08:27:04 +08:00
就行了
ShuWei
2023-08-31 08:38:48 +08:00
考虑前端使用 wasm ,实时生成一个含语义理解的验证,比如实时生成并给出一个图片,让点击图片中特定内容的地方,然后验证坐标对不对。

服务端生成和验证,其实真没有多大的压力,你可能想得有点多了

或者,直接使用第三方的验证码服务,应该是最好的选择
wu67
2023-08-31 09:16:30 +08:00
我选择接入第三方的 sdk. 例如 阿里拉条公司 谷歌交通公司
lanxiner
2023-08-31 10:04:57 +08:00
近期正在研究验证码方案:
建议用第三方
阿里云、腾讯云都基本是按照使用量收费的, 非常便宜. , 但是不原生接入手机端,
其他的网易云盾、极验这些做的比较成熟各个端都可以接, 但是价格相对比较高.
用第三方的话基本上都有无痕验证, 他们有动态更新的风险识别算法,自动识别到有风险才会弹出验证码做进一步验证. (客户体验较高)
mdn
2023-08-31 10:14:16 +08:00
不行,后端并不知道接口是否经过前端认证之后发送的
建议直接接入第三方验证,有无感验证,触发风控才需要弹窗验证
manasheep
2023-08-31 10:31:47 +08:00
“感觉成本有点高了”,毛毛雨了。
yankebupt
2023-08-31 11:03:00 +08:00
@geelaw 我不太懂离线枚举,但是不是可以把 Hash 设置复杂点(比如多 Hash 嵌套几十层),客户端用户点提交后基本1秒之后才验证这种……
反正服务端验证明文又不需要验证 Hash......

但是离线反重放真的完全靠运气,对面上工具的话绝对没戏,所以只能防小白
yankebupt
2023-08-31 11:11:28 +08:00
@geelaw 要说非经典计算机,要有用的话肯定是把验证部分扔TEE里然后非对称加密握手拿到密钥,但又要买证书巨贵而且小程序之类还不能用……
Maerd
2023-08-31 11:15:54 +08:00
直接接入第三方验证吧,前端验证基本拦不住爬虫
yankebupt
2023-08-31 11:26:23 +08:00
@geelaw 我的意思是,服务端只需算出他生成的那些张的 Hash ,而客户端需要枚举所有。而且等客户端枚举完,服务端可能以及换了一批 Hash 组合了
或者如果不在意服务端亲自 Hash 一下的话,可以每次给客户端随机的Hash组合算法用于验证……
比如
md5(sha1(salt(sha1(salt(md5())))))
salt(sha1(md5(sha1(salt(md5())))))

还有真的很多人说成熟第三方,确实。为什么非得验证码。滑块不好么……第三方验证很贵么
dzdh
2023-08-31 11:35:37 +08:00
wasm + cookie 带个随机数 类似 totp 那样 10 秒误差时间范围内算个 6 位数数出来
hahaba
2023-08-31 11:43:10 +08:00
直接把接口加密了,前端的秘钥打散到各个文件再加密找都找不出来,连验证码都不用

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/969630

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX