472,975 Members | 1,757 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,975 software developers and data experts.

An unobtrusive partial alternative to CAPCHA

A while back I suggested a method of using timestamps to filter out at
least some automatic form postings. Now that I have tried it for
about 10 months, I thought it might useful to report back.

Briefly, the current time is encoded in a hidden form field when the
page containing it is served. The script that processes the form
checks the (new) current time against that in the form and rejects the
submission if it is either too fast or too slow. Unless the user
is super fast they see no effect at all. There are no accessibility
issues unless one sets the maximum permitted time too low. I currently
allow submissions from 5 seconds up to an hour after the form was
sent. Results suggest that this upper limit can safely be increased.

Even if a user is "caught", in both cases one can re-present the
form. In the case of a slow submission one would regenerate the time
stamp[1] and the user need only hit submit again.

Of course, the time stamp must be protected so that tampering could be
detected, although no examples of altered or missing timestamps showed
up in this test (which it hardly surprising, why would a bot alter
some mysterious hidden field?).

The method does seem to work well. The people seeing the submissions
report very little "spam" and there have been no complaints from users
being inconvenienced. I have not been able to study the submissions
that got through to count the failures, so all I have to go on is the
reports of "very little" spam and counts of blocked submissions.

Of the 1369 submissions in 42 weeks 518 were blocked by this method.
159 of these for being too fast and a surprising 359 for being too
slow -- way too slow. Only two of these are at all close to the one
hour cut-off time. I image many bots queue up the forms for
submission later. It seems they also keep trying without requesting
the form again since there are increasing time values later in the
test period.

The 5 second minimum look about right. The spread for fast reply
rejections was:

0s: 16
1s: 72
2s: 38
3s: 26
4s: 7

I can supply code if anyone else wants to try it.

[1] The ideal setting would be exactly 5 seconds (the minimum
submission time) old. A submit would then be accepted no matter how
fast the user was.

--
Ben.
Jun 27 '08 #1
13 1569
On Fri, 09 May 2008 03:33:13 +0100, Ben Bacarisse
<be********@bsb.me.ukwrote:
>A while back I suggested a method of using timestamps to filter out at
least some automatic form postings.
Thanks for this, Ben. very interesting and thorough research.
--
Locate your Mobile phone: <http://www.bizorg.co.uk/news.html>
Great gifts: <http://www.ThisBritain.com/ASOS_popup.html>
Jun 27 '08 #2

Ben Bacarisse <be********@bsb.me.ukwrote in
<87************@bsb.me.uk>:
A while back I suggested a method of using timestamps to
filter out at least some automatic form postings. Now
that I have tried it for about 10 months, I thought it
might useful to report back.
That's a brilliant idea, thanks a lot for your research. I'm
going to adopt this method for filtering out the
spambots... unless you consider this your IP and are going
to patent this. But that would be very, very evil of
you. :-)

--
I'm not dead, just pinin' for the fnords.
Jun 27 '08 #3
"Ben Bacarisse" <be********@bsb.me.ukwrote ...
Of the 1369 submissions in 42 weeks 518 were blocked by this method.
159 of these for being too fast and a surprising 359 for being too
slow -- way too slow. Only two of these are at all close to the one
hour cut-off time. I image many bots queue up the forms for
submission later. It seems they also keep trying without requesting
the form again since there are increasing time values later in the
test period.
What does the system do about a failed form?
Does the bounce page say why?
--

Andrew
seo2seo.com
sick-site-syndrome.com

UK Residents:
STOP THE "10p Tax Ripoff"
Sign the petition to stop the government stealing from the
very poorest tell your friends about this petition:
http://petitions.pm.gov.uk/10penceband/
Jun 27 '08 #4
"Andrew Heenan" <an*****@heenan.netwrites:
"Ben Bacarisse" <be********@bsb.me.ukwrote ...
>Of the 1369 submissions in 42 weeks 518 were blocked by this method.
159 of these for being too fast and a surprising 359 for being too
slow -- way too slow. Only two of these are at all close to the one
hour cut-off time. I image many bots queue up the forms for
submission later. It seems they also keep trying without requesting
the form again since there are increasing time values later in the
test period.

What does the system do about a failed form?
Does the bounce page say why?
For a "fast" or a "slow" submission, the page gives the user a message
and re-presents the form (with the user-provided data, of course) and
asks that the user re-submit. When the time-stamp is missing or
corrupt (i.e. the hashed version does not match the plain text
version) I also re-present the form (with a general-sounding failure
message) though the logs show that this has not yet actually happened.

