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.
