Possibly the worst CAPTCHA ever.
epcounty.com
epcounty.com
The worst I've seen was one where the captcha was injected into the HTML, then scrambled with CSS and scome scripting so that it would be difficult for a human to type it.
I think it was for a bank.
And to be honest, it was still easier to process than some of the recaptcha I've come across.
(I'll just conveniently ignore the fact that it's made in Flash.)
OpenID is the answer to this problem. Let the likes of Google/Facebook/Yahoo/Symantec worry about this problem.
We need to stop giving emails and passwords out to 200+ sites and wondering why we get spam and regular password resets.
In September 2013, Janrain announced that MyOpenID.com would be shut down on February 1, 2014; a pie chart showed Facebook and google dominate the social login space as of Q2 2013.[67] Facebook has since left OpenID; it is no longer a sponsor, represented on the board, or permitting OpenID logins.[15][68]
source: http://en.wikipedia.org/wiki/OpenID
Generally everyone moved away from OpenID in favour of OAuth and even when they were implementing it most big companies were just OpenID providers, thereby totally defeating the openness part.
Based on the above, I could safely say, it's not worth implementing OpenID.
I would suggest doing research on the topic before making bold statements like this.
> We need to stop giving emails and passwords out to 200+ sites and wondering why we get spam and regular password resets.
Sure, let's just use Facebook and Google logins everywhere I'm sure nothing bad could come of it aside from the NSA getting full access to EVERYTHING that we use then.
If you are bothered by spam and the likes, just register yourself a throwaway email account.
And if you hit the button to get a new CAPTCHA, the old letters vanish with a sparkly effect before the new ones fall down.
Also interesting: Animated Captcha is said to be harder and easier to crack at the same time. http://phys.org/news/2012-02-stanford-team-animated-nucaptch...
/me keeps up the good fight.
First, the client should be actively and asynchronously working on the puzzle when the page loads, so when the submit button is pressed, the puzzle is solved, and ready to be submitted to the server. Asynchronous JavaScript has already been solved. Even for a Raspberry Pi, a 16-byte Hashcash puzzle can likely be solved before the user has finished typing in the form.
Second, the point of Hashcash is to stop spammers from mass POST attempts. Form spammers rely on bots, without JavaScript, to mass POST to forms, millions of times per day. As soon as JavaScript is required, this immediately stops 90% of the bots in use, right now. Of course, they'll adapt, with JavaScript VM bots if Hashcash is the norm, which then ties up the client solving the puzzle. The longer the client is tied up, the less it can spam in a given amount of time. It _drastically_ slows down the amount of comments a spammer or zombie network can perform. As computing gets more powerful, the Hashcash minting size can be increased, to continue tying up the bots. "Blowing through them" couldn't be a bigger exaggeration and further from the truth.
Third, properly implemented Hashcash is designed to prevent double spending. So, once the token is spent, it cannot be spent again. Even better implementations will not allow tokens that have not been minted within a certain timeframe, such as 24 hours. The Hashcash specification has the timestamp as part of the token. This discourages mining the tokens early, for spending later.
Lastly, captchas have shown to be entirely ineffective against bots. Do a search for beating captchas, and you'll see the sad state of affairs. Captchas are getting harder for humans to interpret, because bots are getting better at OCR, and defeating them, with increasing reliability. In every instance I've deployed Hashcash into a web form, I have yet to see spam come through. In one site, as of the time of this writing, Hashcash is solely responsible for blocking 670,624 spam POST attempts in a 10 year run.
The big drawback, is forcing JavaScript to be enabled, in able to POST to a form. From what I've seen on the virtual web hosts I administer, it seems to be about 10% of the web traffic has JavaScript disabled, on average. This might be acceptable, and it might not.