Shared publicly  - 
 
Note: This is not a password leak - you don't need to go and change your password on every site you use. Just change your Pandora password to something that isn't used elsewhere. Pandora have at least partially patched the issue. But it's still a good idea to use different passwords for different sites.

---

If you have a Pandora account, I highly recommend using a throwaway password for it (assuming you don't do so already).

Why? Because Pandora doesn't one-way hash their passwords. If your account is logged in on a computer, anyone who sits down at that computer can go and look up your password on Pandora's settings page.

Attached is an image that shows what that settings page looks like upon load - I haven't manually entered anything into the form fields and I don't use Chrome's auto-fill; the text in the fields is populated by Pandora.... including the plaintext of the password.

Things like this are why I wrote a blog post about how to do web app auth correctly:
http://codingkilledthecat.wordpress.com/2012/09/04/some-best-practices-for-web-app-authentication/

Thanks to +Dan Boger for bringing this up.

---

Edit: Also just discovered that their password-reset tokens aren't single use. You can reset the password of an account multiple times with the same reset token link...

Also, since Pandora allows you to just change the password field and hit "Save", if you come across someone's logged-in computer, you can just change their password even if Pandora didn't tell you what it was. (The right way to do this is to require the user to enter their current password along with the new password, and pre-fill none of the fields.)

---

Edit 2: It has been pointed out in the comments that even though the password itself appears to be fetched over HTTPS, the page it is inserted into is not... and thus a man-in-the-middle attack is possible to retrieve a user's password by injecting a script into the main page that reads it from the DOM, if you have control of the upstream (e.g. if you're the owner of a public wireless network or the like).

---

Edit 3: It has been further observed that Pandora appears to store the password using local storage in encrypted form and then load it into the password box locally. While this does indicate that they probably don't send unencrypted passwords over the wire, it doesn't change the fact that it is trivially easy for someone to walk up and look at your password.

---

Edit 4: Let's be clear: this isn't about how Pandora stores passwords in their database. As investigation has shown, it is quite possible that Pandora doesn't use plaintext passwords server-side. (The only entity that could definitively answer that question is Pandora.) The issue being raised here centers on the fact that it is trivially easy to recover the plaintext form of the password stored *client-side*.

---

Edit 5: Pandora has now at least partially patched this; the password field now contains "__USE_EXISTING__" by default unless changed.

#security   #pandora
847
364
Juan Carlos Paco's profile photoEivind Flores's profile photoBryan Bryan's profile photoBeatrice Spolidoro's profile photo
194 comments
 
This is common, Diablo3 dont support case sensitive passwords, a local popular site zonajobs last time i checked use plain text passwords, theres more, i dont remember...
 
Whoa. Thanks for the tip. I know I shouldn't reuse passwords, but I have been... need to break that habit.
 
Another thing you failed to mention, if that screengrab is recent, is that not only is the password visible in plaintext on the page, so is the http request containing the password...
 
+syntax-Warren Hancock - I would recommend getting into the habit of using passwordmaker.org everywhere :)

+Dan Ciliske - I was wondering about that too, but I'm not actually sure if the JS code is using SSL or not to get the data. The fact that the settings page itself is not encrypted on the wire is not a problem, on its own.
 
+Dan Boger +Dan Ciliske I'm not 100% sure because there's a lot of noise, but from my manual inspection, the password seems to be loaded via an XMLRPC call to an https endpoint, so there does seem to at least be HTTPS in use.
 
+Dan Boger If they use SSL or not to get the password is irrelevant. The fact that it is shown in plain text implies that it is not hashed in the DB and therefore stored in plain-text.
 
+Alex Egg It's more just a matter of how severe the problem is, not whether or not there's a problem.

It's the difference between "someone can sit down at your computer and steal your password" and "someone can steal your password without you ever seeing them".
 
+Alex Egg, yes, I know -- was commenting if there are N+1 problems here, not arguing about the first N.
 
Alex, it doesn't imply that's it's stored in the db in plain text, it just proves they aren't using one way hashing; they could easily encrypt for storage just like you would a credit card.  In any case, it's stupid to not one way hash the password.  No service should ever be able to show you your password through any means, only let you reset it to a new one.
 