--
Ben.
Jun 27 '08 #5
Pavel Lepin <p.*****@ctncorp.comwrites:
Ben Bacarisse <be********@bsb.me.ukwrote in
<87************@bsb.me.uk>:
>A while back I suggested a method of using timestamps to
filter out at least some automatic form postings. Now
that I have tried it for about 10 months, I thought it
might useful to report back.

That's a brilliant idea, thanks a lot for your research. I'm
going to adopt this method for filtering out the
spambots... unless you consider this your IP and are going
to patent this. But that would be very, very evil of
you. :-)
.... and would be inconsistent with reporting it here. It is simple to
implement and almost entirely invisible to users so, although it is
only partially effective, I hope it does get used. That was the point
of the post.

Thank you for your kind words.

--
Ben.
Jun 27 '08 #6
Gazing into my crystal ball I observed Ben Bacarisse
<be********@bsb.me.ukwriting in news:87************@bsb.me.uk:
A while back I suggested a method of using timestamps to filter out at
least some automatic form postings. Now that I have tried it for
about 10 months, I thought it might useful to report back.

Briefly, the current time is encoded in a hidden form field when the
page containing it is served. The script that processes the form
checks the (new) current time against that in the form and rejects the
submission if it is either too fast or too slow. Unless the user
is super fast they see no effect at all. There are no accessibility
issues unless one sets the maximum permitted time too low. I
currently
allow submissions from 5 seconds up to an hour after the form was
sent. Results suggest that this upper limit can safely be increased.

Even if a user is "caught", in both cases one can re-present the
form. In the case of a slow submission one would regenerate the time
stamp[1] and the user need only hit submit again.

Of course, the time stamp must be protected so that tampering could be
detected, although no examples of altered or missing timestamps showed
up in this test (which it hardly surprising, why would a bot alter
some mysterious hidden field?).

The method does seem to work well. The people seeing the submissions
report very little "spam" and there have been no complaints from users
being inconvenienced. I have not been able to study the submissions
that got through to count the failures, so all I have to go on is the
reports of "very little" spam and counts of blocked submissions.

Of the 1369 submissions in 42 weeks 518 were blocked by this method.
159 of these for being too fast and a surprising 359 for being too
slow -- way too slow. Only two of these are at all close to the one
hour cut-off time. I image many bots queue up the forms for
submission later. It seems they also keep trying without requesting
the form again since there are increasing time values later in the
test period.

The 5 second minimum look about right. The spread for fast reply
rejections was:

0s: 16
1s: 72
2s: 38
3s: 26
4s: 7

I can supply code if anyone else wants to try it.

[1] The ideal setting would be exactly 5 seconds (the minimum
submission time) old. A submit would then be accepted no matter how
fast the user was.
You could enhance it by placing the time into a db, and upon submission,
compare the value in the db. Generate a unique identifier as a hidden
field, and compare that to the one in the db with the time submitted.

--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

Jun 27 '08 #7
"Ben Bacarisse" <be********@bsb.me.ukwrote in message
news:87************@bsb.me.uk...
>A while back I suggested a method of using timestamps to filter out at
least some automatic form postings. Now that I have tried it for
about 10 months, I thought it might useful to report back.

Briefly, the current time is encoded in a hidden form field when the
page containing it is served. The script that processes the form
checks the (new) current time against that in the form and rejects the
submission if it is either too fast or too slow. Unless the user
is super fast they see no effect at all. There are no accessibility
issues unless one sets the maximum permitted time too low. I currently
allow submissions from 5 seconds up to an hour after the form was
sent. Results suggest that this upper limit can safely be increased.
<snip>

Fascinating Ben. This is an area where I have an active interest, so I may
borrow your idea (no need for code, but the concept is priceless.) I know
its not a complete answer to spam, but it all helps.

One thing I would say is that I wouldn't advertise the idea. Once spammers
catch on to it it shouldn't take them much effort to get round it. That
said, most spammers seem to be absolute idiots so the idea may be sound for
many years to come.
--
Brian Cryer
www.cryer.co.uk/brian

Jun 27 '08 #8
Adrienne Boswell wrote:
Gazing into my crystal ball I observed Ben Bacarisse
<be********@bsb.me.ukwriting in news:87************@bsb.me.uk:
>A while back I suggested a method of using timestamps to filter out at
least some automatic form postings. Now that I have tried it for
about 10 months, I thought it might useful to report back.

Briefly, the current time is encoded in a hidden form field when the
page containing it is served. The script that processes the form
checks the (new) current time against that in the form and rejects the
submission if it is either too fast or too slow. Unless the user
is super fast they see no effect at all. There are no accessibility
issues unless one sets the maximum permitted time too low. I
currently
>allow submissions from 5 seconds up to an hour after the form was
sent. Results suggest that this upper limit can safely be increased.

Even if a user is "caught", in both cases one can re-present the
form. In the case of a slow submission one would regenerate the time
stamp[1] and the user need only hit submit again.

