On Sat, Jan 19, 2013 at 06:33:33PM -0600, Jimmy Hess wrote:

On 1/18/13, Matt Palmer <mpalmer@hezmatt.org> wrote:

...

Primarily abuse prevention. If I can get a few thousand people to do something resource-heavy (or otherwise abusive, such as send an e-mail somewhere) within a short period of time, I can conscript a whole army of unwitting accomplices into my dastardly plan. It isn't hard to drop

You can prevent this without cookies. Include a canary value in the form; either a nonce stored on the server, or a hash of a secret key, timestamp, form ID, URL, and the client's IP address.

Nonce on the server is a scalability hazard (as previously discussed). You can't put a timestamp in a one-way hash, because then you've got to hash all possible valid timestamps to make sure that the hash the user gave you isn't one you'll accept. You *can* put all those details into the form, then generate a HMAC (or symmetrically encrypt those details) to prevent tampering, but without server-side storage -- again, scalability hazard -- you can't prevent replay attacks (for as long as the timestamp is valid). The problem with this method, though, is that the only thing that stops the attacker from retrieving the entire chunk of data out of your form and tricking the client into submitting it is the client IP address. Now, you've got a decent idea here:

If the form is submitted without the correct POST value, if their IP address changed, or after too many seconds since the timestamp, then redisplay the form to the user, with a request for them to visually inspect and confirm the submission.

Which is decidedly more user-friendly than most people implement, but suffers from the problem that some subset of your userbase is going to be using a connection that doesn't have a stable IP address, and it won't take too many random "please re-confirm the form submission you made" requests before the user gives your site the finger and goes to find something better to do. I just realised that I may have been insufficiently clear in my original request. I'm not looking for *any* solution to the CSRF problem that doesn't involve cookies; I'm after a solution that has a better cost/benefit than cookies. Things that require me to worry (more) about scalability are out, as are things that annoy a larger percentage of my userbase than cookies (at least with cookies, I can say "you're not accepting cookies, please turn them on", whereas with randomly resubmitting forms, I can't say "please stop changing your IP address" because that might not even be the problem). - Matt

On 1/21/13, Matt Palmer <mpalmer@hezmatt.org> wrote:

Nonce on the server is a scalability hazard (as previously discussed). You

It's not really a scalability hazard. Not if its purpose is to protect a data driven operation, or the sending of an e-mail; in reality, that sort of abuse is likely need to be protected against via a captcha challenge as well, requiring scalability hazards such as performing image processing operations on the fly.... The logistical challenge with a nonce, is ensuring that the server generated and stored a long enough list of nonces for request load; you need to make sure that you never give out the same nonce twice, and you make sure you wipe out old sets of of nonces frequently, and then the only really hard part: when a nonce is used, you persist the fact that it is no longer valid. So you come to consider, the bottleneck: "Persisting the fact that nonce X was used" versus "Sending this e-mail message" or "Posting entries to the database to complete the operation this form is supposed to do" "The operation this form is supposed to do" will normally be the larger scalability hazard, usually involving more complicated database operations, than some nonce record maintenance.

can't put a timestamp in a one-way hash, because then you've got to hash all possible valid timestamps to make sure that the hash the user gave you isn't one you'll accept.

No, but you can use codevalue = "<at_timestamp>:SHA1(<secret>:<at_timestamp>:<submission_id>:<formaction>:<client ip>)" If current_time - at_timestamp > X : require_resubmission

The problem with this method, though, is that the only thing that stops the attacker from retrieving the entire chunk of data out of your form and

Yeah... about that... if they can do that, they can surely steal a cookie, which persists, beyond the time the form is displayed in a browser. The adversary may be able to get the actual site to set the cookie in the unwitting user's browser by using an invisible IFRAME or other techniques, including ones to set a cookie for a different domain, circumventing the use of cookie as abuse prevention methods. The cookie is also susceptible to replay attack if something such as the client IP address is not a factor.

Which is decidedly more user-friendly than most people implement, but suffers from the problem that some subset of your userbase is going to be using a connection that doesn't have a stable IP address, and it won't take

That would be quite unusual, and would break many applications for that user... Although there is nothing mutually exclusive about cookies and other methods. It is possible to set a cookie to be used as an additional factor, after detecting that the user's IP address might be unstable.

I just realised that I may have been insufficiently clear in my original request. I'm not looking for *any* solution to the CSRF problem that doesn't involve cookies; I'm after a solution that has a better cost/benefit than cookies.

