FYI @codinghorror chrome team still did nothing.
Situation remains broken for chrome, we can trivially fix by replacing our spam protection honeypot with some sort of proof of work
Closing for 2 more months
3 Likes
Chrome team seem keen to fix this but need logs here:
https://bugs.chromium.org/p/chromium/issues/detail?id=987293
I will see if I can collect some tomorrow. If anyone beats me to it, you are my hero, flag this post.
EDIT … sent them logs.
10 Likes
@codinghorror this is going in circles at Google. They say the behavior is by design and that they have no way of accurately detecting if a textarea is visible or not.
The general reply here is “It is trivial for a bot to bypass this, so what is the point”. I don’t really have a reply here I kind of agree with them, the honeypot is kind of silly and I can replace it quite easily with something else to ensure a user at least is running JavaScript when registering an account.
I have already spent so much time on this and I feel like I am tilting at windmills, I just want to put a fix in place and move on here.
4 Likes
Ok but I want it to be a pretty complex proof of work. Is there existing code we can pull?
1 Like
Yeah I can pull something together, it will certainly be better than our current system. Our current system of “proof of work” is “reverse a string”
2 Likes
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.
9 Likes
This topic was automatically closed after 6 days. New replies are no longer allowed.