5 ms·

There may be a security issue here, but I think there is a distinct possibility that it certainly isn't what people think. Pandora needn't store the password on

by cbsmith 14y ago

There may be a security issue here, but I think there is a distinct possibility that it certainly isn't what people think. Pandora needn't store the password on their servers. Just posted this to the Google+ thread: Okay, I just did a simple test of what happens when I change my Pandora password. There is a record of HTML local storage keyed on "jStorage" which appears to be a giant JSON blob. A specific attribute whose name appears to be a randomly generated (encrypted) is updated. Assuming that is password, stored encrypted, the exposure here may not be what people think. It certainly would mean the password need not be stored at all on Pandora's server. They could just have an HMAC. The password value could be simple extracted from local storage. Has anyone checked to see if this is the case? Follow up: Okay, I further confirmed that if I set the password back to a prior value, that field in jStorage flips back to the prior value. So, it looks like it is stored encrypted, locally on the system. I haven't traced through all the JavaScript, but it seems likely that the security issue here is different than perceived, and might even be non-existant.

aiiane 14y ago
Even if that's the case, though, that actually only mitigates the least problematic issue here (namely, how the passwords are stored on Pandora's end). At least the stored passwords there are behind other forms of security - so regardless of whether they're stored in plaintext or hashed on Pandora's servers, it'd still take an actual breach of Pandora's servers to retrieve them. The real, major issue here is the fact that passwords are loaded into an HTTP-served page and displayed back to the user. It doesn't matter how it happens behind the scenes - the fact that someone can do either of the following is still majorly problematic: 1. Walk up to a computer you're logged into and read your plaintext password. 2. Inject scripts into the main (non-HTTPS) Pandora page and read it out of the DOM. If they did go to the trouble of saving the password into local storage with encryption, one has to wonder what they were thinking, given that it's a lot of effort for a solution that's far less secure than the trivial effort of just storing hashed passwords.
- peterwwillis 14y ago
  The fact that someone could physically break into your machine to steal your Pandora password is extremely problematic? I'd hate to see your write-up once somebody knocks over the carton of milk... If they used an HMAC and the secret is stored locally, aside some some sort of JavaScript/browser exploit, it's more secure than a non-MAC cryptographically hashed password, and much more secure than the plaintext password you submit in your browser to log into almost every website in the entire world. This Pandora password is just visible to you on your computer. If you're worried about that, please don't have a heart attack, but they have these things called malware now ...
  - stcredzero 14y ago
    > The fact that someone could physically break into your machine to steal your Pandora password is extremely problematic? I'd hate to see your write-up once somebody knocks over the carton of milk... For users that use the same few passwords everywhere, it could well be a problem.
    - peterwwillis 14y ago
      My reply to that argument here: http://hackerne.ws/item?id=4551852 http://hackerne.ws/item?id=4551852
      - stcredzero 14y ago
        Blame the user is a bankrupt strategy. Maybe you can deflect the blame, but it does nothing to keep the black hats at bay. In essence, you are admitting you are wrong. (Clearly passwords period are broken for use by non geeks, but that is another can of worms.)
        peterwwillis 14y ago
        It's not anyone's fault but yours if you reuse a password. But now the straw men will come out of the woodwork, declaring that password reuse is somehow a good thing. All this shit started because someone who does not understand security thought it was horrible that a local program might store a password locally in plain text. There are a billion local programs that store passwords in a reversible way. Know why? Because sending a non-mac password is the same if it's hashed or not. Blame whoever you want to blame, I don't care. But don't tell me Pandora is responsible for the total security of every moron on the internet, either.
- cbsmith 14y ago
  1) No matter what they do, if someone walks up to a computer that you're logged in to, they have a very good shot at getting your plaintext password (there's a distinct chance it's in a memory buffer somewhere). With a minor bit of effort, they can get access to any future password you use. This is a basic principle of security for anything other than MAC style security systems (and even then...) 2) I think there is a very real risk there, but of course, unless they use HSTS (and therefore always HTTPS) everywhere, there is a risk of this. Even if they use HSTS (which isn't broadly supported in browsers yet), almost no-one checks TLS certificates for man-in-the-middle attacks. In short: the man-in-the-middle attack risk is always a risk unless the user takes extraordinary efforts. They could do more to mitigate it, but it'd undoubtedly have some seriously negative user experience consequences. It seems like a very high bar to hold Pandora to given the nature of their service. If you are going to hold them to that standard, you might want to start with a more significant target like say.... the Apple Store.
  - aiiane 14y ago
    Re #1: There's still a matter of degree, however - this takes zero technical knowledge and zero external tools, works on every platform that Pandora runs on, and requires maybe 5 seconds of time. Re #2: Again, it's a difference of degree. Invalid TLS certs will at least give a browser warning that a user isn't used to seeing (in modern browsers), cluing them in that something might be up. Sure, some users might bypass it anyway, but there's at least some tip-off. Furthermore, there's no reason why the password needs to be in the DOM past the login page, which can easily be served over full HTTPS with no user experience impact. Yes, that can still fall prey to session hijacking if you don't use HTTPS for the rest of the site, but session hijacking doesn't give you passwords that you can use to go break into other sites.
    - cbsmith 14y ago
      #1: You know what also requires zero technical knowledge and zero external tools and requires maybe 5 seconds of my time? Typing in a new password for the account and clicking "save". #2: It needn't be an invalid TLS cert. It could be a valid TLS cert pointing to another domain. The browser provides no warning and you only notice it if the check the domain is different from the one you expect. Watch out for domains that are only different because they use a funky character that looks like the one you are expecting.
- jarrett 14y ago
  Very true! And here's a realistic attack scenario: Malorie goes to the coffee shop/train station/airport terminal and sets up a public wifi network. The network--be it provided by a laptop hotspot or a router with custom software--is programmed to intercept request/response cycles as follows. Every response, except those that are part of Malorie's attack, is replaced with a redirect to Pandora's settings page. Some fraction of users will have a Pandora login cookie, which means they'll see the page. Further, every response for the Pandora settings page gets a <script> tag of Malorie's creation. The JS reads the value attributes of the password and email fields and sends them to Malorie's server. Malorie then has a bunch of email/password combos. A lot of users will have reused that same combination on many different sites. Quite possibly their email accounts too, which would facilitate even more account takeovers via password reset emails. So now Malorie can steal entire online identities. From people who reuse passwords, anyway. To protect against this and many other attacks, everyone should avoid reusing passwords. A password manager, such as the excellent 1 Password, is the most practical solution.
mrb 14y ago
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...
- cbsmith 14y ago
  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?
  - mrb 14y ago
    The attribute name may be obfuscated, but it appears to be always the same (at least in my browsers): bc673ea54a2b7153aaafbf178e9b0892e1f2e56be5aaa5a7
    - cbsmith 14y ago
      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.
      - mrb 14y ago
        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.
revelation 14y ago
And why exactly would they go to all this trouble for displaying the correct number of stars in a password field? Unless, of course, they use this local data for actual security purposes. In which case this is a huge gaping security hole and I wouldn't trust them with a bit of my data.
- tgrass 14y ago
  I wouldn't trust them with a bit of my data I too would hate for anyone to know I have a Maroon 5 station. [EDIT] I don't.
  - mkopinsky 14y ago
    Did I just learn how I will torture my coworkers tomorrow? (We have a shared Pandora computer in the office - each day someone gets to choose what plays.)
- deleted 14y ago
  [deleted]

by cbsmith 14y ago

aiiane 14y ago

Even if that's the case, though, that actually only mitigates the least problematic issue here (namely, how the passwords are stored on Pandora's end). At least the stored passwords there are behind other forms of security - so regardless of whether they're stored in plaintext or hashed on Pandora's servers, it'd still take an actual breach of Pandora's servers to retrieve them. The real, major issue here is the fact that passwords are loaded into an HTTP-served page and displayed back to the user. It doesn't matter how it happens behind the scenes - the fact that someone can do either of the following is still majorly problematic: 1. Walk up to a computer you're logged into and read your plaintext password. 2. Inject scripts into the main (non-HTTPS) Pandora page and read it out of the DOM. If they did go to the trouble of saving the password into local storage with encryption, one has to wonder what they were thinking, given that it's a lot of effort for a solution that's far less secure than the trivial effort of just storing hashed passwords.

peterwwillis 14y ago
The fact that someone could physically break into your machine to steal your Pandora password is extremely problematic? I'd hate to see your write-up once somebody knocks over the carton of milk... If they used an HMAC and the secret is stored locally, aside some some sort of JavaScript/browser exploit, it's more secure than a non-MAC cryptographically hashed password, and much more secure than the plaintext password you submit in your browser to log into almost every website in the entire world. This Pandora password is just visible to you on your computer. If you're worried about that, please don't have a heart attack, but they have these things called malware now ...
- stcredzero 14y ago
  > The fact that someone could physically break into your machine to steal your Pandora password is extremely problematic? I'd hate to see your write-up once somebody knocks over the carton of milk... For users that use the same few passwords everywhere, it could well be a problem.
  - peterwwillis 14y ago
    My reply to that argument here: http://hackerne.ws/item?id=4551852 http://hackerne.ws/item?id=4551852
    - stcredzero 14y ago
      Blame the user is a bankrupt strategy. Maybe you can deflect the blame, but it does nothing to keep the black hats at bay. In essence, you are admitting you are wrong. (Clearly passwords period are broken for use by non geeks, but that is another can of worms.)
      - peterwwillis 14y ago
        It's not anyone's fault but yours if you reuse a password. But now the straw men will come out of the woodwork, declaring that password reuse is somehow a good thing. All this shit started because someone who does not understand security thought it was horrible that a local program might store a password locally in plain text. There are a billion local programs that store passwords in a reversible way. Know why? Because sending a non-mac password is the same if it's hashed or not. Blame whoever you want to blame, I don't care. But don't tell me Pandora is responsible for the total security of every moron on the internet, either.
