
Pandora doesn't hash their passwords - aiiane
https://plus.google.com/116797686750161798768/posts/NGV5xQwJywf
======
cbsmith
There may be a security issue here, but I think there is a distinct
possibility that it certainly isn't what people think. Pandora needn't store
the password on their servers. Just posted this to the Google+ thread:

Okay, I just did a simple test of what happens when I change my Pandora
password. There is a record of HTML local storage keyed on "jStorage" which
appears to be a giant JSON blob. A specific attribute whose name appears to be
a randomly generated (encrypted) is updated.

Assuming that is password, stored encrypted, the exposure here may not be what
people think. It certainly would mean the password need not be stored at all
on Pandora's server. They could just have an HMAC. The password value could be
simple extracted from local storage. Has anyone checked to see if this is the
case?﻿

 _Follow up_ : Okay, I further confirmed that if I set the password back to a
prior value, that field in jStorage flips back to the prior value. So, it
looks like it is stored encrypted, locally on the system. I haven't traced
through all the JavaScript, but it seems likely that the security issue here
is different than perceived, and might even be non-existant.﻿

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

~~~
cbsmith
1) No matter _what_ they do, if someone walks up to a computer that you're
logged in to, they have a very good shot at getting your plaintext password
(there's a distinct chance it's in a memory buffer somewhere). With a minor
bit of effort, they can get access to any future password you use. This is a
basic principle of security for anything other than MAC style security systems
(and even then...)

2) I think there _is_ a very real risk there, but of course, unless they use
HSTS (and therefore always HTTPS) everywhere, there is a risk of this. Even if
they use HSTS (which isn't broadly supported in browsers yet), almost no-one
checks TLS certificates for man-in-the-middle attacks. In short: the man-in-
the-middle attack risk is always a risk unless the user takes extraordinary
efforts. They could do more to mitigate it, but it'd undoubtedly have some
seriously negative user experience consequences. It seems like a very high bar
to hold Pandora to given the nature of their service. If you _are_ going to
hold them to that standard, you might want to start with a more significant
target like say.... the Apple Store.

~~~
aiiane
Re #1: There's still a matter of degree, however - this takes zero technical
knowledge and zero external tools, works on every platform that Pandora runs
on, and requires maybe 5 seconds of time.

Re #2: Again, it's a difference of degree. Invalid TLS certs will at least
give a browser warning that a user isn't used to seeing (in modern browsers),
cluing them in that something might be up. Sure, some users might bypass it
anyway, but there's at least some tip-off. Furthermore, there's no reason why
the password needs to be in the DOM past the login page, which can easily be
served over full HTTPS with no user experience impact. Yes, that can still
fall prey to session hijacking if you don't use HTTPS for the rest of the
site, but session hijacking doesn't give you passwords that you can use to go
break into other sites.

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

~~~
aiiane
#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).

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

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

~~~
cbsmith
#!: 42. The answer is always 42.

~~~
labizaboffle
Bring your towel much? ;)

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

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

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

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

~~~
stcredzero
_> 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.

~~~
rapind
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...](http://arstechnica.com/security/2012/08/passwords-under-assault/)

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.

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

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

------
jmediast
Thoughts? <https://news.ycombinator.com/item?id=3798597>

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

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

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

~~~
cbsmith
...and it is still wrong. They _do_ hash their passwords.

~~~
aiiane
Encryption is not the same as hashing.

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

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

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

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

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

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

~~~
telecuda
Good points.

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

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

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

~~~
pbreit
Intuitively that makes no sense so I'm wondering if someone could explain?

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

~~~
icebraining
_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.

------
meritt
Confirmed. No asterisks.

<input type="password" value="hunter2">

~~~
olalonde
<http://bash.org/?244321> ... classic :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

------
biomechanica
What.The.Hell?

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

Wow.

------
RokStdy
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!"

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

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

------
bluedanieru
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,

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

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

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

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

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

