Proof of work - an unobtrusive alternative to captchas | Hacker News Reader

Proof of work - an unobtrusive alternative to captchas

bennolan.com

23 pointsclyfe40 comments

Proof-of-work systems are cool, but this doesn't work, economically.

A proof-of-work system requires a verifiable amount of computation time before you can do something. The idea is that "honest" computers are mostly idle, but that this should slow down spammers.

The problem is that it may not be possible to seriously inconvenience spammers without seriously inconveniencing honest clients, even if both run native code (e.g. hashcash). The article limits the honest guy to some crappy smartphone's interpreted Javascript running an algorithm that is very much optimized for 32-bit machine words (instead of Javascript's floats). If the smartphone can do the work in 10sec (which is annoying enough), the spammer should be able to do it in at most .01sec: enough to send ~8.6 million messages per day.

I think your statement is too broad. I agree that it wouldn't work on the web, for the reasons that you state. But it is a useful approach in a lot of other situations. For example, I've seen it used successfully in gaming to prevent DOS attacks.

Client Puzzles have a couple nice properties: the difficulty can be adjusted & they can be implemented in a completely stateless manner. The last point is the most important because it what protects against a [D]DOS attack.

I agree they are cool, but why not just use a similar solution that does the same thing. Require a couple second server wait time in repeated requests from the same IP. Even if the spammers had over 1000 IPs (and most don't) this would still kill the speed with which they can mass request. Doing this would allow slow machines to get the same wait time as everyone else.

I wouldn't necessarily suggest it, but imagine if this were implemented at the protocol level and handled with native code built into clients.

There could be a new HTTP request method called "SUBMIT" which works like a POST request except with an added step for proof of work. When making a SUBMIT request, the client opens a connection to the server, sends the initial request header with the SUBMIT method, and receives a proof of work challenge as an HTTP field in the server's response. The client then processes the challenge and sends its proof of work to the server which verifies it and sends an OK. Then the client sends its url-encoded data to the server, the server sends its response data, and the connection closes.

Then performance impact and behavior would be fairly uniform for all clients, especially if a standard library of problems and problem solving code were used by them, so you wouldn't have to worry about finding a problem that isn't too hard for poor Javascript implementations to solve while still being too easy for native code implementations in spamming tools to process. There could even be an added field for the server to inform the client what problem type is being used, allowing the addition of new problem types of different difficulty and performance requirements in the future without any more updates to the protocol.

Personally though, I don't like proof of work solutions. Sure, they add some computational cost to spamming, but the mass implementation and use of any proof of work solution would probably just create a new, lucrative market for botnet hackers to sell their services to. Besides that, it just feels like the wrong solution to me.

Messing around with your clients performance doesnt seem like a nice alternative to a captcha for me...

There is plenty of people with bloated windows machines that even using a modern browser struggle to perform properly, I dont think overloading them with extra work would help making their experience easy and smooth.

Just my 2 cents.

This strangely reminds me of how Bitcoin works under the hood -- basically, a proof of work. Anybody up to creating a Bitcoin plugin for browsers as an alternative to captchas? Either as .xpi or a Flash file to be included on the website?

That won't really work. See http://news.ycombinator.com/item?id=2407149 (summary: generating bitcoins takes too long and both client and server would have to trust each other.)

It will work, but the scheme has to be simplified some. Coins can be generated ahead of time, and then the client just pays a 0.001 bitcoin (via browser plugin, automatically) to the server instead of jumping through the captcha hoops. No trust is required, it's just a usual bitcoin payment.

I thought a bitcoin transaction was only considered successful after a sizable number of other bitcoin participants have based their successful computations on it?

If that is correct, bitcoin validation isn't fast enough for instantaneous forum postings when the spammers can be assumed to be as dishonest as fits them.

IIRC, you can almost instantly verify that certain bitcoin wasn't spent someplace else before, which would be good enough. Now, the attacker can use the same bitcoin for several web forms simultaneously, but 1) the scope of this attack is limited by the time window, and 2) if the server discovers a fraudulent transaction in, say, a few minutes, the spammy comment can be automatically deleted then.

Indeed; these are basically Bitcoin microtransactions. I always thought an "if you really believe this deserves to be ranked higher, invest $0.01 in its prospective well-being" model would be good to base a social news website upon, but real microtransactions have always been halted by the static friction people feel when parting with even a single cent of Real Money. Paying in small amounts of CPU time (that have worth, but don't feel like they do) could get around that.

(Note that, even if this were implemented, you probably wouldn't be doing the work in the browser, but rather just spending (fractions of) coins you had already generated and placed into your bitcoin wallet. Thus, this wouldn't slow down spammers—as they could just buy coins on the open market—it would just make the marginal cost of a single spam transaction more (and hopefully prohibitively) expensive. On the bright side, even if it happened that Bitcoins were too comparatively-devalued to prevent spam, spammers would then, by buying Bitcoins en masse, become the de-facto Bitcoin-to-USD exchange!)

This wouldn't work would it? If the server sends the client a number (n), surely, I (as a spammer), could simply pre-calculate the largest integer (p) where the hash starts with 0000. The server cannot verify this is the wrong answer, without calculating all the hashes between n and p.

So I can send back p as my answer for all values of n, without needing to do any client side calculation

You're right, the server needs to send additional unique information, as in http://en.wikipedia.org/wiki/Hashcash

    Server:

    uniq_id = long random string
    salt = long random string
    work_number = random integer
    
    storage[uniq_id] = salt
    send(uniq_id, salt, work_number)


    Client: 

    new_number = work_number

    while hash[:4] != "0000"
      hash = hashfunc(salt | new_number++)

    send(uniq_id, new_number)
    

    Server:
    
    salt = storage[uniq_id]
    if no salt
         deny

    delete from storage[uniq_id]

    if hashfunc(salt | new_number)[:4] != "0000" 
         deny
    else
         allow

May also add timestamps.

Proof of work surely is a very interesting concept, but I'm not sure it's preferable to other methods.

As far as I'm concerned using up 8 seconds of user computation time (during which you cannot guarantee responsiveness) is just as bad as throwing a cryptic CAPTCHA field in her face.

Methods such as timestamping, honeypots and dynamically added fields yield very good results for bot recognition.

Can you expand on the timestamping method? I thought this could be easily circumvented by adding random delays to the bot requests.

You are absolutely correct. Timestamping alone does not suffice, but it is another layer of defense which does work. Most bots do not have random delays.

I'll try to look up some numbers on this.