Just to add to this, and to emphasize what others have said:

When we store a user password in the DB, for example a web site DB, that password is the cryptographic hash of the password + a bit of salt. When a user logs in they normally type a plain text password and that password is sent in plaintext across the net, hopefully in a secure SSL channel. At the server side, the plain text password is retrieved by the server side logic and then the cryptographic hash + salt is compared to the same in the DB.

In some cases, the hash (more often than not an "md5()" hash) is stored locally on the client side the hash is sent as a cookie (or a $_POST or $_GET var), for example, so the plaintext password is not required (this is but one scenario).

However, on the server, we assume there is some standard file system security in place.

So, when an application needs to access the DB, normally the password is stored securely in a plain text configuration file. Likewise, we can store the hash instead of the password, but since the hash of the password and the password can both be used to gain access, most "day to day CMS" systems store the plaintext password in a secure file.

Some people hide this file is some obscure location on the server, like in a "hidden" dot file. This kind of security-by-obscurity is not very good, but some think it is better than nothing.

However, this is just a description of basic authentication.

Systems which have a higher risk use more complex (and expensive) methods for authentication.

As Robin mentioned, we need the details of the application and basic system architecture to properly advise; and as I have mentioned, we should know the risk profile of the system, to really help you.