|Pondering feasibility of form mail security idea|
form mail security idea
I'm about 1/2 a step above knowing nothing.
So this idea may be totally stupid, I apologize if so.
I am interested in implimenting a PHP based for mail.
Thus, I've been reading various post on here.
Most are well dated but seem to have MOSTLY good advice and examples.
In reading them, they gave me a idea. One that I haven't seen mentioned.
That in turn made me wonder if it's even feasible.
So I decided to ask, and maybe even spark interest that leads to increased spam/exploits security...
How about implimenting a dual/tri purpose timer?
set it with a minimum time, crashes if bots submit it to early
maximum time, does a preliminary time out if
TAKING (not taken) to long, so perhaps does a contact form refresh, or throws a security question, MUST BE ANSWERED, NOT CLOSED, then if answered correctly, restarts a additional time alottment to finish the msg.
IF ANSWERED WRONG, commits a die command to the mail script
PERHAPS EVEN, pull redirect to badbot trap
I imagine it is all possible.
Very feasible if you use sessions to keep track of page request times.
I would suggest that a bot would typically take significantly less time than a human to use a mail form.
|Very feasible if you use sessions to keep track of page request times. |
A bot might not even set a session (cookie, etc.) - so there you have another trap.
I would be wary about trapping "too long" requests, as you might annoy a slow user!
I have implemented a similar technique on several forms before... if the form is submitted too quickly (ie. within a few seconds). However, it has never caught anything! Maybe I got the timing wrong?! Or, more probable I suspect, my other spam traps have caught it first.
It's an arms race with the spammers, they'll figure it out soon enough. You're not going to (help to) exhaust their resources so while it might put you a bit in front it's for sure nothing they cannot beat if they care to.
Moreover not all spammers are automated, quite a few run on sweatshops in 3rd world countries - most likely exploiting kids used as slaves.
It's better to make your script smarter and silent about it's refusal: don't give feedback on success/failure to the spammer. That way they'll never know they were too fast for you and you just discarded their message completely. Either based on content, keywords you don;t want to see, excessive amounts of URLs, email address they gave you, fields that are hidden with CSS that they did fill in anyway, browser strings that are off, source IP address of a (cheap) hosting provider, ... But if you give hem feedback that it was refused, they'll figure out why and figure out a way around your defences.