I'd like input on this cookie password storing security system,
When the user ticks the remember me box, it stores these cookies:
User name in plain text.
Password encrypted with a completely random key that the server stores in the database, that is never passed to the client and is user-specific, changes with every login.
And the server then decodes the password with the encryption key when needed.
No offence intended, but why do you want to reinvent the wheel?
Many have already implemented their own versions of this particular wheel so why not search SourceForge? Reusable software - can you code this more quickly than you can find an acceptable (and tested) solution?
Use off the shelf building blocks for the grunt work and move on to the interesting parts ;-)
An attacker could steal somebody else's cookie and then be logged in without having to know the actual password. They would just send the same cookie and would get in. Being able to sniff traffic off the wire and then resend it later is a replay attack.
The best defense is to use SSL so the security is end to end. If you're running a serious commercial site then you should use SSL, no ifs ands or buts. Using SSL cookies will always be encrypted over the wire so it doesn't matter quite so much what their contents are as the attack vector changes from packet-sniffing to having to read the cookie off end users' hard drives.
If your site is not quite so serious, then read on.
On my site, I take the user's password and concatenate their IP address plus a secret token and hash all of those. That hash is stored in a cookie. Then to authenticate them on the server I recalculate the hash and verify that the one they sent matches.
This ties the cookie to a particular IP address so it cannot be so easily reused by a third party. It also eliminates any danger of decrypting the cookie and discovering the password since the hash (SHA256, say) is one-way and cannot be reversed.
Also, I hope you are not storing raw plaintext passwords on your database. You are storing password hashes, yes? And are also salting them to prevent rainbow table attacks?
As Leonix said, this is probably better left to someone else who has developed it before and fixed all the bugs. Especially because it's security related.
Other than that, a glaring flaw I can spot is lack of authentication, or susceptibility to a 'replay' attack, where someone just blindly sends the cookie data that they could of copied from whom they want to impersonate.
Per @caf, adding this as an answer:
If you're going to go down this path, where the cookie basically stores the server's secret, there's absolutely no reason for that secret to have anything to do with the user's password. The client can't interpret the meaning/value of that data anyway.
In essence, that encrypted data is just an authentication token with special rules for how the token was generated. But making the token the user's encrypted password only adds more risk, because now if an attacker somehow gets the encryption/decryption key from the server, they have your user's password. You've made the token itself an attractive target since it has intrinsic value.
So instead of storing the encrypted password in the cookie and the encryption key in the database, you could just have the server generate a sufficiently long random number and store it in both the DB and the cookie. Since it has no meaning to the client anyway, it doesn't really matter what you use for the token, as long it's random, hard to guess and the server can verify it. Don't bother making it have a correlation with the password.