How about the issue that: cookies don't necessarily address CSRF? Cookies are OK for storing user preferences, but not to authenticate that the user actually authorized that their browser make that HTTP request. The user can have been browsing the form legitimately. The user unwittingly opens a malicious web page in another window, after having accessed the form recently. The required cookie is already set: the user might even have a logged in session, with an authentication cookie set in the browser. The malicious page can abuse an already-logged-in session by sending a POST request to it. Or have persuaded the user to login, while the malicious page is still in memory, and able to make quiet discrete POST requests. Cross-site POST operations are allowed operations; and the cookie was already set. On the other hand... a value in the form presented, should be protected against the malicious site, by the same origin policy. So perhaps if you need to use a value in the form anyways, the cookie is redundant -- -JH

On 23 January 2013 09:45, Rich Kulawiec <rsk@gsp.org> wrote:

On Mon, Jan 21, 2013 at 02:23:53AM -0600, Jimmy Hess wrote:

...

that sort of abuse is likely need to be protected against via a captcha challenge as well,

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:

CAPTCHAS are a "defense in depth" that reduce the number of spam incidents to a number manageable by humans. Not all bot writers have the same quality. A lot of them are crappy. Because of this, maybe are worth the effort. -- -- ℱin del ℳensaje.

On Wed, Jan 23, 2013 at 01:20:07PM +0100, . wrote:

...

CAPTCHAS are a "defense in depth" that reduce the number of spam incidents to a number manageable by humans.

No, they do not. If you had actually bothered to read the links that I provided, or simply to pay attention over the last several years, you would know that captchas are not any kind of defense at all.

They're like holding up tissue paper in front of a tank: worthless.

(Yes, yes, I'm well aware that many people will claim that *their* captchas work. They're wrong, of course: their captchas are just as worthless as everyone else's. They simply haven't been competently attacked yet. And relying on either the ineptness or the laziness of attackers is a very poor security strategy.)

This is a fairly common mistake. Security isn't about prevention, it's about deterrence. If you have a locked screen door, someone can still trivially break the screen and unlock it. If you have a glass door, a brick. If you have a hollow core wood door, a shoulder. If you have a solid core wood door, a sledge. If you have a steel door, a prybar. If you have a safe-style door, explosives. If you're Fort Knox, a larger military force. :-) Basically there is no door that cannot be overcome with sufficient force; the point of a door is not to absolutely prevent a bad guy from entering under all circumstances, but rather to deter the average attacker to go bother the neighbors instead. You can do many things to augment your physical security, unpickable locks, reinforced doors, motion sensor lights, alarm systems, etc. but all of these are merely enhancers that are designed to make a criminal look for an easier target. A determined and properly resourced attacker who is determined to attack a given resource is going to be successful eventually. And that's where the so-called argument against CAPTCHAs falls apart. A CAPTCHA doesn't need to be successful against every possible threat, it merely needs to be effective against some types of threats. For example, web pages that protect resources with a CAPTCHA are great at making it much more difficult for someone with l33t wget skills from scraping a website. It isn't a high bar anymore, it isn't a strong defense anymore. All quite true, so I'll even agree with your inevitable answer that many websites are using CAPTCHA as protection against attacks that it is no longer capable of guarding against. Agreed! However, as part of a "defense in depth" strategy, it can still make sense. It's much more of a locked screen door at this point, but if you've got threats that can be easily deterred, then it's still viable. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

On Thu, Jan 24, 2013 at 11:00:50AM -0500, Andrew Sullivan wrote:

On Thu, Jan 24, 2013 at 09:50:15AM -0600, Joe Greco wrote:

...

A CAPTCHA doesn't need to be successful against every possible threat, it merely needs to be effective against some types of threats. For example, web pages that protect resources with a CAPTCHA are great at making it much more difficult for someone with l33t wget skills from scraping a website.

