There appears to be a real security issue that every one missed in this thread: the password does not appear to be encrypted, but merely obfuscated, using the same obfuscation technique as the one used to obfuscate the randomly generated JSON attribute names.
Which means that even after logging out of pandora, the password would remain in the HTML local storage, and could be de-obfuscated, and log back into pandora.
I am currently working on reverse-engineering the obfuscation algorithm...
Update 04:49 UTC: I am done reverse-engineering Pandora's javascript code!
And I was right: the JSON object that it stores in the HTML local storage is merely obfuscated with static keys, not encrypted. I was able to decrypt the full object, including my Pandora password:
lastUserId: "xxxxxxxxx"
storedUserIds: ["xxxxxxxxx"]
Uxxxxxxxxx.StationSortOrderAlpha: false
Uxxxxxxxxx.isAnonymous: false
Uxxxxxxxxx.Username: "xxx@xxx.com"
Uxxxxxxxxx.Password: "myCleartextPassword"
hasLoggedIn: true
(xxxxxxxxx) is the numeric Pandora user ID.
I will publish an tool for decryption as a proof-of-concept, in the next hour.
What were Pandora's developers thinking? This is not a huge flaw, but they should certainly not store sensitive data like the user's password in the local storage.
Yup, I tested with 2 different accounts, using 2 different browsers, even from 2 different IPs. The static keys seem to never change, they are served from the same .js file.
The attribute name is obfuscated, which makes it harder to programmatically find the password (presuming it is under a different name for each account). The password itself is stored encrypted.
Here's the thing: if someone has this kind of access to your browser, wouldn't it be simpler to install a simple browser plug-in that scrapes off any data typed in to a password input field?
It's a different attribute name on my system. Looks like it is different for each account, as it should be.
It's just sad seeing Pandora raked over the coals for this when they clearly have put in a lot of thought and done things as right as possible given their constraints.
> I know why it is different on each system, it is because the numeric user ID is encoded in it.
Yes, this is what I was saying.
> I am 99% sure I am right, all the fields/values are merely obfuscated with a constant key. Not proper encryption at all.
Okay, so if I tell you my key for the field is: bc673ea54a2b7153aaafbf178e9b0892e1f2e56be5aaa5a7, can you discern my key? I'm betting not.
First, this is indeed obfuscation. There undoubtedly is a constant key. The point is merely to make it difficult for an attacker to automate an attack with "grab the attribute with key X". It's possible these attributes are HMAC's of the attribute name + a randomly generated secret, which is actually a pretty good use of encryption under the circumstances. It's certainly miles beyond what most other sites use, and makes attacks against the HTML5 a waste of time (way better to go after the elements in the DOM, which have constant names).
> First, this is indeed obfuscation. There undoubtedly is a constant key...It's certainly miles beyond what most other sites use
The state of typical security in software projects of the 1990's: sad, sad... Any improvement in 2012: such a piddling little improvement. The trend is clear as is the conclusion: the average dev can't be trusted to do security. It doesn't work!
There isn't much more you can do with the key names really. The issue with them using a static key for encrypting the local password is another thing...
> The issue with them using a static key for encrypting the local password is another thing
Actually, it is the thing that I was referring to. Doing things with the key names is another thing -- wily and probably benefits them a little, but it isn't real security.
Which means that even after logging out of pandora, the password would remain in the HTML local storage, and could be de-obfuscated, and log back into pandora.
I am currently working on reverse-engineering the obfuscation algorithm...