progress on use of an api key instead of usename/password?

[Todd Eddy]

I know this was talked about a while ago, was wondering what progress
was made. I want to use all these services that can post updates to
twitter for you, but don't like the fact I have to give my username
and password to all these people. I guess it wouldn't be as bad if
the api used ssl or you could send the password in a hashed form.
Having to transmit the username and password in cleartext over the
internet just screams "hi, please hack me!". And what's really
unfortunate is I'm sure 90% of the people that use these other
services don't realize that the password has to be stored clear text
on whatever site they use so it can be sent plaintext to the service.
Once realizing this I of course made sure I used a password unique
only to twitter instead of my usual "normal web services" password I
use.

I understand one of the main concerns for twitter right now is data
integrity and stability, but security should be in there too. Even if
it was just a "quick fix" of allowing ssl connections and then
enforcing it 9 months from now or something. Then later on enhance
the authentication system to allow things like the hashed password to
be used instead of plain text and then using arbitrary user api keys
or per applicaiton api keys. SSL typically isn't that much overhead
but I can understand if the ssl negotiation could be a big performance
hit when you're dealing with 100's of connections a second or whatever
the load is.

[Alex Payne]

We take security seriously. That's why our own Blaine Cook was one of
the primary authors of the OAuth standard for token-based
authentication. Unfortunately, we're also a very small and
time-constrained team, so our OAuth implementation isn't quite done
yet. It should be complete later this month.

In the meantime, we offer SSL for any and all requests through the
API. If your application runs on untrusted networks, you can use SSL
today.

--
Alex Payne
http://twitter.com/al3x

[Damon Clinkscales]

On Tue, Mar 4, 2008 at 10:29 AM, Todd Eddy <vrill...@gmail.com> wrote:

> And what's really unfortunate is I'm sure 90% of the people that use these other
> services don't realize that the password has to be stored clear text
> on whatever site they use so it can be sent plaintext to the service.

Actually, it doesn't have to be stored in plaintext, and as Alex said,
it can be transmitted over SSL. I'm with you on the token-based
solution though, I am looking forward to OAuth support from Twitter.

-damon

[Todd Eddy]

On Mar 4, 1:10 pm, "Alex Payne" <a...@al3x.net> wrote:
> In the meantime, we offer SSL for any and all requests through the
> API. If your application runs on untrusted networks, you can use SSL
> today.

Ohh I had no idea, although I admittedly never checked either :) Now
I'll have to start bugging all the apps I use to see if their apps
support it :)

[Damon Clinkscales]

On Tue, Mar 4, 2008 at 12:10 PM, Alex Payne <al...@al3x.net> wrote:
>
> our OAuth implementation isn't quite done
> yet. It should be complete later this month.

Alex, et al,

I've heard that some are using the OAuth implementation, although it
is unsupported/unreleased as you point out.

Is this true? Are there any examples written up (anywhere) which
describe how to use it in its current form?

I signed up with the OAuth form on Twitter.com, but do any of the
API's support the new tokens?

Thanks!
-damon

[Alex Payne]

Please do not use OAuth at this time. Once I have something worth
beta-testing I'll let the list know. I'm not holding out on you,
promise!

--
Alex Payne
http://twitter.com/al3x