Comments on: Flickr API security weakness, and thoughts about web APIs in general http://www.yes-no-cancel.co.uk/2009/01/26/flickr-api-security-weakness-and-thoughts-about-web-apis-in-general/ Entrepreneurship, web technology and the user experience Tue, 23 Feb 2010 19:18:22 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Martin Kleppmann http://www.yes-no-cancel.co.uk/2009/01/26/flickr-api-security-weakness-and-thoughts-about-web-apis-in-general/comment-page-1/#comment-1728 Martin Kleppmann Tue, 27 Jan 2009 11:38:26 +0000 http://www.yes-no-cancel.co.uk/?p=217#comment-1728 Blaine, thanks for your reply. I'm sure that OAuth is much much better than the ad-hoc protocols invented but not properly thought through by many sites. And Flickr gets a lot of things right which others haven't even thought about, so I'm praising as much as I'm criticising. I agree about security/phishing having a strong social component, and of course there is also the trade-off between security and convenience. The most secure would be not to use the web at all. That would be a bit of a shame though... ;-) Blaine, thanks for your reply. I’m sure that OAuth is much much better than the ad-hoc protocols invented but not properly thought through by many sites. And Flickr gets a lot of things right which others haven’t even thought about, so I’m praising as much as I’m criticising.

I agree about security/phishing having a strong social component, and of course there is also the trade-off between security and convenience. The most secure would be not to use the web at all. That would be a bit of a shame though… ;-)

]]> By: Blaine Cook http://www.yes-no-cancel.co.uk/2009/01/26/flickr-api-security-weakness-and-thoughts-about-web-apis-in-general/comment-page-1/#comment-1724 Blaine Cook Tue, 27 Jan 2009 02:14:13 +0000 http://www.yes-no-cancel.co.uk/?p=217#comment-1724 These are excellent points. OAuth has been built to address some of your concerns; the user token has a secret associated, so sniffing traffic isn't possible with OAuth. As far as phishing with consumer keys from distributed software, it's definitely a threat. One possible approach would be to flag with some explicit language applications that are distributed (i.e., whose consumer key / secrets are "available"). Something along the lines of "Only accept this request if you are using Flickr Uploadr right now." For the really paranoid, you could combine the approach you describe here, and just have the user enter the first or last few digits of the token to verify that they're taking some action. Of course, when it comes down to it, phishing is a social problem, and no technical solution will ever solve it completely. Education is really the only viable approach (incl. phishing warnings, blacklists, etc) These are excellent points. OAuth has been built to address some of your concerns; the user token has a secret associated, so sniffing traffic isn’t possible with OAuth.

As far as phishing with consumer keys from distributed software, it’s definitely a threat. One possible approach would be to flag with some explicit language applications that are distributed (i.e., whose consumer key / secrets are “available”). Something along the lines of “Only accept this request if you are using Flickr Uploadr right now.”

For the really paranoid, you could combine the approach you describe here, and just have the user enter the first or last few digits of the token to verify that they’re taking some action.

Of course, when it comes down to it, phishing is a social problem, and no technical solution will ever solve it completely. Education is really the only viable approach (incl. phishing warnings, blacklists, etc)

]]>