Skip to content

Known Security Weaknesses

klnusbaum edited this page Feb 16, 2012 · 5 revisions

This page documents known security flaws with UDJ. Yep, we're pointing out our flaws (at least the ones of which we are aware). Why? Because we believe in transparency and don't think that these flaws are a cause for any real concern at this time (that said we're totally open to re-evaluating any and all of these issues should the need arise). Unless other wise indicated, we don't really plan on fixing any of these. It's just not worth it to address these issues at this time.

If you find any new issues, please let us know. Just drop us a line [email protected].

Encrypted Credentials Storage on Desktop Client

When saving the users credentials on the desktop, the desktop client just uses a simple cipher to encrypt the credentials that it then stores on disk. We use the same cipher key for all desktop clients thus we have a single point of failure should the cipher key ever be compromised. Why haven't we addressed this?

  1. The credentials being stored in this file are only used for retrieving tickets that are used for adding music to a library, adding songs to an active playlist, etc. In other words, these credentials don't really protect anything all that valuable (yet). If some one is impersonating your UDJ account, oh well. It's certainly not the end of the world.
  2. The only way to take advantaged of this would be to steal the cipher key we're using, gain physical access to a users machine, and then decrypt the file containing their credentials. If some one has gained physical access to your machine, you've got bigger problems than just your UDJ credentials being compromised.
  3. If the cipher key was ever compromised, all we'd need to do is release an update to UDJ with a different cipher key. The users would then have to enter their credentials once more so they could be re-encrypted with the new cipher, but that's not that big of a deal.
Clone this wiki locally