username/password best practices

[Andrew Badera]

Hi all-

As we await OAuth, many of us are faced with storing a user's username + password.

I'm curious if there's a set of best practices anyone's using these days, or maybe we could brainstorm a few on-list?

I have an app where:

1. User enters twitter name, password, message - no additional user management/authentication.
2. At some point, message is sent. We can now discard the cleartext password, but:
3. User still needs to look up historical entries, so maybe we hash the password after send.

But, what if the username changes? Or the password?

I'm curious what others are doing/thinking in this sort of situation.

Thanks in advance for any input-
--
--
--Andy Badera
http://higherefficiency.net
http://flipbitsnotburgers.blogspot.com/
http://andrew.badera.us/
http://changeroundup.com/
and...@badera.us
(518) 641-1280
Google me: http://www.google.com/search?q=andrew+badera

[Maarten Schenk]

I'm storing them in a cookie on the user's computer. Might not be the
most secure way, but at least it is not stored on my server so if I
ever get hacked no user data is stolen...

Kind regardsn
Maarten Schenk

On 4 aug, 18:15, "Andrew Badera" <and...@badera.us> wrote:
> Hi all-
>
> As we await OAuth, many of us are faced with storing a user's username +
> password.
>
> I'm curious if there's a set of best practices anyone's using these days, or
> maybe we could brainstorm a few on-list?
>
> I have an app where:
>
> 1. User enters twitter name, password, message - no additional user
> management/authentication.
> 2. At some point, message is sent. We can now discard the cleartext
> password, but:
> 3. User still needs to look up historical entries, so maybe we hash the
> password after send.
>
> But, what if the username changes? Or the password?
>
> I'm curious what others are doing/thinking in this sort of situation.
>
> Thanks in advance for any input-
> --
> --

> --Andy Baderahttp://higherefficiency.nethttp://flipbitsnotburgers.blogspot.com/http://andrew.badera.us/http://changeroundup.com/

[Andrew Badera]

Gotcha. Unfortunately in my case they need to be persisted in the DB, and the liability you mention is exactly why I'm curious as to how others are handling this, especially in third party apps that message on behalf of the user, like twitpic.

[jazzychad]

I handle the liability by not letting it exist at all. I will not
write any apps that need to store username/password until a more
secure solution is available.

What is interesting is that, at a BarCamp this past weekend, we were
discussing this topic. I asked the group "did you know when you use
3rd party apps that when you enter your credentials that they are sent
and stored in clear text?" Most people knew, and a few people even
said "yes, but I don't care." I thought that was pretty sad.

On Aug 4, 4:41 pm, "Andrew Badera" <and...@badera.us> wrote:
> Gotcha. Unfortunately in my case they need to be persisted in the DB, and
> the liability you mention is exactly why I'm curious as to how others are
> handling this, especially in third party apps that message on behalf of the
> user, like twitpic.
>

[Andrew Badera]

Well, in the grand scheme of things, exposing Twitter credentials is far more trivial than some cracker snagging my banking login.

But yeah, in general, I certainly agree -- when possible -- avoid the liability.

Unfortunately I'm working on something that requires a non-interactive post to Twitter, so storing credentials is unavoidable.

As far as cleartext ... you can encrypt at rest ... and if you're using https to hit Twitter, you're fine there ... and SSL on the way in certainly helps ... but still, I'd rather just not have to store a password ... API key/OAuth anyone?

[Mario Menti]

On Mon, Aug 4, 2008 at 11:21 PM, Andrew Badera <and...@badera.us> wrote:

Well, in the grand scheme of things, exposing Twitter credentials is far more trivial than some cracker snagging my banking login.

But yeah, in general, I certainly agree -- when possible -- avoid the liability.

Unfortunately I'm working on something that requires a non-interactive post to Twitter, so storing credentials is unavoidable.

As far as cleartext ... you can encrypt at rest ... and if you're using https to hit Twitter, you're fine there ... and SSL on the way in certainly helps ... but still, I'd rather just not have to store a password ... API key/OAuth anyone?

