[Nicolas___]

Being able to provide you with your password in plain text doesn't mean it's stored in plain text. There are very efficient and secure encryption algorithms that are reversible, out there.

Of course, sending passwords in an unencrypted email is bad practice, but that's another story.

[rmc]

'plain text' here includes encrypted non-hashed formats. Passwords should always be stored hashed so the original site (or any attacker who gets them) can get access to the password.

And if it's possible to automatically reverse the encryption, then it's not far off plain text.

[seabee]

More specifically, it raises the bar from requiring a database dump (SQLi) to also requiring the encryption key (filesystem access or discover it yourself by cracking weak passwords).

When each line of code you write is a point of failure, I would rather trust an algorithm (e.g. bcrypt) which is immune to all of them rather than reversible encryption which needs only two.

[madflo]

If your software is able to decipher something, someone else could do the same.

[canop_fr]

Yes, because if somebody could make a select from the databases, chances are that he could also get the software used for deciphering.

[dekz]

What do you mean by secure encryption algorithms which are reversible? Encryption implies an operation in reverse order to exist, otherwise it is in essence, digesting.

It's always (almost) completely unnecessary to store encrypted passwords.

[16s]

> What do you mean by secure encryption algorithms which are reversible?

AES-256 symmetric encryption (as one example) is designed to be reversible while a SHA-512 hash is not. What does reversible mean you ask? It means that plaintext can be made into ciphertext and then back to plaintext again. It's designed to be undone/reversed by the party that holds the key/password.

[ordinary]

Reversible does not mean the same thing that symmetric does. Encryption, by definition, is reversible. If your algorithm is not symmetric, you will not be able to decrypt it with the same key as you used to encrypt it, but it would still be reversible. If it wasn't reversible, it would be data destruction (ie, Unix shred) or hashing (ie, SHA). "Reversible encryption" is a pleonasm.

[16s]

Ah... I see... pleonasm (wet water).

I believe that the parent was simply pointing out that encryption is reversible while hashes are not. This is a point of confusion for many in IT/dev.

[davidu]

While it's possible that this is true, it's still exceptionally bad practice. Reversible encryption, particularly when stored server-side, which is almost always going to be the case, and even if using a HSM, isn't entirely different from plaintext when the attacker holds the keys.