Bill, Good point about using a "slow" hash algorithm. A "dictionary" attack on the hash should fail because, in order to currently use the password the old password had to not be in the dictionary in the first place. However "keyspace" attacks (brute force) would still be quite feasible. Would probably want to put something similiar to a salt in there to help increase the keyspace. Keep in mind that the only reason I suggested a hash at all is to prevent an admin who, in general, would not go through the effort to replace login/password or install a sniffer to get your password, but might be "unnecessarily" tempted by having easy to access passwords stored in plaintext on the server (still in a file only the admin could read). Basically just as a method to keep honest people honest. To verify that a user wasn't using a variation on the original, you would want to only store the hash of the original, but do hashes of the variants on the "new" password and compare with the stored hash of the old password. And of course, only store a password AFTER it has been changed. Really paranoid admins should use challenge/response/one-time passwords with/or kerberos. chris gorsuch chrisg@ti.com