I have to admit that you've got a very good point there. However, don't forget that any twitter account can create new API keys, without any kind of review process ;-)
The problem is very simple: Twitter needs something to identify the application, and this identification must be sent by the application itself. However, if the application can send it, then so can a person who manages to obtain the keys. And don't forget: no encryption is unbreakable. If you wanted the keys for an application, you could simply write a wrapper for libcrypto and fetch the keys for the application (assuming that it uses libcrypto for the SHA1-HMAC part). Bottom line: there's not really a solution to this issue, and you can't blame Twitter for that. Tom On Aug 8, 2:24 am, marketingmaniac <execut...@gmail.com> wrote: > twitter did this for 1 reason and only 1 reason,, sucks i know but > they did this because of all the desktop and net applications > that are mass sending messages,, parsing, you name it,, now they have > controll to kill the key,, > > i think its a horrable solution because now all the developers will do > is steal our keys and impliment it in their solution until > the key gets cut off, then they will just move on to the next key they > took. > > hmm,, twitter just doesnt have the staff that knows how these > developers think. > > Mike > > On Jul 15, 9:22 pm, "uberChicGeekChick(*KaityGB);" > > > > > > > > <uberch...@uberchicgeekchick.com> wrote: > > So basically Twitter's "solution" to keep consumer keys out of oss > > apps code base is: > > - to require a hard coded url, which will be easily found in any > > apps > > source( or by simply scanning one's network traffic ). > > - this uri than responds by displaying the consumer key, consumer > > secret, and even more information in plan text(which can also be > > easily sniffed from network traffic). > > - than these "credentials" are displayed in plain text which the > > user > > has to copy & paste back into my app > > > i have further issues but i'll start here. with the apps oauth > > credentials all being displayed in plain text after a user grants an > > oss application access to their account. so how does this remotely > > rationally solve anything? so now instead of a cracker needing to dig > > through my code to find my consumer secret they can simply run my, or > > any open source app, and grant this app access to my, i.e. the > > cracker's account, and now the cracker has my app's consumer key, > > consumer secret, & even more. and once they have this they need not > > even paste it into my app, or have looked through, even one line, of > > my open source code. > > > so how does this do anything but make my apps oauth "credentials" > > even easier for a cracker to get a hold of? now they can grep/search > > my code base for the uri and use a simple curl/wget script to get my > > apps "key & secret". > > > What's being solved here? an oauth access problem, twitter's lack > > of > > awareness, or complete disregard for open source apps using your > > service? > > > And now even supposing that my app gets this uri "pasted" back into > > it: my apps going to have to store these credentials. Now what? > > Whether i store this information in GConf, a ini/conf file, or even an > > encrypted storage system, e.g.: gnome-keyring/a ggp locked data file. > > no matter what i do there are three glaring wholes in the "solution", > > 1st) even at this point, my process of storing & retrieving twitter's > > precious oauth credentials *has* to be viewable in my source code, > > 2nd) once my app is running & sending request to & form twitter these > > credentials are now sitting in ram & again easily accessible to any > > cracker who'll spend 5minutes looking for it(any decent debugger, or > > countless other methods, will grant them access to this information). > > 3rd) its all still easily accessible by sniffing network traffic. > > > now if an ssl connection where to be *required* this would solve the > > networking sniffing issue - but none of the others. There are other > > issues which are more fundamental short comings in oauth itself, which > > i've already mentioned in my original xauth request support ticket & > > else where online. > > > by any logical evaluation: implement & require oauth is a mistake. > > if only Twitter could stand up and be technically competent enough to > > just admit it. > > > thankfully statusnet/identica & other open source micro-blogging > > platforms will learn from twitter's mistake. the only truly > > depressing part of this situation is that iamno going to be loosing > > my primary "social connection". especially as a disabled open source > > artist: this is incredibly sad & i can honest say that i will miss > > more of my twitter friends than i can even count... all because i > > create & use open source applications. > > > i wish i weren't being force to say good bye to so many beautiful > > friends who've become corner-stones of my personal support network.... > > But that's what i get for having made so many friends who rely on a > > closed sourced 3rd party. > > > At least i can say that, for a time, twitter truly did improve my > > quality of life. ~alas~ now my only choice left is to say goodbye. > > thankfully many of my friends have joined statusnet. and of course i > > can always keep holding out hope that twitter will reverse this > > mistake. a hope i'll hold on to until the day when my own open source > > app can no longer access twitter. hopefully hopemayprove to be > > powerful enough. > > > sincerely & hopefully, > > kaity g.b. - get2gnow's artist, author, code, & creator. > > http://uberChicGeekChick.com/?projects=get2gnow.