CAPTCHA, if you can

“Should the United Kingdom remain a member of the European Union?” or“A ddylai'r Deyrnas Unedig ddal i fod yn aelod o'r Undeb Ewropeaidd?”, in Wales.


This was the question asked of UK citizens on the 23rd of July, 2016. Those who wished to leave the European Union (EU) were in the majority, with a 52 - 48 split. With such a slim majority, many who wished to remain in the EU found ways to express their displeasure. One of the ways they did this was to sign an online petition calling for the UK Government “to implement a rule that if the remain or leave vote is less than 60% based a turnout less than 75% there should be another referendum.” Despite the poor wording[1], the petition managed to attract nearly 4,000,000 signatures within only four days - the largest amount ever received. Reports surfaced that the large number of signatures may have been the result of fraud, and shortly thereafter approximately 77,000 were removed. How did this happen, and what could have been done to prevent this apparent undermining of democracy?

The main reason the petition was open to abuse was because no checks were put in place to ensure that the entity signing the petition was actually a human - let alone a human being who was resident in the United Kingdom. The steps required to be followed to sign the petition could be automated by codifying them in a computer program - colloquially known as a bot. The web application did make an effort to prevent automated signing by requiring that entities click on a link sent to their email address, but even this could be automated, as we’ll see.

The page that required entities to enter their personal details did not contain a CAPTCHA, which is a type of test to determine whether or not the user is human. I’m sure many readers will have encountered a CAPTCHA during their time on the Internet. They often consist of an image containing text, which has been distorted in such a way that a computer would struggle to recognise, but that a human (typically) wouldn’t. More generally though, a CAPTCHA is a challenge that bots would struggle to complete, but a human wouldn’t.

Because the petition site failed to include a CAPTCHA, it was possible to automate submitting signatures using fake names and postcodes. The email address had to be real though because a link was sent to this email address, and the petition was not considered signed until this link was clicked. However, there are services online that allow the creation of disposable email addresses. The bot could use one of these services to provide the petition with a disposable email address for each submission and then periodically check those for messages containing the verification link. Once the link was followed, the signature was considered verified and accepted as genuine.

As annoying as CAPTCHAs might be, they have proven successful in preventing the automated submission of data, and the fact that the petitions website failed to include one is an oversight. Any data collecting form that does not require authentication (e.g. a username and password) should be protected with a CAPTCHA or some other mitigation to prevent automated submissions by bots. However, security is an arms race and there are services online that will solve CAPTCHAs in near real-time for a small fee.

[1] The “remain” or “leave” vote will always be less than 60%. If one side receives more than 60% of the votes, than the other side will obviously be less than 60%. Therefore, the conditions laid out by the petitioner will always result in another referendum. A more accurate wording should have been “to implement a rule that if the winning vote for remain or leave is less than 60% based a turnout less than 75% there should be another referendum.”

Comments

Post a Comment

Popular posts from this blog

The Business Case for Increasing Minimum Password Lengths

I love getting root. I also love looking for other people getting root. What I don’t love doing is telling how they can stop other people from getting that sweet sweet root. I know I’m not alone but unfortunately this is what gets many InfoSec folks paid. InfoSec folks have to explain to lay people how to make things more secure in a way that is easy to understand. For many this doesn’t come easily. Your root can be the sweetest root, but if you can’t explain to others why and how it needs to be fixed then you’ve arguably failed as an InfoSec professional.  I’ve recently been in this situation. I’ve needed to justify to senior leadership increasing the minimum password length for Active Directory domain from the default 8 characters to 14. This was a tough sell because users don’t like long passwords. They’re considered harder to remember and a pain to have to enter every time they want to log in. To make this seemingly bitter pill easier to swallow, I also recommended that the ...
Read more

Password Presentation - P@ssw0rds

In my last post I provided a template business case that InfoSec people could use to justify increasing the minimum password length while also reducing the frequency of enforced password changes. The reasoning being that if users are not forced to regularly change their passwords then they will be more inclined to select complex passwords that are difficult for an attacker to guess or crack (but still easy for them to remember). This is a sound business case but, to really make the point, wouldn’t it be great to also provide empirical evidence that with the default password policy users are actually using weak passwords!? With some technical knowledge, password hashes can be dumped from a domain controller and subjected to a cracking attack. Chances are, that in domain with a default password policy, many users’ plaintext passwords will be revealed within a reasonable amount of time. Metrics can then be derived, such as the percentage of passwords that were successfully cracked...
Read more