It feels like your frustration is less with delegated auth (which is more secure than basic auth, period), and more with web people who don’t understand security. These people will always exist. Overworked teams who allow logins to the admin site via the normal site login with no VPN or otherwise will also always exist.

In South America, they have phishing attacks too; the difference is that the phishing is done with a gun, your car, and your bank card. So we’re never going to solve all of these problems. It just won’t happen. But we can strive to do better, and we should. Arguing about whether Better is Enough seems counter productive.

That said, it’s important that people understand where the possible attack vectors are with OAuth, and how to guard against them (in this case, don’t trust consumer keys in publicly distributed software as much as you do privately held consumer keys with owners who you can sue). The more writing on this, the better, as long as it’s done in a way that doesn’t throw the baby out with the bath water.

@Richard, as long as you’re sending bits to somebody’s computer it’s fair to assume that they’ll be able to identify whatever information is encoded in there – especially if it’s encoded in an x86 executable Secondly a distributed application binary can never be trusted – at least not without significant OS and hardware support that’s definitely lacking on all the platforms I care to run and are probably lacking in practice on the ones that claim to implemented it. The only solution is to trust users, not software – take a look at my next post.

The API Key and, for that matter, the user’s Token (in Flickr API terms) are not meant to be secret. They are on the wire in plain text along with the signature, which is salted using the Secret, the one part that doesn’t cross the wire. OAuth does one better by having per-token secrets that must (whether it says “should” or “must” it means “must”) be sent over HTTPS and are thereafter used just like the API Key’s Secret. Still not very good, as it has to be stored somewhere and money says it’ll be stored less “securely” than even the Secret in Flickr Uploadr.

The Uploadr’s Secret was coded in the way it was because this way it doesn’t show up when you run `strings` against key.dylib. You do get the API Key from `strings`, for reasons mentioned above.

Just forcing everything to use SSL only solves the message-integrity problem but leaves the is-this-really-Flickr-Uploadr problem open. Diffie-Hellman doesn’t help you there. (Each and ever user of Flickr Uploadr would need a cert from a trusted CA for SSL to actually verify identity and even then, if an attacker has access to the filesystem, you’re toast.)

identifying the application is mostly used for rate limiting