On Jul 1, 2009, at 10:17 AM, DWRoelands wrote:
Thanks for weighing in. Much appreciated. Here are my thoughts.
I see two separate issues here: User Authentication vs. Application
User Authentication: Ensuring that the Twitter user is who they say
Application Authentication: Ensuring that the Application is who it
says it is (i.e. the tweet is really coming from "TweetDeck" and not
some other application pretending to be TweetDeck).
I understand that Basic Auth, as is, is not a secure solution.
Transmitting unencrypted credentials in the clear is never a great
idea. What about combining Basic Auth with a form of public/private
key encryption? Using PGP as an example, Twitter could publish it's
public PGP key. Applications using Basic Auth would have to encrypt
the username and password with that key and submit the encrypted
username and password as the Basic Auth credentials. Twitter decrypts
them server side and processes authentication normally. Developers
wouldn't have to include any sensitive information in their source
code, and the credentials would always be transmitted in an encrypted
fashion. PGP is a fairly robust standard, with lots of free resources
available to the development community across many languages.
Rather than breaking with the HTTP specification for Basic
authentication we offer HTTP over SSL for encrypted access. That adds
the benefits you enumerate above plus:
* Requires very little coding from developers (most libraries
* Built on an open standard
* Prevents re-using an Authentication header (even one encrypted) to
essentially act like a user.
* Bonus: Encrypts the contents so nobody else is reading your DMs on
This is a thornier issue that I'm not sure how to solve without having
to bundle some sort of sensitive information in the source code of an
application. However, I think the issue becomes more manageable if
User Authentication is separated from Application Authentication.
This seems to be the crux of the issue from what I can tell. Isaiah
from youhead enumerated some of the difficulties with that, especially
for open source.
I have no doubt that many of the folks on this list have good ideas on
how to solve the second problem.
On Jul 1, 12:46 pm, Matt Sanford <m...@twitter.com> wrote:
Please, take your time and write a well thought out reply. One-
line snarky comments, while fun to write and sometimes to read, steal
time from everyone reading the list, including all of the Twitter API
engineers. They also make the list look less inviting to new comers.