Audiogalaxy and P2P Security Practices

by Marc Hedlund

Related link: http://www.audiogalaxy.com/



Now that Napster has transformed from a technology company into a law firm, many users have started looking around for other companies with technology similar to Napster's. One company that has started to attract attention is Audiogalaxy, a Texas-based company, which was featured in the Wall St. Journal on Monday, July 16th.



In trying out the Audiogalaxy system, I was impressed with the number of music files I could find in its databases. I was much less impressed, though, with the security choices made by the company's engineers. Here is the note I sent them reporting my concerns:






To: help@audiogalaxy.com

Subject: AudioGalaxy sending cleartext password in URL



To the maintainers of AudioGalaxy,



I started up your AudioGalaxy Satellite peer-to-peer filesharing client tonight and noticed that when I pressed the 'Go' button in its main screen, my browser went to the following URL:



<http://www.audiogalaxy.com/satellitelogin?loginUsername=USER&loginPassword=PASS>


[I have removed my username and password from the URL above.]



It is problematic to send a password over the Internet in plaintext in this manner. Worse, your authentication method enters the username and password into the user's browser history records, where it then can be discovered by anyone else using the same computer.



Many users choose the same password for most or all Web site accounts they create. While this is not a good practice, it means that sending a cleartext password and storing a password in the browser's history create the potential for a user to have many accounts compromised -- not just the account on your service.



I notice that you use PHP extensively on your site. PHP has built-in support for MD5 hashes -- see <http://www.php.net/manual/en/function.md5.php>. Hashing the password when the user chooses it on your site, storing the hash in your database, and having the Satellite send the password hashed for login would be at least some improvement over your current practice. (This would also protect the user's password if your database machine were ever compromised.) Please consider making this change, or preferably an even more rigorous one, in a future release of your software.



Obviously you don't want a lecture from a user, but the peer-to-peer architecture of your program, shifting significant functionality out of the browser and into a custom client with filesystem access, increases my concern about security in your software. You are not restricted by the security restraints built into Web browsers, and you need to take greater responsibility for your code's actions as a result. Your password handling choices do not leave me with much confidence in your ability to meet this responsibility, so regretfully I have uninstalled your Satellite program from my machine and will not use it in the future.






Security is a serious topic for peer-to-peer developers. P2P systems have the potential to poke holes straight through many of the security systems users have adopted while connecting to the Internet in recent years. While Audiogalaxy's slip-up is not directly related to the 'peer' parts of its system, it nonetheless reveals a lax attitude about security that could easily carry over into its peer client programming. P2P security will be featured in its own track at the O'Reilly Peer-to-Peer and Web Services Conference in Washington, D.C., this September 18-21.