4 ms·
> Spambots can’t fill in the field because they can’t interact with objects in client-side JavaScript; only users can. Not true anymore. What you could do is a
by chime 15y ago
> Spambots can’t fill in the field because they can’t interact with objects in client-side JavaScript; only users can.
Not true anymore. What you could do is add a hidden field with value=encrypt(timestamp+salt) and only accept the form if the decrypted timestamp is at most x hours old. If you want to further restrict it, you could also add the IP to the encrypted value. This will fail if a user gets a new IP between loading the form and submitting it (laptop user moving around, VPN gateway changes etc).
- jcampbell1 15y agoI don't understand your suggestions. If the spammer can run javascript (e.g. Selenium), how would your timestamps / ip stuff help? Seems like it would just add complexity without any benefit.
- moxiemk1 15y agoThe behavior being stopped is repeated POSTs to create new accounts - a spammer would instead have to GET the form every couple of hours (or if they don't realize the trick, possibly each time), something they'd hopefully do from the same IP = easier to see and ban. Granted, if they have a huge network of distributed bots, it probably won't help. But, if they do try to register a bunch of accounts using the same timestamp hash, it'd be easier to nuke all of them at once when you discover what's going on.
- eoslick 15y agoHow do you handle users coming through corporate proxies that hide their internal addresses?
- mekoka 15y agoAnother technique against spambots that I've used along the line of "hidden fields" is to have a textfield that should NOT contain anything at submission time. You hide the textfield (margin: -10000px) and give it a name unique enough, that browsers with autofills won't have a record of a value ever entered there. Spambots usually fill every fields, so if you see a value in the field when you process the registration, you know that it's highly likely that a non-human is registering. You now have the option of rejecting it, or accept it but put the account in a "monitor" queue. One pitfall is that this scheme expects everyone registering to uses css. You can however give various hints to non-css users, to keep the textbox empty.
- djb_hackernews 15y agoThat's wasted effort. The bots are usually built by humans, and the humans can detect that and build the bot to ignore text fields with margin < -1000 or the unique name or something.
- ydant 15y agoI think it depends on if you are trying to avoid automated attacks or targeted attacks. There seem to be a lot of bots scanning for vulnerable sites - this would potentially work for those. If you get targeted specifically, then, yeah, the human in charge can figure it out in short order.
- aik 15y agoI agree. I think this method is a great idea and is much more foolproof: "You could also use Honeypot Captcha approach: you can create a honeypot form field that should be left blank and then use CSS to hide it from human users, but not bots. When the form is submitted, you check to make sure the value of that form field is blank." http://haacked.com/archive/2007/09/11/honeypot-captcha.aspx http://haacked.com/archive/2007/09/11/honeypot-captcha.aspx
- djb_hackernews 15y agoFails the same test. I build what can be considered bots for a living, though they have nothing to do with spamming or otherwise shady reasons. Part of the process in building the bot is to send exactly what a browser would send, and we do this by actually making the requests in a browser and viewing the raw request. If my browser doesn't send a honeypot captcha, neither does my bot.
- aik 15y agoSay you have a field hidden with a div on a low profile, minimum traffic site (100 visitors a week). It's incredibly unlikely and pretty dumb for a bot to be made specifically for that site -- in this case, how could a bot determine whether that field should contain a value or not?