Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pandora doesn't hash their passwords

plus.google.com

Post reply on HN
Print view View original

131–140 of 160 posts

Re: Pandora doesn't hash their passwords

#131

Post by cbsmith »

mrb wrote: post #123
cbsmith wrote: post #116

Earlier quoted context omitted.

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. I am 99% sure I am right, all the fields/values are merely obfuscated with a constant key. Not proper encryption at all.

> 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).

Re: Pandora doesn't hash their passwords

#132

Post by cbsmith »

mrb wrote: post #128
mrb wrote: post #91

Earlier quoted context omitted.

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.…

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: "xx…

> Update 04:49 UTC: I am done reverse-engineering Pandora's javascript code!

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?

Re: Pandora doesn't hash their passwords

#133

Post by jmediast »

It seems like they "fixed" people being able to read the passwords by replacing the the form value with __USE_EXISTING__...

It's still trivial to automate account takeover though. Here's a PoC to take over pandora accounts on your network using MITMProxy and Tornado: https://github.com/JackWink/Pandora-Account-Takeover-Tool

Re: Pandora doesn't hash their passwords

#134

Post by dougbarrett »

just2n wrote: post #130

I see __USE_EXISTING__. I promise that's not my password, either. It seems that the server interprets this as an implication that it should keep your existing password. So I would expect if it's ever using a different value on the client, it's an accident, because this feature implies there's no reason for the client to ever save the password (not that there's a valid reason to do that anyway). That is, unless I'm ac…

I'm pretty sure they patched it, that's what I'm seeing too.

I have a feeling that they just put a bandaid on an issue that is going to get cracked open eventually.

Re: Pandora doesn't hash their passwords

#135

Post by masterzora »

peterwwillis wrote: post #88
masterzora wrote: post #78

Earlier quoted context omitted.

When password reuse is common (that is to say, in the real world) it is always the time and place for password security. Sure, you and I know that we should have different passwords for every one of the hundreds of websites we've ever visited and that they should each be as strong as the potential damages of each website warrants and that we should change them on a relatively regular basis. And we are supergood about…

Your argument, then, is that Pandora should apply password hashing to keep people from being compromised elsewhere? Assuming they only had two online accounts this might make sense. Assuming every single one of their accounts, all the same credentials, had perfectly implemented password hashing, this might make sense. But that is bullshit and we both know it. There will always be a bad implementation, or a mistake, o…

That's an excellent point. Pandora should just publish their user/pass database and it will the user's own fault if they've reused their password ever.

But, seriously, whether they should be or not the fact is Pandora is hosting sensitive information and they need to act like it. They shouldn't need to lock it down like Fort Knox, sure, but password hashing is considered a bare minimum these days.

Re: Pandora doesn't hash their passwords

#136

Post by mrb »

cbsmith wrote: post #132
mrb wrote: post #128

Earlier quoted context omitted.

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: "xx…

> Update 04:49 UTC: I am done reverse-engineering Pandora's javascript code! 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 account…

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.

Re: Pandora doesn't hash their passwords

#137

Post by aiiane »

just2n wrote: post #130

I see __USE_EXISTING__. I promise that's not my password, either. It seems that the server interprets this as an implication that it should keep your existing password. So I would expect if it's ever using a different value on the client, it's an accident, because this feature implies there's no reason for the client to ever save the password (not that there's a valid reason to do that anyway). That is, unless I'm ac…

Yes, they patched it within the past few hours.

Re: Pandora doesn't hash their passwords

#138

Post by cbsmith »

tzs wrote: post #69
peterwwillis wrote: post #21

If your Pandora password is extremely sensitive perhaps you should re-evaluate how anal you are about privacy. As long as your CC details are secure, who cares?

If a site is indifferent, incompetent, or stupid about password security, you should assume they are the same with credit card security until proven otherwise.

Actually, you really can't. A very good & common security process is to keep your payment system separate from the rest of the site.

Re: Pandora doesn't hash their passwords

#139

Post by icebraining »

SoftwareMaven wrote: post #68
pbreit wrote: post #63

Earlier quoted context omitted.

Intuitively that makes no sense so I'm wondering if someone could explain?

It's not exactly equivalent, but often is due to poor implementations. The web application has to have access to the encryption key in order to make the password check. That means if the web process gets compromised in any way, the attacker can get the plaintext password. However, it is still safer from a straight db dump type of attack. The concern for me, though, is if a company can reverse my password, I have no f…

The web application has to have access to the encryption key in order to make the password check. That means if the web process gets compromised in any way, the attacker can get the plaintext password.

Well, not necessarily, since they could be using asymmetric encryption (encrypt the password received from login, compare the result with the stored ciphertext), and keep the decryption key offline.

That said, very few of them do, because if the application can't access the passwords anyway, then there's usually no point in encrypting vs hashing them. An exception would be a manually operated password recovery system.

Re: Pandora doesn't hash their passwords

#140

Post by junto »

I had a Pandora account long before they bowed to the music cartel and restricted access to anyone outside the US.

I am now in an odd situation where I cannot login to change my password, or delete my account (not that I trust any delete account functions these days anyway).

Is there anyone here working for Pandora that could help me?

Post reply on HN