Not sure what's worse: the fact that you were listening to Lady Gaga or Pandora's security (or lack of thereof).
 
I don't use Pandora, but now I wonder how Last.fm's security compares
 
To give credit due (coworker said this), the page is also HTTP, which means someone can inject javascript in the http page to get the password out of your field when its loaded via XMPRPC.

Thus, a remote attacker still can access/compromise your password.
 
Wouldn't there need to be another, different, bug to get arbitrary JS injected?
 
Even with a MTM? its in plain http so you can inject anything you want in the page.

Let's say a wifi cafe?
 
Somewhere upstream could inject contents (due to lack of signing) - e.g. the owner of the wireless network.
 
HTTP transport attack.  If they control the network they can inject arbitrary stuff into the HTTP requests.  But an XSS or MITM type attack would still be needed to complete it.
 
Nope... if you're man in the middling someone, you can inject/arbitrarily change the content the victim sees.  This can be finicky to pull off over unencrypted wifi but certainly possible.
 
I like to open Pandora's password box and peak inside. You ruined my fun! Thanks!
 
Wow!  I truly can NOT believe this!  I just checked and sure enough, the password is clearly stored as the text box's value.
 
P.S.  You really should use a different password for every site anyway!  Check out Keepass (http://keepass.info/) to help you manage your passwords securely.  It's free and open source.
 
yep.  What's more amazing is how many web site owners seem offended when you tell them about their security holes.  I once sent a screen shot to an ecommerce site's contact email showing how simple web debugging tools allowed me to fill my shopping cart for $1.  They accused me of being a hacker.  :-(  Hopefully they check every PO.
 
Ugh.. thanks for bringing this to attention. I just changed my password.

How are major sites still this bad with basic security stuff like this?
 
I use lastpass. Your article means nothing to me. 
Kenji S
+
1
2
1
 
Yikes. This seems like a stupidly glaring security hole...
 
@Doogie H
It should concern you... When you store user passwords in plain text (or in a two-encrypted manner) it is trivial for an attacker who obtains your user record from their database to gain access to your account. Now you might not think that's a big problem for a service like Pandora.. but there is quite a bit of information associated with your account that a data thief might find useful. That should concern you.
 
Wow, that's really stupid. Thanks for the heads up.
 
But that's why windows have user password for your computer :-)
 
I only use pandora on my iPhone 5
 
Thanks for the info, I got bored with Pandora
 
Who the hell cares about "hacking" your Pandora account?
 
Thanks so much! I'm changing it right now!!
 
so that's why all the playlists I have made in the past few months suddenly vanished.I thought it was a glitch, good share.
 
Yes Lady Gaga Radio!!
 
Lol so wats the worst that can happen? They will change your channel?
 
Thanks for that info!  Checked on mine and sure enough my info was there! 0.0  
 
Btw pharrell radio is the best station on pandora!
 
Come on people just put a password on you user in windows so that when you log out,or turn of your computer no one can hack you
 
Thank goodness I don't use Pandora on my PCs. LOL
 
you've heard the story about "Pandora's Box" right, nuff said!
 
When it comes to personal information, it's always important.  Even if it's just a lowly Pandora account.
 
+SiLee Yognaut yeah, but I bet a lot of people use the same password for their gmail, facebook, etc., that's the real danger
 
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?
 
Am I missing something or can't you, I don't know, log out of pandora when you leave the computer you are/were using? I agree they should handle their authorizations better but if you leave any account logged in and walk away from it...well that's worse than making your password the same as your username.
 
I can confirm that "HMAC-SHA1" appears in the javascript, though not knowing too much on AJAXy stuff, I don't know what it's for.
 
Crazy. I hope Pandora fixes this...
 
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.
 
(I am off to hack Pandora now)
 
+Christopher Smith What do you mean, might be non-existent?  A password that was stored in Pandora's servers shows up in plaintext on a client machine.  There is no other conclusion to be drawn than that it wasn't stored properly.  Unfathomably, it is also returned to the client in this form.
 
Why does anyone use Pandora anyhow? iheartradio is far better, has millions more songs is free and has no ads. Dump Pandora already.
 
+Blake Sherer The issue that was believed to exist (but may not actually exist) is that the password is stored on Pandora's server, so that if someone attacked Pandora's system and succeeded (or someone unscrupulous with access to the password database at Pandora just gave information away), they could get your password, even if you logged out.

This would be a very big problem if, for example, you used that password for other things (which one should not do, but people often do).

As a general rule, what most services store is not the password, but something which can be used to mathematically prove that the password is correct. That way your password is not at risk.

Again, I don't think this has really been proven.
 
Well ill never make a pandora account xD
 
Not hashing passwords = not caring about your users.

Plain and simple.
 
+Christopher Smith There is most definitely a security issue. The extent of it might be slightly different from what was originally thought, but the mere fact that someone can walk up to a logged-in browser and read a plaintext password is a security issue, no matter how it happens behind the scenes.

Likewise, the fact that someone can inject a script into the main Pandora page and read a plaintext password out of the DOM is similarly a significant security issue.

How passwords are stored on the server is actually secondary to these issues, despite being the most commented-on question.
 
No complicated set-ups. life is easier
 
+Christopher Smith If i'm reading this right, what you're suggesting is that Pandora is using zero knowledge authentication, correct?
 
Wow can't beleive they use clear text. Encryption is not really difficult
 
This is far from common, and is an amateur mistake.  They need to fix it.  Any site that does this should be considered amateur hour. Programmers that accept this as typical, or don't understand, should be blacklisted. 
 
+Nick Pendley Though it looks like evidence that Pandora stores passwords on their servers, it doesn't appear to actually be evidence that they do. It actually seems increasingly likely the JavaScript stores the password locally on the computer, and sends a HMAC of the password to Pandora's servers.
 
+Amber Yust I'm sorry, but no, it isn't a significant security issue that if someone can walk up to your loggin session and grab your passwords. That is a threat no matter what Pandora does. Even if Pandora never stored the password, the OS will have it in RAM for quite some time. They can also install hooks to expose any future use of any passwords quite easily. Basically, once they get a chance at your account, you are screwed.
 
It's reasons like this that I made the switch to using a password manager for every site.
 
+Dan Ciliske I'm suggesting that for all we know, they are doing the same client-side HMAC protocol that secure sites use. So, yes.
 
Saying that this means they don't care about their users is silly. Someone else got into my Pandora account once, but it was because my (non screen locked) phone was stolen. All my custom stations got replaced with tons of rap music channels. I contacted Pandora and they were able to roll back all the changes to the time I last had the phone. I figure this represents the worst case scenario for a Pandora account hack; they mess up your channels and Pandora restores them. After all, you shouldn't be sharing passwords across all your web accounts anyway. Oh, and I had a free account back when they took the time to rollback all my channel changes. Hopefully they will improve their security measures.
 
+Amber Yust The man in the middle attack could work regardless of whether they store the password, because it could inject JavaScript that did store the password.

To protect against that, they'd have to use HSTS (which isn't broadly supported) and have all traffic, all the time, use TLS. Even that wouldn't really work because most users don't check their TLS certificates, so you could just use a different certificate and perform a man in the middle attack.

If you are concerned about that, then you have a lot of sites to worry about before you worry about Pandora. I'd start with the Apple Store.
 
Look people, the fact that you can see the password says nothing about whether it is encrypted in the database, just that they are passing it un-encrypted on the wire, and visible in source.  It may be 2-way encrypted but that's not the vulnerability.  It's vulnerable otw without ssl, AND at the point of entry because it's in form. That's the point of the man in the middle attack.
 
+Christopher Smith Comparing a memory/cache-based attack (which requires significant preparation, knowledge, and tools) to a walk-up-and-select-a-menu-option attack (which requires zero preparation, next-to-no knowledge, and zero tools) is facetious at best. Security is not black and white; it is a sliding scale of grey, and this drastically reduces the effort needed to acquire a password.
 
+Brian Klippel Actually, it doesn't even mean they are passing it at all over the wire. It appears it is stored locally, and it looks like all they send is an HMAC of the password.
 
If you use a computer, you should assume that someone somewhere can and will hack it.  There, now doesn't that make you feel better?
 
+Christopher Smith To preload the form variable with it in html they pretty much have to send it over the wire. At some point it has to be decrypted for it to be visible in source. If it's being decrypted in script then all the keys to do so are accessible which is also bad. Also, the fact that it is visible in form source is just as bad regardless.  IF for any reason they felt they needed a 'has not changed' placeholder, they should have used such, but I fail to see how that is useful. I know several ways to determine a currently authenticated user without re-posting a form-state password.  This is bad form... no pun intended.
 
+Amber Yust In order to extract this password, you need to use a browser's dev tools, or the JavaScript console, and some degree of knowledge on how to use them. You also have to catch the browser while it has the password in plain text, which means you are on this page. Those same skills could be used to install a trivial bit of JavaScript to extract text from every input field marked "text" that you ever go to with your browser. If you let get to your machine while it is on this page (which again, is what is needed), I can change your password to whatever I want even without any of those skills.

Now, a more skilled person could potentially reverse engineer the JavaScript and maybe find a way to decrypt the password from encrypted form (maybe), but it'd be far easier to just get a memory dump or install a keylogger.
 
+Christopher Smith Dude, right-click "inspect form element" is not rocket science in my book. I don't care if it's just chrome, if you've been watching, that's the most used browser these days.
 
if phsycologist can read human brain, whats hard with the computer? nothing is secret.
 
+Brian Klippel First, it isn't visible in the HTML source. It is visible in the DOM. It does indeed need to be decrypted, but the password was initially typed in from the browser, and the browser can keep that information entirely locally (which is what appears to be happening) and never send it to the server. This is precisely the protocol used by secure sites everywhere.
 
+Brian Klippel I agree that "inspect form element" isn't rocket science. That's why you don't ever give someone access to your login session. That is among 100 other things that trivial which they can do to compromise your accounts & passwords. It's a basic security principle that once they have unfettered access to your desktop, it's game over.
 
+Christopher Smith

"You need to use a browser's dev tools, or the JavaScript console" - which every browser has installed and require two clicks to use to actually perform this attack. You don't even have to know what the rest of the dev tools do - all you have to know is that you can right-click on the password field and selected "inspect element" and see what value=.

"You also have to catch the browser while it has the password in plain text, which means you are on this page." - Or you can just navigate to the page. Yes, it requires the user you're attacking to be logged into Pandora, no one is disputing that. There are plenty of people who leave themselves logged into Pandora, given that it's a music streaming service.

"Those same skills could be used to install a trivial bit of JavaScript to extract text from every input field marked "text" that you ever go to with your browser." See above - it doesn't actually require knowledge of how the dev tools works to use this attack. There is a vast difference between actually writing JavaScript (not to mention making it persist across page loads) and just right-clicking a field. Furthermore, it takes 5 seconds to right-click and look at the password. It takes significantly longer for a person with anywhere near the same skills to do what you're suggesting.


Yes, if someone has physical access to your machine and knows what they're doing, it's game over. But again, security is not black and white. Just because it's possible for someone to compromise your machine doesn't mean they will, and reducing the number of trivial and obvious holes is still a useful endeavor. A significant portion of "security breaches" aren't done by skilled hackers, but instead people like a jealous ex or a not-so-nice friend.
 
+Christopher Smith - there is no way you could have the password PRELOADED in the settings page without it being stored on the server in, at the very least, reversible encryption. More likely, just unencrypted.

And that's so wrong.
 
Hell my bank does not support symbols in passwords, wtf!
 
+Christopher Smith are you saying that what we're seeing in the form field is not sent from the server, but it just a local in-memory cache of the password?  I have so far been unable to see where it is passed back from the server.  That is admittedly less significant than the passwords being unhashed -- but I still can't figure out why it is even being stored -- why (and how) is this loaded into the DOM?
 
+Christopher Smith OK, I'll give you that it's not in view source.  But that still means it is decrypted in non SSL script somehow, and it does not excuse it. It is still a different page - not a 'stored password' from the browser, displayed in the dom of their account page.  I just tested it.  It's a clean load page that has my password.  I don't know if it's OTW yet, but its still very vulnerable.  That field should be blank, and seeded from an encrypted cookie upon re-post.
 
I bought an iPad from my friend. He wiped it before I got it. I restored it, installed software, etc. When I opened Pandora, I was logged in as my friends daughter. How is that possible??
Ellie P
 
Idk but on my phone I have my dads contacts
 
You'd think after the number of high-profile password leaks large tech companies would learn.
Is it really that hard to write sha1($password . $salt)?
 
+Rob Pungello Actually, you really shouldn't use SHA1 for passwords. Take a gander at the blog post linked in the OP.
 
+Nick Pendley I'm saying precisely that.

Traditional HTTP authentication actually does the same thing, so they are in good company here.

Why do it? It doesn't change the security risks and it allows a user to edit their password. Anyone who is using a password manager effectively has this issue (Apple's Keychain, any of the browser password managers, etc.). I wouldn't do it, and I'd not like my bank to do it, but the risk here is blown way out of proportion. We've gone from a password exposed on the server to a remote attack from any location in the world at any time, to a password exposed to someone who has access to the desktop while you are logged in to the service.
 
+Amber Yust I know, but it's a lot better than storing things in plaintext, and as an example it gets my point across.
 
+Brian Klippel It is seeded from encrypted local HTML5 storage, which is roughly the same as seeding it from an encrypted cookie... except that an encrypted cookie is sent over the wire to the server, which actually makes it a bigger security risk.
 
what are the real concerns here identity theft,escrow,private accounts
you don't want your wife/partner knowing about if your using linux and
some mac you don't have to worry about what?
 
+Christopher Smith I agree that a local cache is remarkably less significant than the server returning a password in plaintext.  

I'm still unclear on how the password is getting stored across the pageloads, but I definitely don't see how this entry in the DOM is what "allows a user to edit their password."  Certainly the server doesn't have to place a password in the DOM to allow a password to be changed.

I also disagree with your assertion that this is as secure as a user choosing to store credentials in a password manager.  Surely the vulnerability is larger for a secondary attack to expose the password from the DOM.
 
Raise your hand if you use the same password across multiple sites
 
+Jon Davis - I'm sure no one ever uses the same password for multiple sites. I mean, that would just be an utterly silly thing to do, right?
 
well i mean i do...the same password for all sites really. or at least the same one that altrnates between 3 others....if this makes any sence
 
+Brian Klippel "That field should be blank, and seeded from an encrypted cookie upon re-post."  Why does it need to be populated with anything?
 
+Amber Yust If you can install a browser extension, you can compromise a browser's security, thoroughly. Don't let people have that kind of access to your system.

There are tons of web sites that put your password at risk in a fashion similar to Pandora. There are tons of pieces of software that put your password at risk in the same fashion: we call them password managers.

Basically this extra security risk is that, if you are logged in to Pandora and leave someone alone with your computer, they could either change your password or extract it using an additional method that is quite trivial. The "change your password" aspect is plainly visible to the user, so this means they've already failed to logout and protect their account (and you might think they'd expect the password extraction issue as well, but maybe not). This risk already exists if you use any kind of password manager (including the ones built in to all browsers and operating systems) and haven't taken measures before walking away from your system. This risk already exists if the person has enough knowledge to install a browser extension and knows where the right ones exist. The risk already exists if the install any other malware on your system. The additional risk goes away if you just log out from Pandora before walking away, though you are still exposed to a ton of other risks.

Seriously, this is NOT a big security issue.
 
+Tom Webster If you use LastPass and you are logged in to your LastPass account and it only has your Pandora login in it, you are exactly as exposed to risk as you would be had Pandora implemented things differently. If your LastPass account also has other accounts in it, you risk additional exposure.
 
+Christopher Smith - I'm not saying that LastPass would protect you from this utter failure to implement security, I'm saying that using LastPass helps you avoid password re-use. This way, when your Pandora account is compromised, you don't compromise other accounts as well.
 
+Christopher Smith Can you point out a couple of other large, popular services with the same design of storing the password in the DOM?
 
+Christopher Smith - Hold on here.... Not a big security issue? Seriously? Storing passwords in plain text, not using one-time password reset tokens? You know, there's a reason respectable tech companies implement security the way they do. I don't believe you have any idea what you're talking about.
 
How about you just use your own pc instead of a public one...yawning right now
 
jetblue is able to email you the password. fidelity also has a retardedly easy password reset.
 
+Nick Pendley I can point you to your browser's password manager or any of the commercially available password managers (including Apple's Keychain, which they market heavily as a feature of the platform, so it must appeal to some people). Any site with a "remember my password" option likely exposes you to a larger risk, but at the very least is exposing you to the same risk. I don't remember the details of Amazon's One-Click Purchase implementation, but it likely exposes you to a similar if not greater risk, though minus the "inspect element" attack (technically it isn't your password that Amazon exposes, but a secret that can be used to trigger further purchases).
 
Just tried and verified, scary stuff
 
+Christopher Smith  Password managers are not web sites, and I specifically asked about the DOM storage.  Any cookie can be used for a session (which has its own security issues) but seeing the plaintext in the dom (instead of a session cookie) seems like a whole other level of bad.   And yes, I get what you're saying about the need for end users to act in secure fashions -- but surely those opens up new attack vectors.
 
+Tom Webster I definitely have a clue. The password isn't persisted anywhere in plain text, and doesn't appear to even be sent to Pandora's servers, let alone stored there. The browser has it in memory in plain text while you are logged in to the site, which is also the case when you type in the password for any site. The only exposure is if you give someone unrestricted access to your desktop while you are logged in to Pandora, and of course they already had the ability to change your password or install any number of bits of malware (including what would amount to the world's smallest browser extension). So no, this isn't a big deal.

Again, if you use the LastPass browser plugin that you are touting and you are logged in to it when you let someone else use your desktop, you likely have a much larger security exposure.
 
That's good to know. thanks for sharing this particular issue. 
 
Go to ANY login page on any site, open the dev tools, search for password. It should say type:password. Change password to text. Badaboom.
Its local.... gets encrypted in packets on upload if https
 
By the way... facebook is extremely well secured. Even if you are logged in, it doesn't store that string anywhere in-session
 
Why would you walk away from a computer while still logged into any account you don't want others to access? And then be surprised or upset that someone accesses your account details?
 
+Tom Webster But the only way your Pandora account can be compromised is via accessing the browser while you are logged in. If you are logged in to LastPass and someone accesses the browser, they now have access to all your non-reused passwords.

I use LastPass myself and highly recommend it to others. It is a great tool. The thing is, what Pandora has done that is getting everyone all freaked out is effectively implemented is their own version of LastPass just for their site. The "exposure" here, if you reuse passwords all over the place, is the same "exposure" you would have if you used LastPass to make all those passwords unique. So this isn't really a good example of why you should use LastPass.
 
i know whole families using same password for everything
 
@andre brutis - hilarious 
 
thanks for sharing that info
 
+Travis Lipshus: that makes it way more efficient to steal the identities of an entire family that way.  :)
 
Not saying that it's a bad idea but why specifically would you say?
 
"I only use my phone. So I'm safe". Sweet Summer Child. 
 
+Trevor Jones You might want to be careful about using whatismypass.com... it shows ads from Google by loading JavaScript in to the page over non-https. It also stores your password in JavaScript just like Pandora does, though they wipe it out after 60 seconds, which is good. The site itself isn't available over https as well. That leaves you with two pretty huge exposures, not to mention a problem not all that different from Pandora's.
 
Thank you my friend for this information
 
Yes, because hackers, moreover those capable of man-in-the-middle attacks, will utilize their skills to take over your Pandora account and create endless playlists of Michael Bolton and Seal. Oh the horror!
 
Thanks for this. Good to know.
 
+Greg Davis You're right, there isn't much concern with Pandora alone. The bigger issue is that many people use the same password for Pandora as they use for everything else (despite the massive number of hacks/attacks there have been on several different sites).
 
+Tony Thompson It's a password that you don't use for anything else (or for some people, a password that they only use for things they don't care about). The idea being that it would have minimal effect if someone were to discover it (unlike, say, sharing a password with your email account).
 
+Amber Yust Oh! I didn't realize they had that online version available! Although one difference that I do see is the profiles are not available everywhere, they're tied to the machine that you create them on if I'm not mistaken.

+Christopher Smith I agree about the non-https issue is certainly a point of concern, albeit the same issue is shared by the online version of passwordmaker.org. I don't know what you mean about it storing your password like pandora does though. Pandora stores the passwords plaintext without hashing in the database, making them recoverable from the database, which whatismypass.com does not. Also the password generator doesn't send any form data to the server to be stored, all password generation is done in javascript. You can confirm it by using the generator after disabling your internet.
 
Wow...who are u guys...all of you get a round of applause.....really...
 
+Trevor Jones This is the part I think you aren't getting: Pandora does not, in fact, store the passwords without hashes in their database. In fact, they don't even send the password to their servers (just like whatismypass.com). What everyone is freaking out about is that it is stored in the browser's memory, which whatismypass.com does as well.

Pandora does appear to store an encrypted version of the password in local storage, which is different from whatismypass.com. They also don't time limit the password like whatismypass.com. This isn't what people are concerned about.
 
+Christian Orpinell You probably don't have to change all of your passwords. Just change your Pandora one to something that isn't shared with other sites.
 
+Christopher Smith I see where I was confused...(read: didn't read 'Edit 4'). But I will contend that the comparison you're making is slightly incorrect. With pandora the specific issue involving the browser side storage revolves around the password of the logged account being stored in the browser and thus made available by simply reading the dom of the settings page (It isn't clear to me from the post if this is using html5 local storage, cookie, or session variable)

With this in mind, the following scenario is possible: Alice leaves machine unattended while logged into pandora, Eve accesses machine and navigates to the settings page and recovers the revealed password. 

Now consider whatismypass.com in the same scenario, Alice logs into whatismypass.com, then leaves the machine unattended. Eve accesses the machine but unlike with pandora, navigating to the account settings page for the user does not reveal the password in the dom, nor is the password of the account stored on the local machine, the account password is only stored in a hashed format on the server side. (This is simply meant to highlight the difference between the two issues and why they are not in fact the same, not ignore that the site still is vulnerable to a man in the middle. Hopefully the developers will be willing/able resolve that issue)
 
If its not https then don't use the same password for your email or other sites.
 
Way to much thought being put to this!!! Dump that outdated Pandora!!!
 
Psh, actually very common. Sadly I constantly do exactly this in order to retrieve my ISP password off my router login page.
 
What are people going too do steal music you don't own!!!!!
 
Thanks for heads, but now more people are aware of how to get into other people's accounts
 
But who cares about someone else's pandora password....i think you should worry about sites like boa and those are hashed ssl
Neha Pd
+
2
3
2
 
Din't even know that there existed something called "Pandora" till now.
 
+Trevor Jones To simplify what I am getting at. Get a password for a site with WhatIsMyPass. Pretend you walked away quickly and someone then walked up to your computer. They open up the JavaScript console and type in: "document.getElementById('password').value"

They get your password. It is stored in the DOM as plaintext. That's why the "Show/Hide" button works. That's why copy & paste works. They wisely timeout the value and clear the field, which does improve the security, but you could accomplish much the same thing simply by having a screen lock timer.
 
This is valid for every site that supports the browser password saving. I.e. you can type 
console.log(document.getElementById('input_password').value)
in firebug console for phpMyAdmin
 
+Christopher Smith you are wrong. As my tool demonstrates, Pandora passwords can be stolen even after logging out of the site, as they are stored persistently in HTML local storage in plaintext (well, encrypted with a key that the whole world knows). This is a vulnerability that a secure site should not have.
 
I see they took my advice from an earlier comment and switched to using a placeholder... ;)
 
FAKE. Nobody listens to Lady Gaga
 
Yep, now it says "__USE_EXISTING__". And don't worry, I'm sure we can trust them to have stopped storing plaintext passwords in the DB...
 
Very edifying discussion! Thanks to Amber, Christopher, Marc, Trevor et al. for being so generous with your knowledge, so thorough in your comments and so civil in polemics.
 
I think it's pretty definite that they're storing the passwords in plaintext on the server-side. (Or at best they're using two-way encryption, which is little better.) I was able to see my password in FireBug on a new computer and after clearing cookies and local databases. I haven't used Pandora in a long time, so I can't see any other way they could have stored the password locally.

Edit: Well, I suppose they could use JS to capture it at login and store it locally?
 
+Marc Bevand your decryption tool does not argue against +Christopher Smith's point, which is that there isn't evidence that Pandora stores your password in plain-text serverside. Those entries in the local storage are (necessarily) populated client-side.
Add a comment...