You can't, most of the time. The correct way to "store" a password so that a user can be authenticated during a login session, for example, is by using the Hashing methods of Xceed Encryption Library. A password should never be stored, encrypted or not, on a disk drive. Here's how a typical user/password authentication scheme is performed.
During the first login (or following a password change), a salt value is calculated (see below) and is added to the password. The result is then hashed using, for instance, SHA-1 (160 bits). This can be done by using the Hash method of the the XceedSHAHashingMethod. The username is stored along with the hash value of the user's password and the salt value.
On subsequent logins, the stored user salt is added to the password entered by the user and the result is hashed using the same algorithm. The resulting hash value is compared with the stored hash value of the username. If the hash is the same, the probability is very, very high that the password entered is the right one.
What is a salt?
A salt is a value added to a password during login authentification before it is hashed. The value can be anything. A random value, the user id, a sequential number, ... The value is added to the password using, generally, a simple concatenation; but it could be something else (a XOR, for instance). The salt is stored, in the clear along with the username and the hash value. Its purpose is to prevent mass dictionnary attacks. A mass dictionnary attack is when an attacker has precomputed a table of frequently used password and their hash value. The attacker uses this table to lookup in the password database and try to find a match. It is computationally infeasible to precompute a table of all possible variations of frequently used password when salt is used.
However, the salt does not prevent a dictionnary attack on a single password. Knowing the salt value associated with a user, an attacker can calculate the hash values of the most commonly used password and try to find a match.