I have spent way too much time thinking about this problem so I decided it is time to put it to rest:
Per this commit the OP here is “fixed”
https://github.com/discourse/discourse/commit/d5d8db7fa82d314adcd064882a57a48b3eb088e2
The fix is kind of complicated and involved 2 pieces that I am happy I have gotten to.
-
I tightened the logic for honeypot and challenge a lot
-
I added a client side only workaround for chrome bug in autocomplete, I am comfortable with this cause it does nothing to change the server side protocol.
Previously we used to reuse our honeypot and challenge random string for all account registrations on the site, this makes scripting creating accounts pretty trivial cause you just hardcode a value once.
The new implementation gives every single user a unique string to validate which is bound to your cookie store (in our secure session store). This string expires after an hour.
Meaning when scripting this stuff you are forced to regularly make calls to get brand new challenges and honeypots between requests and you can’t just steamroll accounts in.
The workaround in 2 is simply shuffling out a INPUT chrome is getting confused about and replacing it with an INPUT of type text it is not getting confused with.
Overall I don’t feel that (2) makes it any easier for a “generically” coded bot that registers accounts on unknown sites. For starters the bot would need to use Chrome web driver, parse all our ember and then follow a very specific flow. This particular barrier is very low and nothing compared to the new rotating per user challenges.
As to adding proof of work, I would like to wait a bit, not because it is particularly hard to build but more cause I don’t want to go shopping for the fastest sha1 algorithm out there and then send it to the client on demand.
Leaving this open for a bit so people can confirm my fix, fixes the issue. Will close this in a week.