Doubly Encrypted for Extra Safety

Floating 'round the twitterverse today was a new service called twittersnooze. The possibilities for twitter apps seem endless, and considering how easy and, well, fun the api is to play with, I'm sure there will be many more.

Among other nice features, I applaud the auther's honest disclosure that "TwitterSnooze stores passwords on the DB". Currently as the twitter api is written, this is a necessary evil for an application of this sort. If you want to authenticate, you need the user's password in plaintext.

However, there is a way around this that I think twitter, and other web sites that have apis should consider doing (I think lastfm does this, but I'm not sure). Basically I am suggesting that the site doubly encrypt their passwords, and make the first level of encryption publicly available. How exactly would this work? In this example, I will describe a double encryption scenario using salted md5, and I will use twitter and twittersnooze as api providers and consumers:

• When the user signs up for twitter 2 salts are generated (salt1 and salt2) and the password (plaintext) is then encrypted as: md5(salt2 + md5(salt1 + plaintext))
• Both salts will be stored in the twitter's user table, as will the result of the double encryption.
• Salt1 will be made available through the api without authentication.
• When a user signs up for twittersnooze, twittersnooze will make an api call to retrieve salt1. It will then encrypt the user's password as md5(salt1 + plaintext) and store the hash in it's user table.
• When twittersnooze needs to authenticate as the user, it sends the hash that it has stored. Twitter then applies md5(salt2 + hash) and checks that it matches it's own user table.
• Viola! No plaintext passwords stored anywhere!

Some other benefits:

• Twittersnooze can now use the twitter password for its own user accounts, saving the user the trouble of creating a new account.
• The plaintext password never has to be transmitted over the wire between twittersnooze and twitter.
• If salt1 == salt2 then there is no additional storage requirements for twitter.

Of course, there are other approaches. The first one that comes to mind is to generate api keys for every user, which can be fetched via their api. This is certainly better than nothing, but has the drawback of requiring that the plaintext password be sent over the wire for authentication when the api key is fetched.

Please note that I am not suggesting that applying md5 twice is stronger than applying it once. Thats a different issue and I think thats what people usually mean when they say "double encryption". Rather, I am suggesting that doing it obviates the need to store plaintext passwords.

If tweetersnooze's database was compromised under this scenario, it would still be a security breach for twitter. It would not, however, impact the naive user who uses the same password for twitter that they use for their online banking.

Any thoughts?

LOTD tracker update II

The great staff over at wiredset (the makers of trendrr) fixed the bug, and I was able to update the bad data points. Thanks so much Dustin for the quick turnaround, and on a Sunday nonetheless!!

Muxtape - clean and simple

I have to admit that like so many others I am impressed by Muxtape. A UI experiment that has caught like wildfire, clearly Justin filled a need, and did it with style and skill. I put up a muxtape of some stuff that I am currently into, and I put a good amount of thought into the selections and the ordering.

Of course, the biggest question is the business model. 3 possibilities:

• Linking to amazon, and/or itunes and even possibly giving the muxtape author a cut of the revenue generated from singles sales. (This came up at the most recent NY tech meetup)
• Audio ads at some point through the muxtape.
• MICROPAYMENTS!! Whether you pay 10 cents to listen, or you pay 10 cents for for someone else to listen, I think its time micropayments started coming into play in the US.

Here are some other suggestions:

• Multiple file uploads: Wouldn't it be much easier if you could queue your uploads at once, and then click upload for all of them? I really don't like that I have to go one file at a time. One possible way to do this is with a java applet (gasp) called jupload but theres got to be a way to do it with javascript and iframes.
• Uploads out of order: I uploaded my playlist in the order in which I wanted them to play. It wasn't until I was done that I realized I had to reorder them as they were backwards. (The last track uploaded was the 1st in the playlist)
• Mixtapes always had an intended audience, so should muxtapes: I think this is my biggest criticism. I like that muxtape forces you to edit down to 12 songs. However, if the idea is to simulate the old school mixtape, then it fails for this reason. I always made mixtapes with an audience of 1 in mind. How can I make one mixtape that my mom would like and my weird friend from college would also like?? I can't.

Finally, I want to thank Justin for perhaps the biggest innovation on the site. I think its absolutely brilliant that muxtape doesn't require you to enter your password twice when you register. I have always believed that I could manage to get my password right on the first try, and finally someone gave the chance to prove it. I am really curious to know whether this has caused significant problems with registration or not.

So, please give my muxtape a spin. I guarantee there will be music on it you have never heard, and just maybe something that you will enjoy.

LOTD tracker update

I am very proud to have gotten a link from Fred Wilson's blog mentioning the lyric of the day tracker that I built. Of course, I have been going crazy all day trying to figure out how to fix the data problem that was caused by twitter being down last night for maintenance.

I guess I could have handled bad data in my bot's code, but I thought I would be able to manually edit the data if there were any problems. I still think that I can, but I can't seem to do it at the moment. Either trendrr is having a temporary problem, or there is a bug in their site as their data view clearly allows for in place updates of the data, however it doesn't allow for saving the change. I have several frantic emails in to trendrr support, however something tells me they have better things to do on a Sunday :)

Anyway, I hope to fix the data soon. I am excited to have the views and the link, but of course I want it to be perfect.

Lyric of the Day Stats

http://www.trendrr.com/timeseries/378706
Written in ruby using Hpricot. Unfortunately I couldn't see where the twitter api allows for fetching the post and user counts for an account, so I just use the original web api. Updated hourly.

Back from the dead

I'm too excited about goings on online and in my life to keep quite. I'm baacccckkkk....