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.

Reply via email to