I agree, I also run a service that does non-interactive posts to twitter, and combined with the fact that posts to twitter have to use basic auth, it's not possible to use one-way encryption in your database. Yes, SSL helps, but the long-promised oAuth support/implementation would really take a load off my mind..

Cheers,

Mario. 

[jstrellner]

While oauth is ideal, we all know it isn't here yet.

What we are doing is storing the Twitter account ID. Twitter stores
an account id that is unique to each user. What you can do is
normalize your database using the twitter id, which never changes.
Then you let the user login to twitter using their username and
password and you get the ID back from Twitter - which you then
associate with the information in your database.

If you need to post something back to twitter though, you can do a
couple of things, but the best way would probably be to cache the
username/password for the current session only, which would still
greatly minimize the chance of the credentials getting out since most
of your users likely aren't going to be logged in at the same time.
While the session is active, you could do some kind of encryption on
it like 256 bit Rijndael encryption, which is two way encryption. It
isn't a foolproof secure way, but it beats storing the data in clear
text.

-Joel

On Aug 4, 9:15 am, "Andrew Badera" <and...@badera.us> wrote:
> Hi all-
>
> As we await OAuth, many of us are faced with storing a user's username +
> password.
>
> I'm curious if there's a set of best practices anyone's using these days, or
> maybe we could brainstorm a few on-list?
>
> I have an app where:
>
> 1. User enters twitter name, password, message - no additional user
> management/authentication.
> 2. At some point, message is sent. We can now discard the cleartext
> password, but:
> 3. User still needs to look up historical entries, so maybe we hash the
> password after send.
>
> But, what if the username changes? Or the password?
>
> I'm curious what others are doing/thinking in this sort of situation.
>
> Thanks in advance for any input-
> --
> --

> --Andy Baderahttp://higherefficiency.nethttp://flipbitsnotburgers.blogspot.com/http://andrew.badera.us/http://changeroundup.com/

[Andrew Badera]

Not sure how much I can normalize, as I'm working with Google App Engine, and BigTable is a big flat sonofagun ... however, storing the account ID is absolutely do-able and absolutely awesome, thanks, not sure why I didn't think of that.

Don't have to worry about active sessions and per-session encryption much ... it's more of a fire-and-forget kind of scenario.

[Jerry C]

Hi Andrew,

Even though you are using Google App Engine, Adobe AIR developers
should be aware that EncryptedLocalStore is made for this purpose.
According to Adobe documentation, "AIR uses DPAPI on Windows and
KeyChain on Mac OS to associate the encrypted local store to each
application and user. The encrypted local store uses AES-CBC 128-bit
encryption."

In fact, most Twitter AIR-based applications, when given the choice
between a configuration file (such as an XML-based solution), a SQLite
database and EncryptedLocalStore, seem make the right decision. So
far, I've only seen one Twitter app that stores credentials in a
SQLite database.

For more information:
http://livedocs.adobe.com/labs/air/1/jslr/flash/data/EncryptedLocalStore.html
http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/data/EncryptedLocalStore.html

Cheers,

Jerry

On Aug 4, 6:00 pm, "Andrew Badera" <and...@badera.us> wrote:
> Not sure how much I can normalize, as I'm working with Google App Engine,
> and BigTable is a big flat sonofagun ... however, storing the account ID is
> absolutely do-able and absolutely awesome, thanks, not sure why I didn't
> think of that.
>
> Don't have to worry about active sessions and per-session encryption much
> ... it's more of a fire-and-forget kind of scenario.
>

[Damon C]

Andrew,

Here's another idea I've been tossing around, which kind of adds on to
Joel's suggestion above.

While it requires the user to remember another piece of information,
you could ask them for some sort of PIN or other string to use as part
of the encryption key. This would help ensure that when the data is at
rest, not even you can gain access to it without that users'
additional information.

Damon

On Aug 4, 4:00 pm, "Andrew Badera" <and...@badera.us> wrote:
> Not sure how much I can normalize, as I'm working with Google App Engine,
> and BigTable is a big flat sonofagun ... however, storing the account ID is
> absolutely do-able and absolutely awesome, thanks, not sure why I didn't
> think of that.
>
> Don't have to worry about active sessions and per-session encryption much
> ... it's more of a fire-and-forget kind of scenario.
>

[jstrellner]

Damon,

That works too, but as you hinted at, the user then has to remember
more info. We use seeding, but it is randomly selected for the user
at login and on stored in the session.

I wrote out what we all we do to fully secure the login, but then I
realized that I was giving out too much information. I will say that
there are about 6 steps to get just one of our users twitter login
information, and it must be done in less than 15 minutes (while they
are logged in). If the user clicks on any page, the seed is
randomized again, thus invalidating a login. So in short, they have
to know what they are doing and be really, really fast at it.

Even though it sounds pretty secure, I'd still like to have OAuth
instead....

-Joel

[Derek Gathright]

I'd think the least amount of liability when storing credentials would be to encrypt the data in a cookie with a key stored on the server.  Still hackable, but the data is out of your hands so less of a need to worry.  Currently, I'm storing it in the session data encrypted in the DB, so when someone logs out... row deleted.

Also, it's good to let users know exactly what you are doing with their data and let them make up their own mind.  That's my biggest complaint with a lot of the uni-functional online apps.  I'd imagine most Twitter power-users are used to providing credentials to 3rd party apps and it's not the end of the world if their account is hacked (unlike an email or bank account).

Also, as someone mentioned, storing by twitter user_id is absolutely essential for any application that provides a historical layer on top of Twitter. It's an unlikely, but possible, scenario that someone changes their username to one formerly taken by someone else, and upon logging in they could be mapped to the other user's data if the association is by username and not user_id.

That's my $.02 anyhow.

[Andrew Badera]

Cookie's great if you're dealing with a desktop or mobile client, but what about sites like, say, TwitPic, where it's all web-driven, there's no client to be setting a cookie? That's the situation I'm in.

I think we can all agree, properly encrypted cookies, or a secure, encrypted, machine/user datastore, are the way to go when you're dealing with a desktop or mobile client ... but what about the burgeoning field of apps that are purely web, no active client interaction, acting on behalf of a Twitter user?

Here's what I'm looking at:
Authenticate with username/password to get User ID
Use User ID for all interal records and operations
Capture username & password at sign-in in, to associate with tweets to occur later
Encrypt password at rest until tweet event occurs
Hash or destroy password upon occurrence of tweet

I think destroying makes the most sense; I was thinking hashing previously in order to associate users to historical tweets, but User ID eliminates the need to keep the password after send.

Now, if a user changes their username or password between entering the tweet, and the tweet being sent, they're out of luck ... but I don't see a great way around that. Can we lookup current username based on User ID values?

[Derek Gathright]

"Can we lookup current username based on User ID values?"

show

Returns extended information of a given user, specified by ID or screen name as per the required id parameter below.  This information includes design settings, so third party developers can theme their widgets according to a given user's preferences. You must be properly authenticated to request the page of a protected user.

URL: http://twitter.com/users/show/id.format

Formats: xml, json

Parameters:

• id.  Required.  The ID or screen name of a user.  Ex: http://twitter.com/users/show/12345.json or http://twitter.com/users/show/bob.xml
• email. Optional.  The email address of a user.  Ex: http://twitter.com/users/show.xml?email=te...@example.com

[Andrew Badera]

Excellent, thanks!

[jstrellner]

As Derek mentioned, the show method would work for this. But that is
another call you'd have to make for a very unlikely case. You should
probably only do this on an error where Twitter is reporting an
invalid user.

You may encounter a password change, and in that case, twitter won't
help you through any of their calls. The user would have to directly
provide it.

By analyzing what twitter returns on an error you can probably avoid
the show method entirely simply by forcing the user to login again if
you encounter a username/password error. That is probably what I
would do.

-Joel