Well, yes and no. Lately, AFAICT, most CAPTCHAs have been so successfully attacked by wgetters that they're quite easy for machines to break, but difficult for humans to use. For example, I can testify that I now fail about 25% of the reCAPTCHA challenges I perform, because the images are so distorted I just can't make them out (it's much worse on my mobile, given the combination if its small screen and my middle-aged eyes).

So it's now more like airport security: a big hassle for the legitimate users but not really much of a barrier for a real attacker. A poor trade-off.

"A Modest Proposal": Maybe we need to turn it around and fail on successful recognition of the CAPTCHA, then? -- Mike Andrews, W5EGO mikea@mikea.ath.cx Tired old sysadmin

--- On Thu, 1/24/13, Andrew Sullivan <asullivan@dyn.com> wrote:

Lately, AFAICT, most CAPTCHAs have been so successfully attacked by wgetters that they're quite easy for machines to break, but difficult for humans to use.  For example, I can testify that I now fail about 25% of the reCAPTCHA challenges I perform, because the images are so distorted I just can't make them out (it's much worse on my mobile, given the combination if its small screen and my middle-aged eyes).

So it's now more like airport security: a big hassle for the legitimate users but not really much of a barrier for a real attacker.  A poor trade-off.

+1000 I routinely fail CAPTCHAs, and am certainly less accurate than a decent machine at the OCR required. Those of us whose eyes don't correct to 20/20 would greatly appreciate some other form of "slow down the spammers" than this. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com

But defenses have to be *meaningful* defenses. Captchas are a pretend defense. They're wishful thinking. They're faith-based security.

They're a hook-and-eye latch. Now, if you want to go installing a bank vault door to keep your dog in the backyard, by all means, be my guest. Me, I'm frugal, so I'll make the more reasonable investment of a hook-and-eye latch to keep the gate closed.

Moreover, like all defenses, they don't come for free. There are costs associated with them (both for those deploying them and for users of whatever service they're allegedly protecting). And beyond the obvious costs, as we've learned through bitter experience, "complexity" is not only a hidden cost but also sometimes the one that bites us in the ass by way of vulnerabilities.

So given that we all know that (a) the express purpose of captchas is to determine whether or not a human is on the other end of the wire and (b) THEY DON'T ACTUALLY DO THAT, why incur those costs?

Not a given; your (a) is faulty. I already gave a trivial example of a situation where the deployment was intended to detect and deter a specific sort of automated exploit (more of a "prove you're a stupid spam bot and therefore ignoreable" than a "prove you're human").

Doubly so given that there are a fair number of visually-impaired people, blind people, and, oh, by the way, people using devices with rather small displays. Especially the last, recently. Why inflict this nonsense on them? Why try to offload the (admittedly) hard work of securing a resource onto the users, especially the users who are least-equipped to deal with it?

That depends on the CAPTCHA, I would imagine. Pretty sure that none of the cases you list would have a problem with the CAPTCHA I described.

And please: let's not even go to audio captchas. That's the sort of bag-on-the-side-of-a-bag hack that we all did our sophomore year but were too embarrassed to admit by the time we were seniors.

We have much better defenses at our disposal. (Examples: BCP 38, the Spamhaus DROP list, ipdeny.com, passive OS fingerprinting combined with rate throttling, checksum comparison.)

Each suitable for a particular range of purposes. And, as it turns out, each generally varies in effectiveness as they age... it just turns out that CAPTCHA has aged relatively poorly. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

On 1/26/13, Michael Thomas <mike@mtcc.com> wrote:

Rich Kulawiec wrote:

...

On Thu, Jan 24, 2013 at 09:50:15AM -0600, Joe Greco wrote:

...

However, as part of a "defense in depth" strategy, it can still make sense.

...

But defenses have to be *meaningful* defenses. Captchas are a pretend defense. They're wishful thinking. They're faith-based security.

Hm.. see, what we have here is a theory, that because some major sites' CAPTCHA implementations have been broken (in some cases, mainly by attacking the audio version), that all CAPTCHA implementations are necessarily vulnerable. And then, because of that.... all CAPTCHAs are worthless, just because some significant CAPTCHA implementations have been defeated with good success. [And then those Captchas got quickly revised, so they are no longer defeated] So what we have here, are two leaps of logic.... (1) CAPTCHAs used by a few popular websites were defeated in some cases, and some folks have published materials about techniques for defeating CAPTCHAs, therefore, we are to believe that all CAPTCHA implementations are inherently necessarily easily enough to break. The concept has a few holes in it, because it is possible the websites whose CAPTCHAs were defeated, had implementation-specific issues, and it is possible that CAPTCHAs exist that could be fundamentally harder to defeat efficiently. It may be a flawwed supposition that all CAPTCHA implementations are necessarily so similar, that the same attacks work. This may be coming, but It is not accepted fact, or a compelling idea, that text-based CAPTCHAs are yet trivial to defeat. It's entirely possible, that some types of CAPTCHA will become trivial to defeat, and others will present major challenges for an abuser. And, the second leap of logic was: (2) If a CAPTCHA is as easily broken as (1), then a considerable number of the attackers who target a site for abuse will be able to break it and do so (therefore, resulting in a defeat). [identical-misconception] The concept is equivalent to the idea, that all RSA based encryption worthless, because just some 512 bit RSA private key was defeated through factoring, by an attacker with sufficient cash to spend. Therefore, any site relying on a RSA-based SSL implementation is insecure, since RSA encryption is faith-based security [/identical-misconception]

Oh, I dunno. I run a website that has a fairly low volume forums that occasionally gets a drive by spamming. I'm pretty sure that if I implemented even a naive captcha it would go back to zero. [snip]

Yes. I would agree, that the CAPTCHA is likely to be successful in that case. If you would implement, and measure the amount of spam rates from automated bots both before and after implementing, then you would have a datapoint, in regards to CAPTCHA effectiveness :)

Mike -- -JH

On Thu, Jan 24, 2013 at 5:48 AM, Rich Kulawiec <rsk@gsp.org> wrote:

On Wed, Jan 23, 2013 at 01:20:07PM +0100, . wrote:

...

