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...
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.
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.
Good job!
> This is not a huge flaw, but they should certainly not store sensitive data like the user's password in the local storage.
Well, if it was properly encrypted, I'd disagree with you, but since it isn't, I'm not going to quibble.
Out of curiosity, how do you know the key is static, and not per account? Did you test with two accounts?
Pandorhack: Stealing Pandora Passwords http://news.ycombinator.com/item?id=4553184
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 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 am 99% sure I am right, all the fields/values are merely obfuscated with a constant key. Not proper encryption at all.
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).
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!
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.