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