Pandora doesn't hash their passwords • Hacker News Board

Re: Pandora doesn't hash their passwords

#151

Post by rapind » Fri, Sep 21, 2012, 4:03 PM UTC

Evbn wrote: post #98

rapind wrote: post #85

Earlier quoted context omitted.

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.

Not as rare as you might believe.

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

Re: Pandora doesn't hash their passwords

#152

Post by cbsmith » Fri, Sep 21, 2012, 7:21 PM UTC

stcredzero wrote: post #149

cbsmith wrote: post #131

Earlier quoted context omitted.

> 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 obfusca…

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

Re: Pandora doesn't hash their passwords

#153

Post by macchina » Fri, Sep 21, 2012, 7:53 PM UTC

SystemOut wrote: post #65

macchina wrote: post #49

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

Re: Pandora doesn't hash their passwords

#154

Post by stcredzero » Fri, Sep 21, 2012, 8:27 PM UTC

cbsmith wrote: post #152

stcredzero wrote: post #149

Earlier quoted context omitted.

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

Re: Pandora doesn't hash their passwords

#155

Post by stcredzero » Fri, Sep 21, 2012, 8:56 PM UTC

peterwwillis wrote: post #150

stcredzero wrote: post #148

Earlier quoted context omitted.

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

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

Re: Pandora doesn't hash their passwords

#156

Post by bluedanieru » Sat, Sep 22, 2012, 1:48 AM UTC

bluedanieru wrote: post #67

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.

Re: Pandora doesn't hash their passwords

#157

Post by marshray » Sat, Sep 22, 2012, 5:00 AM UTC

pbreit wrote: post #63

mikeash wrote: post #46

Earlier quoted context omitted.

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

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

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.

Re: Pandora doesn't hash their passwords

#158

Post by pbreit » Sat, Sep 22, 2012, 7:20 PM UTC

mikeash wrote: post #105

pbreit wrote: post #63

Earlier quoted context omitted.

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

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'…

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

Re: Pandora doesn't hash their passwords

#159

Post by mikeash » Sat, Sep 22, 2012, 8:24 PM UTC

pbreit wrote: post #158

mikeash wrote: post #105

Earlier quoted context omitted.

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'…

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?

Re: Pandora doesn't hash their passwords

#160

Post by pbreit » Sun, Sep 23, 2012, 1:27 AM UTC

mikeash wrote: post #159

pbreit wrote: post #158

Earlier quoted context omitted.

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.