cbsmith 14y ago
1) No matter what they do, if someone walks up to a computer that you're logged in to, they have a very good shot at getting your plaintext password (there's a distinct chance it's in a memory buffer somewhere). With a minor bit of effort, they can get access to any future password you use. This is a basic principle of security for anything other than MAC style security systems (and even then...) 2) I think there is a very real risk there, but of course, unless they use HSTS (and therefore always HTTPS) everywhere, there is a risk of this. Even if they use HSTS (which isn't broadly supported in browsers yet), almost no-one checks TLS certificates for man-in-the-middle attacks. In short: the man-in-the-middle attack risk is always a risk unless the user takes extraordinary efforts. They could do more to mitigate it, but it'd undoubtedly have some seriously negative user experience consequences. It seems like a very high bar to hold Pandora to given the nature of their service. If you are going to hold them to that standard, you might want to start with a more significant target like say.... the Apple Store.
- aiiane 14y ago
  Re #1: There's still a matter of degree, however - this takes zero technical knowledge and zero external tools, works on every platform that Pandora runs on, and requires maybe 5 seconds of time. Re #2: Again, it's a difference of degree. Invalid TLS certs will at least give a browser warning that a user isn't used to seeing (in modern browsers), cluing them in that something might be up. Sure, some users might bypass it anyway, but there's at least some tip-off. Furthermore, there's no reason why the password needs to be in the DOM past the login page, which can easily be served over full HTTPS with no user experience impact. Yes, that can still fall prey to session hijacking if you don't use HTTPS for the rest of the site, but session hijacking doesn't give you passwords that you can use to go break into other sites.
  - cbsmith 14y ago
    #1: You know what also requires zero technical knowledge and zero external tools and requires maybe 5 seconds of my time? Typing in a new password for the account and clicking "save". #2: It needn't be an invalid TLS cert. It could be a valid TLS cert pointing to another domain. The browser provides no warning and you only notice it if the check the domain is different from the one you expect. Watch out for domains that are only different because they use a funky character that looks like the one you are expecting.
jarrett 14y ago
Very true! And here's a realistic attack scenario: Malorie goes to the coffee shop/train station/airport terminal and sets up a public wifi network. The network--be it provided by a laptop hotspot or a router with custom software--is programmed to intercept request/response cycles as follows. Every response, except those that are part of Malorie's attack, is replaced with a redirect to Pandora's settings page. Some fraction of users will have a Pandora login cookie, which means they'll see the page. Further, every response for the Pandora settings page gets a <script> tag of Malorie's creation. The JS reads the value attributes of the password and email fields and sends them to Malorie's server. Malorie then has a bunch of email/password combos. A lot of users will have reused that same combination on many different sites. Quite possibly their email accounts too, which would facilitate even more account takeovers via password reset emails. So now Malorie can steal entire online identities. From people who reuse passwords, anyway. To protect against this and many other attacks, everyone should avoid reusing passwords. A password manager, such as the excellent 1 Password, is the most practical solution.

mrb 14y ago

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

cbsmith 14y ago
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?
- mrb 14y ago
  The attribute name may be obfuscated, but it appears to be always the same (at least in my browsers): bc673ea54a2b7153aaafbf178e9b0892e1f2e56be5aaa5a7
  - cbsmith 14y ago
    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.
    - mrb 14y ago
      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.

revelation 14y ago

And why exactly would they go to all this trouble for displaying the correct number of stars in a password field? Unless, of course, they use this local data for actual security purposes. In which case this is a huge gaping security hole and I wouldn't trust them with a bit of my data.

tgrass 14y ago
I wouldn't trust them with a bit of my data I too would hate for anyone to know I have a Maroon 5 station. [EDIT] I don't.
- mkopinsky 14y ago
  Did I just learn how I will torture my coworkers tomorrow? (We have a shared Pandora computer in the office - each day someone gets to choose what plays.)
deleted 14y ago
[deleted]