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.
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?
Done correctly, login is an exchange of hashes, not encrypted passwords.
A simple way to do this would be to send a unique, random salt S for every login, and the user would reply with e.g. sha1(password + S). However, to be able to check that the answer is correct, you would need to know the user's password, in plain text, which brings you back to square one.
To securely do this, you would need commutative hashing functions, i.e. hashing functions f(x) and g(x) such that f(g(x)) = g(f(x)). Actually, to be completely safe, you would need to be able to generate a whole (preferably infinite) family of commutative hash functions g(x), a random one for each login. I have no idea if such functions exist, more importantly, if they are known, it's an interesting idea actually.
Since you can't trust the server in this scenario, you can't implement in in (normal) javascript.
Because if you send back passwords in plaintext, they usually are...
Still not the best solution, hashed password (with a salt) are way more secure if your password happens to be 12345.