Of course, the time stamp must be protected so that tampering could be
detected, although no examples of altered or missing timestamps showed
up in this test (which it hardly surprising, why would a bot alter
some mysterious hidden field?).

The method does seem to work well. The people seeing the submissions
report very little "spam" and there have been no complaints from users
being inconvenienced. I have not been able to study the submissions
that got through to count the failures, so all I have to go on is the
reports of "very little" spam and counts of blocked submissions.

Of the 1369 submissions in 42 weeks 518 were blocked by this method.
159 of these for being too fast and a surprising 359 for being too
slow -- way too slow. Only two of these are at all close to the one
hour cut-off time. I image many bots queue up the forms for
submission later. It seems they also keep trying without requesting
the form again since there are increasing time values later in the
test period.

The 5 second minimum look about right. The spread for fast reply
rejections was:

0s: 16
1s: 72
2s: 38
3s: 26
4s: 7

I can supply code if anyone else wants to try it.

[1] The ideal setting would be exactly 5 seconds (the minimum
submission time) old. A submit would then be accepted no matter how
fast the user was.

You could enhance it by placing the time into a db, and upon submission,
compare the value in the db. Generate a unique identifier as a hidden
field, and compare that to the one in the db with the time submitted.
Or, better yet, in the session.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Jun 27 '08 #9
Adrienne Boswell <ar****@yahoo.comwrites:
Gazing into my crystal ball I observed Ben Bacarisse
<be********@bsb.me.ukwriting in news:87************@bsb.me.uk:
>A while back I suggested a method of using timestamps to filter out at
least some automatic form postings.
<snip>
>Briefly, the current time is encoded in a hidden form field when the
page containing it is served. The script that processes the form
checks the (new) current time against that in the form and rejects the
submission if it is either too fast or too slow.
<snip>
>Of course, the time stamp must be protected so that tampering could be
detected, although no examples of altered or missing timestamps showed
up in this test (which it hardly surprising, why would a bot alter
some mysterious hidden field?).
<snip>
You could enhance it by placing the time into a db, and upon submission,
compare the value in the db. Generate a unique identifier as a hidden
field, and compare that to the one in the db with the time
submitted.
I am not sure that would add anything. Currently, the server sets the
hidden field to:

time + ":" + md5(time + "some secret string")

When the form comes back, the server splits the string at the ":" and
it computes md5(part-before-the-colon + "some secret string").
Checking that this md5 hash matches the part after the colon is
equivalent, I think, to looking up a unique ID in a server-side DB
(but simpler to do).

--
Ben.
Jun 27 '08 #10
Jerry Stuckle <js*******@attglobal.netwrites:
Adrienne Boswell wrote:
>Gazing into my crystal ball I observed Ben Bacarisse
<be********@bsb.me.ukwriting in news:87************@bsb.me.uk:
>>A while back I suggested a method of using timestamps to filter out at
least some automatic form postings.
<snip>
>You could enhance it by placing the time into a db,
<snip>
Or, better yet, in the session.
See my reply to Adrienne Boswell. I don't think you gain much by
using session data. There is no reason not to store the data in the
session, but given the checks I make, I don't think it adds much.

--
Ben.
Jun 27 '08 #11
Ben Bacarisse wrote:
Jerry Stuckle <js*******@attglobal.netwrites:
>Adrienne Boswell wrote:
>>Gazing into my crystal ball I observed Ben Bacarisse
<be********@bsb.me.ukwriting in news:87************@bsb.me.uk:

A while back I suggested a method of using timestamps to filter out at
least some automatic form postings.
<snip>
>>You could enhance it by placing the time into a db,
<snip>
>Or, better yet, in the session.

See my reply to Adrienne Boswell. I don't think you gain much by
using session data. There is no reason not to store the data in the
session, but given the checks I make, I don't think it adds much.
Just one more layer of security - it isn't in the web page.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Jun 27 '08 #12
Jerry Stuckle wrote:
Ben Bacarisse wrote:
>Jerry Stuckle <js*******@attglobal.netwrites:

>>Adrienne Boswell wrote:

Gazing into my crystal ball I observed Ben Bacarisse
<be********@bsb.me.ukwriting in news:87************@bsb.me.uk:
A while back I suggested a method of using timestamps to filter out at
least some automatic form postings.
>
<snip>
>>>You could enhance it by placing the time into a db,
<snip>
>>Or, better yet, in the session.
See my reply to Adrienne Boswell. I don't think you gain much by
using session data. There is no reason not to store the data in the
session, but given the checks I make, I don't think it adds much.


Just one more layer of security - it isn't in the web page.

With any use of sessions I always have to wonder; what about people who
have cookies disabled?

