Just for a perspective from someone who used a different kind of encryption...
You never store a password. Ever. What you do instead is generate some sort of hashed string (RC4 hashing being one such example) when the user creates the account. Then, when your user wants to log in, you ask for a username and password and hash THAT, too. Then compare the fresh hash with the stored hash. That way, you can honestly say that you don't know the password, so can't divulge it even if someone wanted to know.
Typically, you do something like concatenate the username and password with one garbage character like a vertical bar or a tilde. Then take the hash of that longer string. That way you have the username and password combined in a way that will inextricably link them together.
I was with the U.S. Navy and held security certificates for a long time. The above method is approved by the U.S. Dept. of Defense and in fact is one of the preferred methods of doing a username/password combo.
The only thing that you need to remember is if the user wants to change passwords, always use a "tell me twice" method and compute the hash once for each input. Then compare them and do nothing if the user fat-fingered the password. If you have a choice among the various ways you could do the hashing (RC4 is only one of MANY possible hash algorithms), you have to have a way to remember which method the user used (or YOU used) when the stored hash was computed. That way, if you later add a new hash to the repertoire, you can still validate old users and old passwords.