CAPTCHAS are a "defense in depth" that reduce the number of spam incidents to a number manageable by humans.

No, they do not. If you had actually bothered to read the links that I provided, or simply to pay attention over the last several years, you would know that captchas are not any kind of defense at all.

They're like holding up tissue paper in front of a tank: worthless.

(Yes, yes, I'm well aware that many people will claim that *their* captchas work. They're wrong, of course: their captchas are just as worthless as everyone else's. They simply haven't been competently attacked yet. And relying on either the ineptness or the laziness of attackers is a very poor security strategy.)

---rsk

It's true that relying on the laziness of attackers is statistically useful, but as soon as one becomes an interesting enough target that the professionals aim, then professional grade tools (which walz through captchas more effectively than normal users can, by far) make them useless. I disagree that they're entirely ineffective. The famous Wiley cartoon (found also in the frontspiece of the original Firewalls book...) "You have to be this tall to storm the castle" does apply. But knowing the relative height and availability of storm-the-captcha tools is important. They are out there, pros use them all the time, they are entirely effective. -- -george william herbert george.herbert@gmail.com

On Thu, Jan 24, 2013 at 04:43:47PM -0500, Jean-Francois Mezei wrote:

It is better to have a tent with holes in the screen door than no screen door. If the damaged screen door still prevents 90% of mosquitoes from getting in, it does let you chase down and kill those that do get in.

I get this argument, but it seems to miss the point I was trying to make earlier. This isn't like a screen door with holes in it, but more like a screen door with holes in it and a trick hinge that, from time to time, bounces back and whacks the humans entering right in the nose. To resort to plain language instead of overworked metaphor, the problem with CAPTCHAs is that they're increasingly easier for computers to solve than they are for humans. This is perverse, because the whole reason they were introduced was that they were _hard_ for computers but _easy_ for humans. The latter part was a key design goal, and we are increasingly ditching it in favour of "just using a CAPTCHA" because they're what we think works. (Of course, this is really just a special case of the usual problems in HCI when security becomes an issue. We have this kind of problem with passwords too.) A -- Andrew Sullivan Dyn, Inc. asullivan@dyn.com

On 24 January 2013 23:38, Joe Greco <jgreco@ns.sol.net> wrote: ..

So, then, "replace it with what, exactly?" What if we all wake up one morning to find that our computers have gained an IQ of 6000? Will the computers be making jokes about "as dumb as a human" and debating ways to identify if they're talking with another computer or just a human? :-)

I don't like Facebook, or the lost of all our privacy. But if Facebook work hard to ban all robots, then you have a simple way to solve this problem (or outsource it to facebook) by having a "login with facebook to post" button. This don't work for all uses. If you have a photo Gallery, and your bussines plan is to show in the gallery the lores image, and sell the highres somebody will wwgget all of it, by teaching the bot to login with facebook. Random people will use the lores version, and ignore your highres version photos. You you do here, is to watermark all photos in the center with your logo, but this make the photos look uglier. You get paid by a museum to photography and put online a Mayan Codex and other cool stuff , but the museum want you to put the photos online but with DRM... so people still have to visit the museum to watch the book. Then you uses a java applet as viewer, or other ugly way that ofuscate how the computer download and view the images. If you have a forum, you can disable public registration, and allow registration with invites, so to register in the forum you must be invited by a person already in the forum. We don't have to replace CAPTCHA by a single tecnique, It could be replaced by different solutions for different sites. Good News: World levels of spam in email are lowering, more and more and more. Thats a fight the good guys are winning!. -- -- ℱin del ℳensaje.

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

On 21 January 2013 09:26, . <oscar.vives@gmail.com> wrote:

On 21 January 2013 07:19, Matt Palmer <mpalmer@hezmatt.org> wrote: ...

...

...

If the form is submitted without the correct POST value, if their IP address changed, or after too many seconds since the timestamp, then redisplay the form to the user, with a request for them to visually inspect and confirm the submission.

Which is decidedly more user-friendly than most people implement, but suffers from the problem that some subset of your userbase is going to be using a connection that doesn't have a stable IP address, and it won't take too many random "please re-confirm the form submission you made" requests before the user gives your site the finger and goes to find something better to do.

You want to stop the CSRF problem, but you want to support a user making the login in a IP, and submiting a "delete account" button *the next second* from a different IP. then you want this solution to be better cost effective than cookies.

Maybe ask the user his password.

<form method="post"> <input type="hidden" name="id_user" value="33"> <input type="hidden" name="action" value="delete_user"> <input type="submit" value="Delete user"> <p>For this action you must provide the password. </p> <input type="password" name="password" value=""> </from>

Even if this request come from a IP in china, you can allow it.

So this solution can be read has: - Do nothing to avoid CSRF. - Except for destructive actions, where you ask for the password. -- -- ℱin del ℳensaje.