Implementing OAuth can get tricky when retrofitting, especially since a lot of sites such as Twitter may have unique/custom user authentication models, but it's definitely a step forward.
For everyone working on a web app, please consider the following Top Ten common threats [1] along with the excellent materials at OWASP [2]. It's good to think about security early in the requirements gathering phase (especially when outsourcing development) and Twitter's woes goes to show that its important to invest in safeguards. I can understand that its expensive to implement security when you're boot-strapping, but when you get to a scale like Twitter - there's really no excuse!!! [1]: http://www.owasp.org/index.php/Top_10_2007 [2]: http://www.owasp.org/ On 09/01/2009, at 2:19 PM, Sherif wrote: > > Forget about oAuth - none of this problem gets fixed until we get some > decently coded applications! > More to my point: > http://news.zdnet.co.uk/security/0,1000000189,39588628,00.htm > > Twitter hackers - a brute force attack. Twitter has no limit on login > attempts, no challenge-response and no Captcha. > > They are now working on changing all that.. > > On Jan 8, 10:46 pm, Sherif <sherifgmans...@gmail.com> wrote: >> @silky - totally agree, Twitter need to adopt a password anti- >> pattern:http://adactio.com/journal/1357/ >> >> FriendFeed does it really well - they have a 'remote key' which >> third- >> party applications use - and not your actual username and passwords. >> Its been well thought out... >> >> I'm really amazed at how bad twitter is written (the many outages we >> had months ago (due to it being written more like a blog-architecture >> than a message-queue type of solution), and even more recently >> recently the phishing attacks) >> >> Just goes to prove to get a successful startup its a lot to do with >> timing and getting a big user-base .. they have done that very well. >> Hats off to them, you can deliver an average service - thats so >> popular - it takes something big to move all users off twitter... >> will >> this be it? I don't think it will... >> >> On Jan 8, 9:13 pm, Rex Chung <rex.ch...@gmail.com> wrote: >> >>> Mashable had several post about >>> this.http://mashable.com/2009/01/03/warning-twitter-phishing-attack-underway/ >> >>> "You can follow updates on the attack by subscribing to the Twitter >>> topic #phishingalert"http://search.twitter.com/search?q=%23phishingalert >>> Rex >>> -- >>> Sydney: +61 421 591 943 >>> HK: +852 6901 2682 >> >>> Ankoder - Video Encoding On Demandhttp://www.ankoder.com >> >>> On Thu, Jan 8, 2009 at 6:02 PM, John Masson <jmas...@gmail.com> >>> wrote: >> >>>> An excellent point that some of us at work were discussing a few >>>> weeks >>>> ago, there are SO many dodgy looking sites asking for twitter >>>> credentials to do who knows what with it's scary!! It's like >>>> phishing >>>> attacks without even pretending to look like something else :) >> >>>> Will definitely aim to talk about this in our next Instantiate >>>> Podcast. >> >>>> JM >> >>>> On Jan 4, 5:06 pm, Elias Bizannes <elias.bizan...@gmail.com> wrote: >>>>> Hi everyone, >> >>>>> I personally believe Twitter is being irresponsible by creating an >>>>> ecosystem off their API without creating appropriate safeguards to >>>>> protect users like us. I am looking for some Aussie bloggers to >>>>> help >>>>> me make some noise. The silicon beach community literally turned >>>>> the >>>>> fight against the clean feed to a whole new level, so I'm >>>>> looking for >>>>> us do it again by creating a better Internet through example. >> >>>>> Quick background: >>>>> For you to give access to things like third party apps (like >>>>> Twhirl), >>>>> you need to give up your login and password. As has been >>>>> reported in >>>>> the tech news this last week, there have been security breaches of >>>>> people taking your Twitter password and selling it and the like. A >>>>> simple change to their API can avoid this bad password anti- >>>>> pattern. >> >>>>> With delegated authunentication or through the use of an open >>>>> standard >>>>> called "oAuth" you can actually allow websites to access your data >>>>> without you needing to give up your password (by simply giving >>>>> them >>>>> permission through the Twitter interface). What happens is that >>>>> instead of you punching in your password, and giving some random >>>>> your >>>>> personal details which they can then take advantage of, you can >>>>> instead have them request Twitter for authorisation, and you can >>>>> simply click a button saying "approved". >> >>>>> I will be posting something on the DataPortability Project's blog >>>>> about the issue and hope to give it some attention. The more >>>>> people we >>>>> have posting a synchronised blog post, the better chances we can >>>>> turn >>>>> this into news and get them to pull out their finger out. I know >>>>> for a >>>>> fact the only reason they are not doing this is because they don't >>>>> give it a high enough priority - but of course they don't, as >>>>> it's not >>>>> them hurting but us. With a bit of awareness, we can make people >>>>> realise there is a simple way to fix a very serious issue, which >>>>> is >>>>> comprimising your online identity. >> >>>>> I've already had to change my passwords a few times due to third >>>>> party >>>>> apps, and I am sick of doing it, and it annoys me when I know I >>>>> don't >>>>> need to do it! >> >>>>> Please contact me if you are willing to participate. For those >>>>> looking >>>>> to get a bit more exposure of their blogs, this is a good way to >>>>> do >>>>> it :) >> >>>>> Thanks! >>>>> Elias > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Silicon Beach Australia" group. To post to this group, send email to silicon-beach-australia@googlegroups.com To unsubscribe from this group, send email to silicon-beach-australia+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/silicon-beach-australia?hl=en -~----------~----~----~----~------~----~------~--~---