Some fraction of users will have a Pandora login cookie, which means they'll see the page.įurther, every response for the Pandora settings page gets a tag of Malorie's creation. The network-be it provided by a laptop hotspot or a router with custom software-is programmed to intercept request/response cycles as follows.Įvery response, except those that are part of Malorie's attack, is replaced with a redirect to Pandora's settings page. Malorie goes to the coffee shop/train station/airport terminal and sets up a public wifi network. Very true! And here's a realistic attack scenario: If you are going to hold them to that standard, you might want to start with a more significant target like say. It seems like a very high bar to hold Pandora to given the nature of their service. They could do more to mitigate it, but it'd undoubtedly have some seriously negative user experience consequences. In short: the man-in-the-middle attack risk is always a risk unless the user takes extraordinary efforts. 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. This is a basic principle of security for anything other than MAC style security systems (and even then.)Ģ) 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. With a minor bit of effort, they can get access to any future password you use. 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.ġ) 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). Inject scripts into the main (non-HTTPS) Pandora page and read it out of the DOM. Walk up to a computer you're logged into and read your plaintext password.Ģ. It doesn't matter how it happens behind the scenes - the fact that someone can do either of the following is still majorly problematic:ġ. The real, major issue here is the fact that passwords are loaded into an HTTP-served page and displayed back to the user. 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. 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.Įven 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). So, it looks like it is stored encrypted, locally on the system. Has anyone checked to see if this is the case?įollow 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. The password value could be simple extracted from local storage. It certainly would mean the password need not be stored at all on Pandora's server. A specific attribute whose name appears to be a randomly generated (encrypted) is updated.Īssuming that is password, stored encrypted, the exposure here may not be what people think. There is a record of HTML local storage keyed on "jStorage" which appears to be a giant JSON blob. Okay, I just did a simple test of what happens when I change my Pandora password. Pandora needn't store the password on their servers. There may be a security issue here, but I think there is a distinct possibility that it certainly isn't what people think.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |