Pandora doesn't hash their passwords | Hacker News Reader

Pandora doesn't hash their passwords

plus.google.com

209 pointsaiiane150 comments

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.

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.

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

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

My reply to that argument here: http://hackerne.ws/item?id=4551852

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

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.

> But don't tell me Pandora is responsible for the total security of every moron on the internet, either.

Real security needs to work, even without the education and cooperation of "every moron on the internet" or it isn't going to work. Implementing systems that don't work in the face of this is just failing, then pointing fingers.

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.

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.

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

#1 - yes, which is also a problem! But is actually less serious, because that doesn't give you knowledge of the old password which could be shared with another site. (Obviously in the ideal case it wouldn't be, but let's face it, it is for the vast majority of users.)

#2 - which is something that browser vendors are working to address (e.g. by displaying non-ascii characters in slightly different ways, e.g. punycode, and by blacklisting domains used for phishing, etc).

#1: It might be a problem, but it is also a clear indication to even a naive user that if they leave their browser logged in to Pandora, their account be compromised.

#2: Right. So there is a possibility that some day in the future, if you are really careful and check your TLS certificate every time you do something with your password, Pandora will be exposing you to a huge gaping hole, that you would otherwise only be exposed to if you used the Apple Store, Amazon, Ebay....

The gist of your argument appears to be "you'll never be perfectly secure, so there's no reason to try to improve things incrementally".

No, the gist of my argument is that this isn't an additional security risk. Worrying about this is tantamount to looking at the lock on your front door, which itself is made out of plywood with a hollow center, and of course is attached to a house with several standard windows, not to mention sliding glass doors, one of which you tend to leave open all the time --and then screaming, "OH MY GOD I CAN'T BELIEVE THEY DID THIS! THIS LOCK COULD BE CRACKED BY A GUY WITH A HAND SAW IN 5 MINUTES!!! THEY REALLY SHOULD GET A STRONGER LOCK!"

#1: How many times is too much when replying with #1 and #2?

#2: Answer: this many times.

So anyway, everyone change your Pandora password and be done with it. You can't buy anything with a Pandora account except to be able to listen to Pandora. That is not worth stealing, even if it is a great service. I pay for it, and I'm not going to stop because of Apple. They may have the library, but they don't have the years of experience that Pandora has in its market. I do think Apple will own the high-end home entertainment market eventually.

#!: 42. The answer is always 42.

Bring your towel much? ;)

Not to step into your flamefest, but point #2 is already solved by using TACK (https://news.ycombinator.com/item?id=4010711) and Chrome has other partial workarounds in production.

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.

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

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?

The attribute name may be obfuscated, but it appears to be always the same (at least in my browsers): bc673ea54a2b7153aaafbf178e9b0892e1f2e56be5aaa5a7

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

An attacker would just grab ALL keys, decrypt them, and look at those of the form Uxxxxxxx.Password.

> First, this is indeed obfuscation. There undoubtedly is a constant key...It's certainly miles beyond what most other sites use

The state of typical security in software projects of the 1990's: sad, sad... Any improvement in 2012: such a piddling little improvement. The trend is clear as is the conclusion: the average dev can't be trusted to do security. It doesn't work!

There isn't much more you can do with the key names really. The issue with them using a static key for encrypting the local password is another thing...

> The issue with them using a static key for encrypting the local password is another thing

Actually, it is the thing that I was referring to. Doing things with the key names is another thing -- wily and probably benefits them a little, but it isn't real security.

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: "xxx@xxx.com"
  Uxxxxxxxxx.Password: "myCleartextPassword"
  hasLoggedIn: true

  (xxxxxxxxx) is the numeric Pandora user ID.

I will publish an tool for decryption as a proof-of-concept, in the next hour.

What were Pandora's developers thinking? This is not a huge flaw, but they should certainly not store sensitive data like the user's password in the local storage.

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

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.

Done:

Pandorhack: Stealing Pandora Passwords http://news.ycombinator.com/item?id=4553184

Very well done.

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.

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.

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

My jaw dropped. How does such a publicly visible website think it is okay to show users their password without them asking?

It should now be assumed that every hacker on the planet knows about this vulnerability, and Pandora will see attacks against their database very soon. What we don't know is if Pandora is storing users' passwords in plaintext. It is possible that Pandora remembers your password server-side for your session. I hope that this is the case. If it turns out to be anything else--plaintext passwords in database, etc.--then Pandora is worse than LinkedIn.

What kind of profitable attacks could one perform with a large collection of Pandora passwords? The best I can think of is for a small band to have millions of people "like" them.

Many users reuse passwords across their web presence.

So there's the chance of gaining access to other accounts as a result of the data leak... such as their bank accounts, etc.

People typically use variants of the same password across the web. It's a huge starting place for breaking into an email account.

Also, since it's vanilla http, you could sniff these passwords at a coffee shop's wifi all day and just wait for someone to log in to Pandora.

Simple, for every user that the hackers have, try their password for the associated email account, guaranteed they will gain access to many email accounts. Now they have access to their banking accounts.

This could happen, but do we have any evidence that it has? I'm being serious...I constantly hear about widespread leaks of passwords, but the most I hear about it is people having their email hacked by a botnet to...send spam. Have their been any large scale attacks to gain access to bank accounts to then clean them out somehow?

On top of that, how does getting access to someone's bank account even help you? You have to transfer the money to another account, which leaves a trail...

Robbing a convenience store at gunpoint or illegally downloading torrents usually also "leave a trail." That doesn't mean nobody is willing to do it, and I definitely wouldn't feel safe if random people had access to my bank account just because if they did anything law enforcement might be able to catch them.

I'm sorry please be clear: is your response to "this is a well-known security problem with easy-to-implement best practices to lower chances of incident" really "I've never heard of an attack using this"?

Yes. One of our clients had their ETrade account compromised after a Yahoo password leak. (We had helped them change passwords on all their other services and recover the data deleted from their Yahoo account, but they forgot they had an ETrade account.)

In that case, E*Trade detected the activity as fraudulent, so the damage was minimal.

> This could happen, but do we have any evidence that it has? I'm being serious...I constantly hear about widespread leaks of passwords, but the most I hear about it is people having their email hacked by a botnet to...send spam.

The more password databases are hacked, the better password cracking becomes, and the more sites black hats get access to. It's a vicious cycle. Yes, people sometimes do get large amounts withdrawn from bank accounts.

This. For more information on why this is the case, here's a pretty good article on it.

http://arstechnica.com/security/2012/08/passwords-under-assa...

The simplified version: Every time a password is cracked it is added to a database of hashes used to hack other databases. Essentially crowdsourced cracking.

That only works on broken sites that don't salt.

If I was to try to break salted passwords, my first inclination would be to find the largest set of known passwords and try those before resolving to a pure brute-force approach. Thus if you password "ILikePuppies" is ever exposed as a password, then I would consider it insecure.

Not as rare as you might believe.

http://www.theregister.co.uk/2012/06/07/linkedin_admits_data...

Even if they are just using saving it in session they aren't using https

That makes it even worse then. Every Pandora user connected via WiFi is at risk. I wonder if Pandora is usable in airports?

It has to be plaintext in the db, because they can't reverse the hash back to plaintext to send to you.

Not quite true. It could be (and probably is) encrypted in the database.

That doesn't make sense. Three days after you sign-up (i.e. no cache), if they are sending you your password, it can only be because it's plaintext. Unless they are bruteforcing the hash for your convenience... :-)

They could two-way encrypt which seems safer to me than plain text but some disagree (I'm not sure why).

Only if the keys are well controlled.

If the keys were well controlled, you wouldn't have to worry about plaintext passwords in the DB either. But passwords get leaked all the time. If the key is sitting somewhere locally, when they break in to steal the passwords, they can steal the key too. There's no way the program can reverse the password without having the key pretty easily accessible.

Can you elaborate? I don't know any way to take a hashed password and get the plaintext version. When you log into any app i've worked on, we hash the pw you send and match it with the one in the db. This is why you have to get a password reset most of the time, because the company literally does not know your password.

A cryptographic hash is one-directional (among other things).

However, encryption is the the same as hashing, and it can be decrypted. It is possible that they are not hashing your password, but encrypting it, before they put it into the database.

Encrypted, not hashed. As in, encrypted with a key that can be used to then decrypt it later.

I haven't seen where it pulls the password from, but in theory it could pull it local session cookie.

Actually, technically it doesn't have to be in the database at all. I don't know if anyone has looked carefully at the JavaScript, but it appears the password, unlike everything else, is populated from client side JavaScript. It could be stored in a cookie or HTML5 local store or any number of other ephemeral client side storage tricks. It would be set when you login, from your browser. The server might only store an HMAC.

Thoughts? https://news.ycombinator.com/item?id=3798597

Proof that 99% of generating good conversation on HN comes from a well-phrased title.

No, most of it is timing and simple luck. If you hit the right time of the day (when there are a lot of users present but not a ton of news) and get the first few votes in a good time (which is mostly luck), you'll make the front page.

Actually, proof that a provocative but false headline on HN will still get the sheep to vote up your article. ;-)

