Re: basic captcha

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Just a few notes on the previous responses.

Delaying with JavaScript, like validating with JavaScript is a rather
pointless endeavor. Think about it, you are putting your "limiting"
mechanism, on the hackers' computer... You can still post to your
server as fast as you want.

With regards to using external APIs and slow-downs, in my experience
it's because the coders of the website have no idea how browsers work,
as a result they will throw in a blocking action at the top of their
list and then you have to wait for google to serve you content before
you get the rest of your page.

With regards to capchas, somewhere around 80% if capcha software are
easily bypassed by current OCR software, another maybe another 15%
would be in the "works 70-80% of time" category, leaving only about 5%
of capcha software that is hard to impossible to crack with current
freely-available OCR technology. I am of the idea that if it annoys
users, and still doesn't work, it's not the best of solutions.

Honeypots, they will help against some robots, as those become more
advanced, honeypots like extra fields will begin to fail, especially
if you put easily parsable comments to help me them :P. Also doesn't
do anything about people who actually read your page code.

Tokens, tokens are something that really hasn't been discussed here
yet, but they can act just as well as a honeypot, actually in part
just like a honeypot, and probably offer a better protection.
For example consider registrations (part pseudo code):

1. You send me a request

2. I send you back a page, with a 2-part token,
---- one in html <input type="hidden" class="token" name="token"
value="S0mETOk3n"/>
---- one in JS,  $('.token').val( $('.token').val() + b64d("SOM3B64=="))
---- perhaps even a temp cookie or something

3. You then fill in the form and press submit
3.5. Submit posts the data without refreshing the whole page
(increasing the level of complexity of a system needed to exploit
this)

4. I send you an email and a page asking to not close out your page,
and for you to go check your email
4.5 i send you another bit of a token with my response

5. You go and check your email and have a short bit of text to paste
back into the new input on the page

6. You paste the text and press finish

7. I take your html token part, 2 js parts and email part (6
alphanumeric characters will do fine), combine them and send them back

Why i prefer that to a typical honeypot?
One of the biggest reasons, is state, you would have to maintain state
through the process you get a bit of a token every time you do
something
Another one is that it uses multiple pieces that are typically
available in full-fledged browsers
For registration scenario, there is an inherent time out in email
delivery, meaning that you have a built-in limit to the amount of
requests anyone who has bypassed your honeypot, can make.


--
The trouble with programmers is that you can never tell what a
programmer is doing until it’s too late.  ~Seymour Cray

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux