【探索】无形验证码 —— PoW 算力验证

先来思考一个问题:如何写一个能消耗对方时间的程序?

消耗时间还不简单,休眠一下就可以了:

Sleep(1000)

这确实消耗了时间,但并没有消耗 CPU。如果对方开了变速齿轮,这瞬间就能完成。

不过要消耗 CPU 也不难,写一个大循环就可以了:

for i = 0 to 1000000000
end

但这和 Sleep 并无本质区别。对方究竟有没有运行,我们从何得知?

所以,我们需要一个返回结果 —— 只有完整运行才有正确答案。

result = 0
for i = 0 to 1000000000
    result = result + i
end
return result

通过返回结果,我们就能校验,对方是否完整运行了我们的程序。


不过上面这个问题,毕竟还是 too simple。小学生都知道,用数列公式就可以直接算出结果,根本不用花时间去跑循环。

有什么函数,是无法用公式推测的?也就是说,必须老老实实运行函数,才能得出结果。而找不到一种更快的算法,也能算出相同的结果。

显然「单向散列函数」就是。例如,一个经典的问题:

MD5(X) == X

就无法用公式来解决了。要找出答案,只能一个个试过去,需要大量的时间。

但对于验证者,是非常轻松的 —— 只需将收到的答案,计算一次就可判断对错。

Hashcash

当然,上面的那个例子太困难了,一时间根本找不到答案。但可以做一些改进,例如只要求结果前几位是 0 就可以:

Hash(X) == "0000......"

这样 0 的数量越少,满足条件的 X 就越容易找到。

同时,为了防止答案重复使用,还可以再增加一个盐值:

Hash(X, Salt) == "0000......"

盐可以由验证者提供,这样就可以充当一个「问题」。符合条件的 X,则可以当做问题的「答案」,提交给验证者鉴定。


这就是所谓的 PoW(Proof-of-Work),一种鉴定对方是否投入计算工作的机制。并且只需花费少量的资源,即可鉴定大量的工作。

使用散列函数实现的 PoW,就叫做 Hashcash。现实中比特币使用了类似的原理,它使用了 SHA-256 作为散列函数。有权威的密码学算法作为保障,因此只能暴力穷举,而无法使用投机取巧的方法获得结果,保障了挖矿工作的价值。

传统应用

当然,Hashcash 早不是新鲜事,很久以前就用在反垃圾邮件中。

例如,用户写完邮件时,客户端将「收件地址 + 邮件内容」作为 Salt,然后计算符合条件的答案:

Hash(X, Salt) == "000000..."

最后将找到的 X 附加在邮件中并发送。

服务端收到后,即可鉴定发送这封邮件,是否花费了计算工作。

对于正常用户来说,额外的几秒计算并不影响使用;但对于制造垃圾邮件的人,就大幅增加了成本。

传统的限制策略,大多通过 IP、账号,攻击者可以用大量的马甲和代理,来绕过这些限制;而使用了 PoW,就把瓶颈限制在硬件上 —— 计算有多快,操作才能多快。

Web 应用

同样,Hashcash 也能用于 Web。例如论坛,增加机器发帖的计算成本。

在发帖时,计算:

Hash(X, 帖子内容) == "000000..."

提交时,带上额外的参数 X。

后端即可判断,用户发这条帖子,是否付出了计算工作。

Web 改进

然而,网页不同于客户端。

例如写邮件的例子:

邮件写完后,客户端可以隐藏在后台自动计算,然后再发送。但网页就大不相同了。如果发帖时,网页卡上好几秒,将大幅降低用户体验。

因此,不能像邮件那样,拿「帖子内容」、「标题」等这些用户输入的内容来计算。而是选择一个始终固定的参数。


例如,可以参考传统验证码的方式:

# 后端 - 生成随机问题
ques = rand()
session["pow_ques"] = ques

echo(ques)

在页面初始化时,后端生成一个随机数,并下发到前端。

前端使用这个随机数作为盐值 —— 这样页面打开时,就可以开始计算了。

# 前端 - 挖矿
while Hash(X, ques) != "000000..."
    X = X + 1
end

我们选择一个适中的难度,例如 10 秒。通过多线程,还可以更快的完成计算任务,同时不影响用户体验。

正常情况下,用户发帖前已完成计算。提交时,将答案 X 带上。

如果提交时答案还未算出,则等待计算完成。。。(发帖太快,有灌水嫌疑)

# 前端 - 提交
wait X
submit(..., X)

# 后端 - 校验
if hash(X, session["pow_ques"]) == "000000..."
    ok
else
    fail
end

这样,一个「测试机器算力」的验证码实现了。

目前也有不少 hashcash 的实际应用。例如 WordPress 的 hashcash 插件。甚至还有第三方的验证服务 hashcash.io

Web 性能

当然在 Web 中使用,性能也是一大问题。如果 10 秒的脚本计算,用本地程序只需 1 秒,那攻击者就可以使用本地版的外挂了。

好在如今有 asm.js,可接近原生性能,让用户的劳动不至于贬值;对于较老的浏览器,也可以使用 Flash 作后补。在上一篇文章 0x08 节 中已详细讲解。

如果算力实在不够,也可以使用后备方案 —— 传统图形验证码。

这样,高性能用户可享受更好的体验,低性能用户也能保障基本功能。

这也算是鼓励大家使用现代浏览器吧:)