For the record, the title was actually edited from what I submitted it as.

...and it is still wrong. They do hash their passwords.

Encryption is not the same as hashing.

That said, when I said the title was edited, I was not referring to myself editing it.

> Encryption is not the same as hashing.

UPDATE: http://news.ycombinator.com/item?id=4552358

If mrb is right, it looks like they are storing it locally without encryption, which is indeed bad.

What I had written before seeing that:

======================================

Yes it is not. As a consequence, they are not mutually exclusive.

The title would be correct if it said, "Pandora stores encrypted passwords locally". Guess how much less interesting your post would be with that title? ;-)

They hash their passwords. They encrypt their passwords.

I'd prefer they only did the former, but the fact that they do the former at all is NOT what most people commenting on this thread understand.

Over 100 days ago... Now I'm outraged that the HN community didn't notice this before! xD

I actually found this a couple weeks ago when I was getting ideas on what they store as their as most likes (like rdio) just use value="password".

I wish someone would make a one-pager that says:

"Hey CEO, your site doesn't hash passwords. Here's why it's bad. Here's how it got other companies in hot water. Here's how simple it is to fix. Forward this to your tech guy. Oh, and until you do, we'll put your company on this wall of shame."

Every time I receive a welcome email showing my password in plain-text, I'd gladly spend 5 minutes finding the email of an exec, or simply sending the link to support. Why? If the service is valuable to me, it's probably worth 5 minutes to protect my account and others'.

Would pair up with someone here if you want to knock it out.

Someone shouldn't do that, because a) though the poster thinks they have proof that the site doesn't hash passwords, it increasingly seems like they do, and b) the CEO isn't the person to send this to anyway.

I disagree from personal experience. On (a) if you receive an email confirming your registration that displays your password, I guess it could be hashed later but probably wasn't, right? And (b), this happened with my city's utility bill service (has a lot of my personal info) and an email to the mayor's office got it addressed. My larger point is that telling a non-technical higher-up can go a long way for things where customer service may not see the bigger problem.

I agree that if you get the password in an e-mail plain text, there could be an issue... unless your e-mail client is rendering that section using a browser... which happens to have an encrypted version of the password stored locally.

However, in Pandora's case, this isn't what is happening, and it appears they've taken pretty extensive security measures given their constraints.

Telling a non-technical higher-up there is a problem, is also a good way to get a technical person in to trouble. If it is merited, no problem, but if you are wrong, you've just rewarded good work with a load of crap. It is much more appropriate to follow up with the appropriate party and at least give them a chance to respond before sounding the klaxon.

Good points.

I've done this a couple of times too and usually it does get fixed in a week!

This is very bad from a security standpoint but you'd be surprised how many websites do this.

Here is a list http://plaintextoffenders.com/

I would have expected Pandora to know better. Anytime a website shows you your password or emails it to you, it's a bad sign. It means it is stored in plain text.

