While sending passwords in plain text via e-mail is something that should be frowned upon, the e-mail itself is not evidence that they store your password in plain text.
Everyone here implies that passwords are stored in just another table of the database. There are other more sensible scenarios. For exmaple: authentication servers which talk to the front end using CHAP, well behind internal firewalls and with dedicated hardware which holds the private keys and encrypts/decrypts the data.
This has been discussed before. The ability to recover passwords has bussiness value, so at the end its a tradeoff between risk and money.
if your application can access the password, there is a very high chance so can somebody that has application level access to your machine can just do whatever your application does, you cannot hand wave that away with "smart cards", "encryption" and "firewalls".
Having a stored password in any format except for one way hashing is a massive and _unnecessary_ liability.
Before you take the time to reply with another convoluted shell game of keep the password away from the hacker, consider the actual necessity and value of a recoverable password. Does it really outweigh the massive security problems?
Anyone that has application level access to your servers can still get your password very easily, for example every time you log in. Why is having a means to decrypt the password so much worse?
You misunderstand the point of password hashing, it is not about preventing people from breaking into the machine containing the hashes, it is about limiting the damage they can do with millions of passwords as a result of doing so. Most people do not bother to change their password from service to service, login to login. So instead of a breech on one system, you potentially have a breech on thousands.
In most cases, anyone that has application level access can already do the things an ordinary user needs authentication for. The password is irrelevant, unless you want to find it out to access another system you don't already have permissions for.
You say it's _unnecessary_ and "there's high chance of someone accessing the password". Under that premises, obviously, it's foolish not to use one-way hashing. Mine is that may provide value and there are sensible ways of mitigating the risk, miles away from accessing the data directly from your application, by using software and hardware designed and implemented by security professionals. That's all.
The problem is, the application fundamentally HAS to be able to access the password, either through direct comparison to authenticate, or some mechanism to mail out the password. This fundamentally cannot be separated, that's why hashing is always better, and why the risks are nearly impossible to meaningfully mitigate.
How does that statement hold true? I can easily think of an application that just uses a simple service on a separate box behind a firewall that only accepts an email and then sends the password. Authentication works via CHAP or any other auth protocol. The application itself never has access to the plaintext password.
Granted, an attacker may gain access to the app-server and then proceed to crack the authentication server, but he could also just rig the application to pass on any password it receives. Just about as good as cracking the auth server and far easier to do. (Added bonus: works for hashed passwords just as well).
Granted, this may seem tons of work for a simple solution, but from there on, it's a business decision.