Hashcash 缺陷

不过,语言上的性能差距还是有限的,外挂不会纠结于此,而是使用更强力的武器 —— GPU。

Hashcash 的本质就是跑 hash,这是 GPU 最擅长的。例如著名的 oclHashcat,和 CPU 完全不在一个数量级。

对抗硬件的并行计算,大致有如下方案和思路:

  • 硬件瓶颈

  • 移植难度

  • CPU 算法

  • 以暴制暴

  • 自创加密

  • 串行模式

前 3 个在上一篇文章 0x09 节 提到了,下面讨论一些不同的。

以暴制暴

如果我们也能在 Web 中调用显卡计算,那 GPU 版的外挂就毫无优势了。

不过,这个想法似乎有些遥远。尽管目前主流浏览器都支持 WebGL,但都只局限于渲染加速上,并未提供通用计算接口。

当然,也可以通过一些 hack 的方式,例如曾有人尝试用 WebGL 挖比特币,但效率并不高。

如果未来 WebCL 成为标准,或许还能考虑。

自创加密

不要自创加密算法 —— 这似乎是一条真理。

在账号安全里,这固然正确。但在对抗的场合下,就未必如此了。

经典的加密算法固然权威,但研究的人也多,破解的工具也多。

自创的算法,虽然在密码学上很弱,但可以把逻辑实现的很长很复杂,并且加以混淆,就可以在「隐蔽性」上占优势了。

这样,要将其移植到 GPU 上,就困难了。

同时还可以制作模板,定期变幻代码。在攻击者破解之前,逻辑又变化了。

在对抗中,随机应变的弱算法,显然比一成不变的强算法更好。

串行模式

Hashcash 的原理,决定了它是可以并行计算的。有什么样的算法,是无法并行计算的?

如果每次计算都依赖上次结果,就无法并行了。例如 slowhash:

function slowhash(x)
    for i = 0 to 1000000000
        x = hash(x)
    end
    return x
end

这种串行的计算,自然是无法拆分的。

但这能用到 PoW 上吗?显然不行!

因为 PoW 虽然计算困难,但得 容易鉴定。而这种方式,鉴定时也得重复算一遍,成本太大了。


但发挥一下想象:如果能够设计得当,这还是可以尝试的 —— 我们可以使用 UGC 的模式,让用户来贡献算力!

首先,需要一个访问量较大的网站,在其中悄悄放置一个脚本:

# 隐蔽的脚本
Q = rand()
A = slowhash(Q)

submit(Q, A)

我们利用在线的用户,来生成问题和答案!!

当然,这项工作必须足够隐蔽,防止被好奇的用户发现,提交错误的答案。

当后端题库有一定的积累时,就可以使用验证码的模式了。

用户访问时,后端从题库中抽取一个问题,安排给前端计算:

# 后端 - 分配问题
Q = select_key_from_db()
session["pow_ques"] = Q

# 前端 - 计算问题
A = slowhash(Q)

用户提交时,后端无需任何计算,直接通过查表,判断答案是否正确:

# 前端 - 提交
submit(..., A)

# 后端 - 鉴定
Q = session["pow_ques"]
if A == db[Q]
    ok
else
    fail
end

使用预先计算的方式,避免了耗时的鉴定工作。同时,把让用户来出题,可大幅节省硬件成本。


回顾之前的 hashcash,因为散列结果是不确定的,题解时间有一定的随机性。

但 slowhash 这种方式,只是重复执行散列函数 N 次,所以解题的时间更固定。

演示

出于简单,这里演示一个 hashcash-md5 版的:

https://github.com/EtherDream/proof-of-work-hashcash

如果想看算力速度,可以查看这里

看起来好像不慢,不过对比 GPU 的速度 就相形见绌了。

所以 hashcash 如果使用经典算法,简直就是不堪一击的。或许自己写的「隐蔽式加密」算法,反而更能对抗一些。

至于 slowhash 那种串行模式的 PoW,涉及到较多策略和数据积累,本文就不演示了,下回再讨论。


(2017/03/01 补充)现在 WebGL2 出来了,着色器支持整数以及位运算,因此非常适合 PoW 计算:

Demo:https://www.etherdream.com/FunnyScript/glminer/glminer.html

用我的笔记本核显,每秒都能计算 2700 万次 SHA256 算法。换成好点的显卡例如泰坦,每秒可以 5 亿以上的 hash 计算~ (注意 SHA256 比 MD5 慢多了)


总结

最后来对比下,算力验证和传统图形验证的区别。

验证方式 验证对象 用户体验 拦截假人 实际意义
传统验证 图像识别 人脑 有交互 部分拦截 杜绝假人
算力验证 问题解答 电脑 无感知 无法拦截 减少滥用

论效果,当然还是传统验证码更好;论体验,计算对于用户是透明的,无需任何交互。

简单来说,传统验证码是防止机器「不能使用」;而 PoW 防止的则是「不能滥用」。


当然上述提到发帖那个案例,并不恰当。即使用上 PoW,限制每 5 秒发一帖,那么一分钟仍有 12 贴 —— 这速度显然还是有点太快。更适合 PoW 的场合,应该类似找回密码、或者接收短信等功能,比较容易在短时间内被大量滥用,用于增加攻击者刷接口的成本。

posted @ 2015-12-29 16:49 EtherDream 阅读(...) 评论(...) 编辑 收藏