It seems there are quite a number of people who somehow believe that adding an additional question on the registration page somehow makes their forums less susceptible to bot registrations, over the standard MyBB captcha.
Well, it's true that MyBB's captcha isn't the best (and in fact, may not be that difficult to crack), but for those blockheads out there, it's certainly better than any additional question. If anything, it's FAR easier for a bot coder to answer questions than it is to recognise squiggly text.
But I primarily dislike it for the following principle: the effort you need to put in to make it work linearly scales with the effort the bot coder has to go to.
Think about it this way. If I set up 10 questions for my board, then the bot coder just needs to code in 10 answers to their program, and they've defeated your system. Perhaps, if you're really enthusiastic, you could make up 100 questions, which means the bot coder just needs to put in 100 answers. Maybe bot coders can't be stuffed so much, and hopefully won't bother with your board, right?
Wrong. Actually, if they just coded in 10 answers, the bot would work 10% of the time. As it is a bot, it doesn't matter so much for the bot coder, since the machine just has to do more work - it will still ultimately get through.
Questions might not necessarily be easy to come up with either, especially if you're planning to be more creative. You may think everyone knows who the current president of the United States is (let's say you're diligent and update this when it changes too
), but perhaps some visitors from some, say, East Asian nations, may not be so sure.
Maybe a standard set of questions would solve it? Unfortunately no, it just means that bot coders have a common target/interface to deal with.
The method to solve these sort of issues is to use a system which doesn't scale linearly, that is, a lot more difficult for the bot coder to bypass than it is for the forum software coder to write. Which is essentially what captcha tries to do (although captcha does have its downsides).
But disregarding the design concerns I have with these systems, it appears that the people coding MyBB plugins to try to implement the above are clearly no smarter, unfortunately.
I believe LeX- was one of the first to implement it, but as you'd probably expect,
the design is completely flawed.
I have seen
some other attempts, and
this recent one has caused me to want to post this thread.
All of those involve the use of a static link between question and answer. The user won't notice this, but a (non-braindead) bot coder probably will, and certainly use this flaw to their advantage.
Here, I'll try to explain why this is stupid design and a bad idea.
How these plugins statically link question and answer
Typically, the questions and answers are stored in a database table somewhere, usually with the fields "id", "question" and "answer". There's an obvious link between "question" and "answer". The "id" column is just used as it is good database design, and makes it easier to track the two (though strictly, if questions are unique, not necessary).
Most of these plugins I see work by randomly selecting a question and displaying it on the registration page. As the system needs to also be able to handle an answer, typically the "id" is sent to the page to track which question was sent.
Simplified, the HTML would look something like this:
And the logic works something like this:
Registration page: randomly select question from table and send question id and question text to browser
Actual registration process: grab the question from the table, from the sent question id, and compare the answer given by the user with that stored in the table. If they match, it's a valid answer, otherwise, it's invalid.
Why it doesn't work
The above relies on the assumption that the question id cannot be forged by the user. Of course, this is hardly the case. Imagine if I edited the above HTML to something like:
I have effectively permanently bypassed this security. "question_id" was meant to be random, but the system never checks that that actually is the case, so I can bypass it by making it non-random, and in fact, something I select.
It doesn't matter how many questions you add to the database, as long as you don't delete the above, this "exploit" will always work and doesn't require any extra work.
The solution?
To not use static links. Similar to how MyBB has a captcha table.
When the user visits the registration page, create a temporary entry into some table containing the real question id. Eg:
And when validating, check for the real question id from the artefact id, and don't forget to delete this row from the question_sessions table regardless of it being valid or not!.
Managing a temporary table is also more work (ie cleanup), but it's the only way to do it properly.