Hacker News Reader

Comment by fruchtose | Hacker News Reader

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.

View on HN

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?

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

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.

Reply on news.ycombinator.com