Pandorhack: Stealing Pandora Passwords(pandorhack.zorinaq.com)
pandorhack.zorinaq.com
Pandorhack: Stealing Pandora Passwords
http://pandorhack.zorinaq.com/
7 comments
It shocks me that people keep downplaying the issue here. Storing a password in a visitors browser especially in a place where it can be exploited is lazy not only from a security perspective but if a users original password can be exposed as well as their email address a lot of people use the same password for everything (not everyone is a security conscious developer) especially email. This is just lazy programming and security at its finest, so glad I don't use Pandora.
Interesting though. We all knew HTML5 local storage bugs would happen, but this is the first one I've seen in the wild.
Not a bug at all. It's doing exactly what it should be doing. It's an oversight on an engineering department, if anything.
To be fair, this is really a tiny issue compared to them storing plaintext passwords server side as they were initially accused of doing. If you have access to a browser's local storage, you can also probably install a browser extension that key logs any password inputs. Or you can view all the browser's saved passwords. etc.
I disagree. Putting aside saved passwords which I admit is a big aside. The browser's usual attack vector is login or session cookies. It will grant users access to the account but it doesn't usually leak any information in itself. However this leaks the, email, username, password, and a myriad of other data. This is compounded by the risk of leaking data in the event of a javascript injection. Usually this would allow the js to steal login cookies or do actions on the site (hopefully anything 'secure' requires an additional password input), but now they can whisk the usernames and passwords off site and elevates the breach to be almost as bad as a database leak.
Again: If there is JavaScript injection, they can capture the password at the time you enter it anyway. Once you have JavaScript injection, almost any site will cough up all that data without issue. Heck, they can do a full-on man in the middle attack if they so desire.
It doesn't appear that merely cloning a login session cookie would get you access to the password, as it does not appear that the server even knows what it is. In fact, this approach they've used seems like it would allow for password challenges whenever Pandora wanted to, which makes session stealing far less effective.
It doesn't appear that merely cloning a login session cookie would get you access to the password, as it does not appear that the server even knows what it is. In fact, this approach they've used seems like it would allow for password challenges whenever Pandora wanted to, which makes session stealing far less effective.
I agree with you. That said, it is a possible vector they should patch up, so it shouldn't be ignored by any means. Its just minor enough I dont see why any of us should care.
I hope you never click 'save password' in Pidgin, or about a thousand different local apps. There's a 'vector' there too!
I know you're being funny, but for everyone else here's their spiel on saving your passwords locally: https://developer.pidgin.im/wiki/PlainTextPasswords
The default and most secure setting is to not save passwords.
The default and most secure setting is to not save passwords.
> The default and most secure setting is to not save passwords.
While true from a systems vantage point, it isn't really true once you bring in the human factors. It just isn't reasonable to think people will type in distinct and secure passwords for each of their IM accounts each time they start up their client. It's far more reasonable to have a password manager which manages which applications have access to which passwords, and which stores the passwords all protected by a master password (ideally with two factor authentication).
While true from a systems vantage point, it isn't really true once you bring in the human factors. It just isn't reasonable to think people will type in distinct and secure passwords for each of their IM accounts each time they start up their client. It's far more reasonable to have a password manager which manages which applications have access to which passwords, and which stores the passwords all protected by a master password (ideally with two factor authentication).
[deleted]
[deleted]
[deleted]
[deleted]
[deleted]
bloggez(1)
Oh noes! you mean my hacker mom will be able to log onto my pandora account and listen to my Yes/Supertramp mix station!!??
Ok, admittedly, bad form on pandora's part but seems pretty low impact to me.
Ok, admittedly, bad form on pandora's part but seems pretty low impact to me.
I strongly disagree. People use the same password on multiple sites all the time. If someone shares a password between Pandora and Gmail or PayPal, for example, you now have access to their email or their money.
Honestly, if you share your PayPal password with other sites, you are already asking for it pretty badly. I'd say the same thing about your Google password, but if you use two-factor authentication is isn't quite so bad (and in that case Pandora isn't a concern).
The reality is though, what Pandora is doing prevents the password from going over the 'net at all, which arguably protects it from being stolen better. For someone to get access to it, they'd need access to your machine, at which point... just how secure do you think your PayPal and Google accounts (assuming no two-factor auth) will be?
The main increased risk factor if you shared your PayPal and Pandora passwords would be that if someone had read-only access to your filesystem, they could still get your PayPal password (which wouldn't otherwise be the case). This would be a potentially big exposure if you have unencrypted backups (though why backup HTML5 storage or browser data in plaintext to an untrusted target if you want security?) or for whatever reason you let other people read your browser profile directory.
Still doesn't feel like a big deal.
The reality is though, what Pandora is doing prevents the password from going over the 'net at all, which arguably protects it from being stolen better. For someone to get access to it, they'd need access to your machine, at which point... just how secure do you think your PayPal and Google accounts (assuming no two-factor auth) will be?
The main increased risk factor if you shared your PayPal and Pandora passwords would be that if someone had read-only access to your filesystem, they could still get your PayPal password (which wouldn't otherwise be the case). This would be a potentially big exposure if you have unencrypted backups (though why backup HTML5 storage or browser data in plaintext to an untrusted target if you want security?) or for whatever reason you let other people read your browser profile directory.
Still doesn't feel like a big deal.
you've got a really good point there and on second thought I totally agree with you. I guess I was looking at it from a more "my app"-centric point of view.
I suppose these days, in light of the point you make, if you accept a password from an end-user there is no such thing as a low impact disclosure.
I suppose these days, in light of the point you make, if you accept a password from an end-user there is no such thing as a low impact disclosure.
[deleted]
[deleted]
Every week a story like this comes out. And a lot with really large companies that have huge amounts of funding and are certainly capable of hiring people who know what they are doing.
As fun as they are to read about, I don't care so much about the actual attacks. How to do it wrong is well known.
I am interested in what causes this problem in general. What is causing so many companies to have such abysmal security practices even though we know how to do it better? Can it be fixed?
If the industry does not police this, the government will have to regulate us to ensure compliance with more reasonable practices. That means auditing of our code by independent agencies, paying the fees to do so, suffering the inevitable cases where code is stolen by corrupt auditors, and the foot in the legal door for future and expanding governmental code regulation and auditing at all levels, not just web facing. It would be much better if we could solve this problem ourselves as a responsible industry and avoid the necessity for invasive regulation.
As fun as they are to read about, I don't care so much about the actual attacks. How to do it wrong is well known.
I am interested in what causes this problem in general. What is causing so many companies to have such abysmal security practices even though we know how to do it better? Can it be fixed?
If the industry does not police this, the government will have to regulate us to ensure compliance with more reasonable practices. That means auditing of our code by independent agencies, paying the fees to do so, suffering the inevitable cases where code is stolen by corrupt auditors, and the foot in the legal door for future and expanding governmental code regulation and auditing at all levels, not just web facing. It would be much better if we could solve this problem ourselves as a responsible industry and avoid the necessity for invasive regulation.