Where would this leave people with JavaScript disabled, and users of assistive technologies without the option?

Con: a teeny tiny percentage of your audience will either have javascript or cookies disabled

You just have to weigh this against your alternatives:

* Less security for your forms + spammers probing for weak points
* Annoying CAPTCHA tests that suppress communication with visitors

In addition, in the demo, I wrote about a warning message that could be shown if javascript is disabled. You could put a link in this message to a different form, or other options for contact.

My tutorial provides a possible solution with lots of upside but with certain downside.

It’s up to you to decide if the benefits outweigh the costs.

Just one small remark. Your demo.php file also references cookieFunctions.js, which doesn’t seem to be either needed nor included …

Keep those tutorials coming

This is a technique.

It has benefits - and it has drawbacks.

As others have commented, it can be useful for some developers. For you, it is of no use.

’nuff said.

I proposed something similar to this in a comment, but after reading this, and being impressed, realized that you could add another layer to make it totally non JS reliant.

Have a CAPTCHA in the form which is removed by JS. This way works with JS off.

Regards,
Deep

All a remote script needs to do is retrieve the page, then request the hash and send along the cookie as it does it….then submit the form. Sure, it’s a little bit more work, but not more than 10 minutes.

Anything a browser can do without the user interacting a bot can do without a user. I think you understand this since you talk about it just making it harder, but I think you overestimated the level of security this will provide.

It’s a great idea though. I came up with something similar a few years ago…I never implemented it though since I haven’t needed it (lucky me!).

Although it is not quite the holy grail, it’s an easy way to separate visitors from bots.

Thank you very much for this example!

A sidenote though, which has nothing really to do with captchas: a common pain in the * is the use of mail forms on websites by bots, to send masses of spam from your server.
If the bot wants to succeed, he has to put a header (mime-type) into the textarea.
Let PHP filter this:
$tmpstr = implode(”",$_POST);
if(strpos(”mime-type”,$tmpstr)===true){
exit(”Your message is considered spam”);
}

That, combining with this JQuery addon, should be quite waterproof I think. Just my two cents

As for the slideshow, it’s a javascript you can download free. I believe if you look at the javascript file of the slideshow you will see a url to the author’s website.

Its a bit simpler than this technique, and I suspect probably doesn’t work as well, but its so easy to implement that its worthwhile to stay out of the ‘low hanging fruit’ example…

When the input-form is generated, it is marked “do not cache” (so the browser will actually retrieve something new from us), and it includes a hidden-field containing an unrecognizable hash.

This hash is based on the IP-address of the requester, a salt-value and a garbage string known only to us. It masks, by means of exclusive-OR, the server date/time and another checksum/hash.

When we receive the input, we unmask it, verify the checksum in the unmasked data (to know that the unmasking worked), then check the timestamp thus revealed.

This timestamp must be (say) more than 30 seconds old, and not more than 15 minutes old.

Typically, spam-bots are in a hurry. This stops them dead.

!empty($_POST[’name’])

in the first condition and works great now..

I don’t mind being wrong.

But there are four things that tell me these kinds of replies are silly:

1) Adding similar code dramatically reduces automated spam attempts on real life websites over and over again. Based on actual experience, it works quite well.

2) From what I gather, the comments about how easy this is to beat talk about the *specific* demo I’ve put up… But tweak the name of the hidden text field, the name of the cookie, and some of the validation, and your bot code is SOL.

3) I would love to see some php or cgi that grabs form fields that are generated through DOM, as jquery would do. Not saying it can’t be done, just haven’t come across it yet. I’m sure it exists, so show me.

4) This isn’t about creating a form that is unbeatable… I clearly say that in my post. It’s about thwarting automated spam. If the technique eliminates 99% of most automated spam attempts before it begins, does it have any worth? I think so.

If you, or someone else reading this post, can create the code I’m told is so easy to create but I haven’t seen yet, I’ll put my money where my mouth is.

Show me the code that will remotely:
1) read all cookies set, regardless of cookie name, even session variables
2) read all form fields, regardless of name, including fields that are added after page load using javascript DOM methods

I’ll pay the first person to show me such code $50 if it meets those specific criteria.

Not saying it can’t be done…

But show me.

