You need to read up on
- HTTPS/SSL
- password hashing
The issues you mention have been thought of and addressed.
Either the password is sent in plain text
It's not. It is sent via HTTPS, meaning encrypted.
or it's sent in it's encrypted format, in which case somebody could intercept that and, even if they can't read the password, they could then pretend to be you by sending the encrypted string to the site.
No. HTTPS sessions cannot just be hijacked like that. There is a shared secret key being negotiated between the two parties, and you cannot just intercept and replay. The server issues challenges that a man-in-the-middle cannot reply to convincingly.
Note that this depends on the public-key infrastructure, though, meaning trusted certificate chains. If someone can fake an SSL certificate (or make you accept a self-signed one), you cannot be sure who you are talking to. Then, man-in-the-middle is possible.
Similarly if the hacker gets a copy of the database, he would just be able to send of the encrypted password and gain privileges.
Yes, if the hacker gets a copy of the database, that is a problem.
Sending an encrypted password however is useless. Password checks work by sending the "raw" password (over an encrypted connection), and then comparing it against a hash stored in the database.
What a hacker would do if he got the database is try to brute-force (guess) the passwords locally, and if he is lucky, he can then log in as the user. Fortunately, if the passwords are long and random, and they have been properly hashed and salted, this process still takes a long time. No longer long enough to be completely safe from cracking, but still long enough for you to change your passwords.