The websites that do it right cannot tell you your password (because they don't know it); they can only let you reset it.

> Anytime a website shows you your password or emails it to you, it's a bad sign. It means it is stored in plain text.

No it doesn't. They could be using the strongest encryption known to man and still show you your password or e-mail it to you by simply decrypting it when needed.

And then someone looks at your screen and takes your account.

Which is almost as bad. A service provider does not need to know your password, just a salted hash of it.

It's true that he worded it badly, but symmetrically encrypted passwords are no safer than plaintext in practical use.

Encrypted passwords are functionally equivalent to "stored in plain text".

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 faith they are doing anything correctly WRT security.

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.

Basically, encryption allows you to expose data to the public without disclosing its contents by keeping another, usually much smaller, piece of data private (the key).

In this case, your passwords should be private to begin with. If they are accidentally exposed, it's likely that the key is also exposed, so you gain little. You can't hide the key because you need to use it to e.g. authenticate people logging in.

It's a bit like a business keeping all of their cash in a safe to protect it, but because they have so many people who need to access the safe, they basically have to write the combination on the door.

Hashing passwords is like a sealed black box where you can go up to it and say, "Bob is here and claims his password is X, is that right?" and the box will give you a yes or no, but it's extremely difficult to crack it open and get at the actual passwords. Much more secure than the safe, which really does little in this case.

Since they key is almost definitely not stored in the db and is very likely stored fairly securely, why does it follow that "if [passwords] are accidentally exposed, it's likely the key is also exposed"?

I understand that passwords are better hashed I just don't nderstand why encrypted is no better than plain text (according to some).

How do you store the key more securely than the database while still allowing your web apps to access the key whenever they need to verify or change someone's password?

Well, it's common to have db but not file system or codebase access. And it's easy to make a directory readable by only the app.

Encryption is a method of converting a plaintext secrecy problem into a key distribution problem.

This is a case where you can't have your ciphertext and decrypt it too. If you encrypt the user's password, you can't store the decryption key in the same place.

Well, you can, but it's just pushing the problem around with no security benefit.

or by sending you the email while it's still stored in memory from you signing up

Confirmed. No asterisks.

http://bash.org/?244321 ... classic :)

Is there a need for the password to even be printed there? Usually the flow for changing the password is inputting the current password, then typing the new password twice.

Exactly. That brings up another bonehead move by Pandora - if you've made it here on someone else's account (presumably they left it logged in), you can change their password without knowing their password (ignoring the fact that you can already get their password from the DOM).

But I guess that's a minor issue compared to exposing your password. Either way, the whole programming dept. at Pandora needs a lesson in passwords.

Nope! They're just bad at their jobs.

Why are people still relying on developers to implement proper password security instead of using unique passwords?

I fail to see the tragedy, too. Every service should have an unique password. Also even if the password are hashed, if hackers get control of the web server, they could sniff the passwords when users log in.

Why are we still relying on passwords rather than a secure PKI key-based access method in which unique keys are generated for each remote system accessed?

There's the possibility of authenticating with a SSL certificate. Fedora uses this method for a web service.

There is also OpenID, but not many sites are using it unfortunately.

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

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?

Found a workaround. You can still get to the login page: http://pandora.com/login

From there you can say you have forgot your password: http://www.pandora.com/forgot.vm?target=

Completing this form sends a forgotten password email to your registered email address.

That link provided allows to you reset your password.

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 actually seeing this after they've patched the issue?

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.

Yes, they patched it within the past few hours.

This is terrible. No site has any business "knowing" my password. To me, not hashing is a violation of my trust right there. I'm a paid Pandora user and have been their evangelist for many years and supporter through all their tough times. Just seeing my password in plain text in the DOM Inspector makes me embarrassed. This should have never happened. They should fix this. Soon.

I don't get why people don't do this. It's not that hard. The modification would be about 2 lines of code. If you're unhappy about storing 128 bits for everyone's password you could even just take an 8 character substring of the hash or something. It would be a lot better than nothing.

Eek, nothing more frightening than seeing my own password there in the plaintext of the HTML...

It's not in the plaintext of the HTML. It's in the DOM. You know, the think that you can hook in to capture your password when you type it in...

This is very shocking.

It's just ASTOUNDING to me that in the year 2012 — one of the largest and most well-known companies on the internet (listed on NYSE, Alexa Rank 306, $100 Billion+ in revenue) could allow such a stupid vulnerability to persist.

Not to say it's excusable by any stretch, but their revenue in 2011 was roughly $138 million, not billion.

argh, obviously you're right – this is the second time i've done something like this today, I need definitely need more sleep

What.The.Hell?

You would figure companies out there would have learned a lesson or two by now.

Wow.

To me the funniest thing is that they rely on the 'password' input type to obfuscate the password. If you change it to 'text' its just a plain text password sitting there. So... somebody thought, "well we're going to have the password here, better make this input 'password' so people can't just see it over your shoulder, it's private!"

It also seems the password is being passed in the clear...

Can't help but notice that its a google+ user, that happens to work at google. Must be some strong kool-aid over there in Mountain View.

Neither does Hover, still, despite being outed here nearly 18 months ago and assurances by a Hover rep that they were working on tightening security and would have it completed by September (2011).

Some companies just do not give a shit about (your) security,

Okay, I have to take this back. It looks like they did finally implement this sometime between now and June (when I last checked). Better late than never.

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?

It's the job of the web developer to do everything within their control to protect a user. There is no excuse for not hashing/salting passwords.

It's a radio station. I would never expect a web developer to do 'everything within their control' to secure it. Not even banks do that.

Honestly, what are you worried about? So they have your plaintext password. You didn't reuse it for any other service, right? So what use is it to anybody other than logging into your Pandora account and fucking with your stations? (And why the hell would anyone do that?)

People need to be more realistic about security.

Which would be a reasonable argument except that hashing passwords is effortless in terms of development.

The cost/benefit of implementing this functionality makes it a rule of thumb for front facing web pages.

Of course it's easy. You won't necessarily do it right, but you can sure get a crappy version working quickly.

Assuming every web developer implemented a crappy password hash and then checked off the 'security' box on their compliance form. Are users more secure? No, because they didn't consider exactly how secure it needed to be.

Are you using a sha1 hash? Great. Is it salted? Oh shit, forgot that, let's salt it. Ok, now I just cracked it. Oh shit, let's use pbkdf2. Uh oh, it's cpu expensive and not very strong, let's use bcrypt. Shit, it's easy to crack with a big FPGA array, let's use scrypt. Shit, now it can be used for replay attacks, let's add a MAC. Password hashing is easy, right?

Europeans have chip-and-pin credit/debit cards. Are they more secure than Americans without chips in the cards? Yes. They probably feel they're more secure. Yet it's been known for a decade that you can intercept the communication, and millions of dollars/euros have been lost because customers and companies believed in the blind faith of their perceived security.

  "oh, i have an anti-virus, i'm secure now."
  "oh, i have a vpn, i'm secure now."
  "oh, i have tls, i'm secure now."
  "oh, i have a password hash, i'm secure now."

I'm not saying you should not apply strong password hashes. I'm saying there is a time and a place to be outraged about a lack of security practices. If you knew how incredibly, horribly, terribly insecure the world around you is, the world that matters, you wouldn't care about your Pandora password either.

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 this and never slip.

Except, oh wait, even people on HN don't always follow best practices because they can be fucking hard sometimes. And that's before we get into the support email I got from a 90-year old user that consisted entirely of the subject line "WHAT IS PASSWORD".

I will guarantee you that somebody with access to every Pandora user's username and password will be able to access multiple bank accounts (or worse) within a short time period even though Pandora itself is a key example of a minimum-damages service.

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, or an insider, or a man in the middle. If all their 100 accounts are the same creds, it only takes one time and they're fucked.

It is completely impossible to have perfect security on all these accounts. It is inevitable that one will get cracked. At that point, blaming anyone but the user is lunacy.

> Assuming every single one of their accounts, all the same credentials, had perfectly implemented password hashing, this might make sense.

It is Pandora's ethical duty to do their part. And it is the ethical duty of other sites to do their part.

It is the user's duty to do their part.

Any one of these parties slacking does not excuse slacking on the part of others.

This is not a perfect world. We all know there are people who use the same password everywhere. Since we know that, it is our responsibility to do our part.

This is exactly what I meant when I said: "everything within their control to protect a user".

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.

Anyone capable of keeping my credit card details secure would know better than doing this. If the blueprint is in crayon, there's no reason to check whether the building would resist earthquakes.

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.

This is an incredibly dangerous assumption. It implies they're doing credit card security right just because they put a crypt() call in their code.

Always assume they're doing it wrong, because usually they are.

I'm not suggesting that implication. The implication is that when you know someplace seriously botched security in one area, you should assume all their security is suspect.

The default most of us have to use is to assume when we use websites is that they are doing things right, so seeing no problem in one area (login passwords) doesn't change anything about our confidence in the rest of the site (credit cards). It stays at default.

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

Reply on news.ycombinator.com