nanog mailing list archives
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
From: Jimmy Hess <mysidia () gmail com>
Date: Thu, 24 Jan 2013 22:30:32 -0600
On 1/23/13, Rich Kulawiec <rsk () gsp org> wrote:
On Mon, Jan 21, 2013 at 02:23:53AM -0600, Jimmy Hess wrote: Once again: captchas have zero security value. They either defend (a) resources worth attacking or (b) resources not worth attacking. If it's (a) then they can and will be defeated as soon as someone chooses to trouble themselves to do so. If it's (b) then they're not worth the effort to deploy. See, for example:
See, you don't show they're not worth the effort to deploy in case (a). The CAPTCHA _might_ be attacked, only if the attacker perceives the value of resources worth attacking as higher than what the attacker believes the sum of their cost of the effort that will be required to defeat all the barriers resisting attack. The return on defeating the CAPTCHA, without defeat on other measures, will be pretty much zero, if it is reinforcing other security measures. And of course, you can revise the CAPTCHA, if your monitoring finds that it has been defeated, and abuse starts to occur, so the attacker has to break it again. It takes much less time commitment to develop new variations on a CAPTCHA than it it does to defeat novel variations.
Now I'll grant that captchas aren't as miserably stupid as constructs like "user at example dot com" [1] but they really are worthless the
[1] Such constructs are based on the proposition that spammers capable of writing and deploying sophisticated malware, operating enormous botnets, maintaining massive address databases, etc., are somehow mysteriously incapable of writing
...
No, they are based on the proposition, that the obfuscation is unique enough to avoid detection, and spammers frequently search for something particularly obvious (e-mail addresses that don't require extra CPU cycles spent on trying many de-obfuscation techniques to parse). Any particular obfuscation would obviously lose value, if it became used frequently. I believe the specific one 'user at example dot com' is well-known due to its obviousness and use by certain Mail archive to HTML software, and therefore -- I would not recommend that particular method. For obfuscation methods to be most effective at blocking address harvesting, they should be novel, non-obvious. eg ' Email to username and atsign, this domain: example, dot, and then com. ' Of course... if any obfuscation method becomes very popular, or frequently used by a large number of documents (E.g. list archives of many/large public mailing lists), and the obfuscation technique will automatically become worthless, just because mailing list archives are such an attractive target for address harvesting, and a consistent obfuscation method for many addresses -- means the value of defeating that method becomes significant. -- -J
Current thread:
- Re: Suggestions for the future on your web site: (was cookies, and, (continued)
- Re: Suggestions for the future on your web site: (was cookies, and Joe Greco (Jan 25)
- Re: Suggestions for the future on your web site: (was cookies, and Michael Thomas (Jan 26)
- Re: Suggestions for the future on your web site: (was cookies, and Jimmy Hess (Jan 26)
- Re: Suggestions for the future on your web site: (was cookies, and Jean-Francois Mezei (Jan 30)
- Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...) George Herbert (Jan 24)
- Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...) Jean-Francois Mezei (Jan 24)
- Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...) Andrew Sullivan (Jan 24)
- Re: Suggestions for the future on your web site: (was cookies, and Joe Greco (Jan 24)
- Re: Suggestions for the future on your web site: (was cookies, and . (Jan 25)
- Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...) Scott Howard (Jan 24)
- Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...) Jimmy Hess (Jan 24)
- Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...) . (Jan 21)
- Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...) . (Jan 21)
- Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...) Jean-Francois Mezei (Jan 21)
- Re: Security reporting response handling [was: Suggestions for the future on your web site] Matt Palmer (Jan 22)
- Re: Security reporting response handling [was: Suggestions for the future on your web site] Suresh Ramasubramanian (Jan 22)
- Re: Security reporting response handling [was: Suggestions for the future on your web site] Alain Hebert (Jan 22)
- Re: Security reporting response handling [was: Suggestions for the future on your web site] Jimmy Hess (Jan 23)
- Re: Security reporting response handling [was: Suggestions for the future on your web site] . (Jan 23)