Do you insist they enable cookies, or go with the flawed trans_sid method?

--
*****************************
Chuck Anderson Boulder, CO
http://www.CycleTourist.com
Nothing he's got he really needs
Twenty first century schizoid man.
***********************************

Jun 27 '08 #13
Chuck Anderson wrote:
Jerry Stuckle wrote:
>Ben Bacarisse wrote:
>>Jerry Stuckle <js*******@attglobal.netwrites:
Adrienne Boswell wrote:

Gazing into my crystal ball I observed Ben Bacarisse
<be********@bsb.me.ukwriting in news:87************@bsb.me.uk:
>
>
>A while back I suggested a method of using timestamps to filter
>out at
>least some automatic form postings.
>>
<snip>

You could enhance it by placing the time into a db,
>
<snip>

Or, better yet, in the session.

See my reply to Adrienne Boswell. I don't think you gain much by
using session data. There is no reason not to store the data in the
session, but given the checks I make, I don't think it adds much.


Just one more layer of security - it isn't in the web page.


With any use of sessions I always have to wonder; what about people who
have cookies disabled?

Do you insist they enable cookies, or go with the flawed trans_sid method?
PHP will handle the session id through a get parameter. Others do
similarly.

But then, people who surf with cookies disabled are uses to sites which
don't work.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Jun 27 '08 #14

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: pantagruel | last post by:
I have an old web application I did where browsers with dynamic capabilities received a drop down menu on the top of the page and a fold out on the left hand side of the page and non-dynamic...
9
by: Gomaw Beoyr | last post by:
Two question about the "partial classes" (in the next wersion of ..NET). Question 1 ========== Will partial classes (in the next version of C#) have to be declared "partial" in ALL places. ...
16
by: pawel.pabich | last post by:
Hajo, I would like to have 2 my own partial classes. For example: Default.aspx.cs Default2.aspx.cs and they both will relate to Default.aspx page.
7
by: Julian Jelfs | last post by:
Hi, I had an aspx pag in .Net 1.1 with a label on it. As such I had a code behind page with a declaration for that label. When I convert to Asp.Net 2.0 the code behind is converted to a...
10
by: ptass | last post by:
Hi In asp.net 2.0 an aspx files .cs file is a partial class and all works fine, however, I thought I’d be able to create another class file, call it a partial class and have that compile and...
0
by: Matt | last post by:
I have a problem when I select node elements from an xml file and validata each node againts the schema. I use XmlValidatingReader and it complains about elements not being declared. I have...
9
by: Fat Elvis | last post by:
I'd like to extend some of my Asp.net pages by using Partial Classes. Example ASP.Net Page: public partial class Admin_Customer : System.Web.UI.Page { protected void Page_Load(object sender,...
6
by: lokchan | last post by:
i want to create a vector of pointer s.t. it can handle new and delete but also have std::vector interface can i implement by partial specialization and inherence like follow ? #include...
1
by: kaoruHobbs | last post by:
My code does not work , i cannot find what is wrong with it. Please help me ! i don not want to use onclick in HTMl file to make unobtrusive javascript. html <form id="checkSudoku" action="#">...
12
by: lorlarz | last post by:
Unobtrusive JavaScript leads to BUILDERS (e.g. drag drop activity builder) Once you totally remove JS from a web page, and learn the shortcuts and efficiencies provided by a library like...
0
by: lllomh | last post by:
Define the method first this.state = { buttonBackgroundColor: 'green', isBlinking: false, // A new status is added to identify whether the button is blinking or not } autoStart=()=>{
2
by: DJRhino | last post by:
Was curious if anyone else was having this same issue or not.... I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 4 Oct 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM) The start time is equivalent to 19:00 (7PM) in Central...
0
tracyyun
by: tracyyun | last post by:
Hello everyone, I have a question and would like some advice on network connectivity. I have one computer connected to my router via WiFi, but I have two other computers that I want to be able to...
2
by: giovanniandrean | last post by:
The energy model is structured as follows and uses excel sheets to give input data: 1-Utility.py contains all the functions needed to calculate the variables and other minor things (mentions...
4
NeoPa
by: NeoPa | last post by:
Hello everyone. I find myself stuck trying to find the VBA way to get Access to create a PDF of the currently-selected (and open) object (Form or Report). I know it can be done by selecting :...
3
by: nia12 | last post by:
Hi there, I am very new to Access so apologies if any of this is obvious/not clear. I am creating a data collection tool for health care employees to complete. It consists of a number of...
0
isladogs
by: isladogs | last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, Mike...
4
by: GKJR | last post by:
Does anyone have a recommendation to build a standalone application to replace an Access database? I have my bookkeeping software I developed in Access that I would like to make available to other...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.