What you need to store (and compare upon login) is only a hash (a checksum), which can never be reversed back to the original password. And keep in mind:

1. Don't use MD5, it's broken. Use a STRONG hashing function, like Sha-512 or Whirlpool. There's absolutely NO reason to use anything less.
   
   
2. Don't hash just the password, hash the password plus a long 'salt' string. Appending 50 random alphanumeric chars will do (you'd need to store the salt string separately, of course). This protects against rainbow tables and brute force attacks on short passwords.
   
   
3. Make sure the salt string is different and unique for every account. This kind of 'user-specific salt' is sometimes called 'pepper'. Including the account's ID or creation timestamp (or anything that is unique for the account and doesn't change) to accomplish this is OK. This protects against detecting if two users happen to have the same password, and limits brute force attacks to single accounts only (as opposed to all accounts at once).

Email is being transmitted (and usually stored) in PLAINTEXT, and therefore EVIL. This wouldn't even be possible in the first place if you sticked to rule #1, but even just mailing the password in a confirmation email (directly after creating a user account, without saving the password yourself) is FORBIDDEN.

And your 'I forgot my password' feature should not email a new password, but a time limited link through which the user can submit a new password themselves, once.

User input is ANYTHING that directly or indirectly originates from outside your server. Get and Post variables, uploaded files, external files, remote scripts, form input, email, cookies, session IDs, browser agent strings, HTTP requests, URI formats, referrer URLs, ANYTHING.

This also implies that JavaScript, which runs client side, by definition can NOT secure anything. Using JavaScript to avoid illegal or invalid input is merely a user-friendly feature that helps them entering correct input. It does NOT avoid illegal or invalid input to be submitted, in any way. Anyone can override your script and submit whatever he/she/it (in case of bots) likes.

Therefore:

1. Before putting user input in MySQL queries, ALWAYS ESCAPE it. This protects against SQL injections.
   
   
2. Before putting user input in HTML output, ALWAYS CONVERT control chars to HTML entities. This protects against cross-site scripting (XSS) or messing up your output with custom HTML.
   
   
3. Before putting user input in command line arguments or shell input, ALWAYS ESCAPE it. This prevents custom commands from getting inserted, and your server from being hacked.
   
   
4. Before including user input in filenames or URLs (for example if 'yourcms.php?page=something' includes 'something.php'), ALWAYS VERIFY and make 100% sure it's actually valid and allowed. Compare it against a whitelist. This protects against accessing stuff you don't want people to access (e.g. what happens if some smartass changes the URL to 'yourcms.php?page=../admin/index' ?) or even publishing custom pages on your website.
   
   
5. Same for selecting tables or columns in databases based on user input (for example, a combobox called 'Search what?' with column IDs as options: 'firstname', 'lastname', 'email' etc). Again, compare against a whitelist to exclusively allow table or column names that you explicitly defined server side.
   
   
6. NEVER trust on checks that occur client side (such as JavaScript). Check, verify, sanitize, filter, strip, escape, and validate user input server side.

Enforce SSL (https) for your login page. And while you're at it, you might just as well enforce SSL for your entire website. Hardly any reason not to, any so called performance issues are remnant illusions of a previous decade.

Whenever there's ANY personal or sensitive information involved on your website (like a login form, registration process, acquiring customer details, email subscription, cookies, history, banking, payment, administration area, whatever), why making it possible for your customer's ISP, or secret government agencies, or a wifi hotspot operator, or man-in-the-middle hackers, or whoever, to sniff your traffic, monitor or intervene with your customer's connection, keep track of your communication, and whatnot?

JUST. USE. SSL.

Oh, and FYI: regular plain old-fashioned FTP is also COMPLETELY INSECURE as it transmits all login details, commands, and file data in PLAINTEXT (amongst other weaknesses). So just like email, FTP is EVIL and should be avoided whenever possible. Any decent hosting provider should provide a secure alternative such as SFTP.