This is disastrous.
The right (or at least a much better) way to do this is to create a server-side token that is long and random enough to be unguessable and send in the cookie when the user logs in. When the server receives a cookie, check the token against the list to see if it matches, and if so, consider the user validated.
A few miscellaneous notes:
- You may want to reset that token now and then to keep someone who copies the user's cookies from having indefinite access to your site. If the token is, for example, older than a week, generate a new one and send it to the client and expire the old one server-side.
- Treat the token server-side with the same security as a username and password, since it is considered an authentication mechanism. Don't just stick it in a table or a file that's accessible to everyone!
- For any transactions that are destructive or of higher level of confidentiality, make sure you force the user to re-validate via username and password. For example, if the user wants to change their password, or if you use e-mail as a password recovery mechanism and they want to change their e-mail address, or if they want to delete their account, etc., make them type their username and password in to do so even if the token exists.
You might want to check out the OWASP site for more tips and best practices, but yeah, do not send the password in any form, no matter whether it's hashed, encoded, or whatever, to the client.