1) I agree with that it can works. Actually in my opinion, main reason is not spammers cannot work out this, but because this method havn’t applied commonly, they do not want waste time on such few sites.
2) If this method is used in a widely used open source web application, most of users are lazy or unable to
change the code, except using a builtin function. So tweak the name maybe not as effective as considered.
3) CGI may unable to do those, but the desktop application can work out.
4) Generally speaking, i like this quick and easy method, and will use it in my personal site.

I have currently no way to run the JS within a bot, and no common way to defeat most of CAPTCHAs. On the other hand, write a specific spam bot is much easier.
1) all cookies set can be read at HTTP response header: Set-Cookie . Session variables cannot be read , but in MS ASP(i’m a ASP programmer) server-IIS, session is implemented with a cookie like ‘ASPSESSIONIDSDKFJSFS=KSDJFKLSDFSDFSF’ (this string length maybe not wrong, just show the pattern), sending the same ASPSessionID, IIS will process requests as same user.

2) This criteria seems hard to me - I’ll wrote a script-supported browser if i can do this. It’s also difficult/complex to automaticly read the form fields name. Easier implementation is watch out a valid user operation, capture all the request data, then simulate that in bot.

If you really want a bot, I’ll write one working but may not meets the criteria.

At last, I still interest at the $50 - it’s almost equals my monthly living cost

Anyhow, thanks for your replies.

Ideally, I’d be interested in a PHP script that did what I’ve laid out.

And I agree… it would be very difficult.

Your suggestion of a browser type application is the one that I see as most likely for doing everything I’ve requested for the “prize” money.

That said, this reiterates what I’ve said before: this isn’t the “end all be all” of thwarting automated spam, but in practice it knocks out almost all of it.

and just to be annoying, firefox = open source, firefox = web platform capable of doing the above as a plug in. you do this all the time with you use your fancy video grab plug ins or seo junk…

come to think of it , a ff/ie plugin that inserts a javascript to grab the form variable then submit and clear/alter cookies. reload page repeat.

conclusion, people could sent bogus form information and spam the world using this method.

Then when you get a post you would first look to be sure the timestamp is within your pre-determined timeframe and that its md5 hash is correct.

If so, go with it. If not, drop it on its head.

But then, of course, I have some comments.
1. I assume you set the cookie instead of a session to keep your solution stateless? Because storing it in a session variable would be just as easy and theoratically more secure (in your solution, an attacker can brute force the salt, and yes I read your 1000 comments on silver bullets).

2. As Mike Robinson put forward, typical bot behaviour can be characterized by either slow or fast responses. So putting a lowerbound on the timestamp is really a good idea.

3. The comment by Tarwin (instead of the warning message, remove a CAPTCHA) is extremely good, for multiple reasons: a) With javascript disabled, the form is still accessible. b) Bots see the CAPTCHA and leave. c) If a bot is so extremely clever to solve the CAPTCHA and your system, we can catch ‘em because they send back two solved challenges! d) It is gracefully downgrading; Annoying CAPTCHA tests now suppress only communication with annoying visitors

4. It would be friendly to the visitor to tell him/her that the submission time has expired and provide a way to reload without losing form content, wouldn’t it?

This helps ensure a client’s posts are synchronized with a new transaction on the server every time (consider submitting a payment) - hence the name.

Many Java web frameworks implement this sort of thing for you out of the box - skipping the JQuery step of inserting the hidden form field in dynamically and just automatically including the hidden field in the form for you. This method requires no Javascript, and you can suggest it as a way to deal with clients that don’t have Javascript. The Javascript applies just an added level of obfuscation to the whole process and isn’t really needed to achieve what you’re looking for.

Another similar pattern to take a look at in terms of secure form processing is PRG (http://en.wikipedia.org/wiki/Post/Redirect/Get).

Implementing the browser environment is a bit hard though even with the JS runtimes so you could get away with this for a while. Though a simple XULRunner or Firefox Extension app would have the environment to run anything in FF.

I don’t think I’m understandint this fully though. Are you just setting a cookie when the XHR is made, or are you sending back JS that needs to be interpreted. If its justa cookie, then this isn’t JS dependent, if its obfuscated JS, then yes the spammer would need a JS interpreter or some nifty regex. If you implement some browser specific environment features, then you could get even further as the spammer would need to implement those in their bot. Could get expensive enough you might have something for the masses…