I thought this was the case. We discussed using a private key to encrypt the password, as we're trying to tighten up these issues in other places in metacat. However, it seems to me that we don't really need either in this case. The current process is to:
1) authenticate user upon harvest registration
2) store user password if valid
3) periodically harvest documents and insert, update, delete as that user
However, the key here is that metacat is simply keeping track of who it has previously authenticated, and gains no new information by storing the password. Instead, it seems to me that Metacat could simply store the account name and a 'validated' flag, then do the insertions as that user without further logging in. This would solve two potential problems. First, the password list is vulnerable to perusal if the db were to be compromised. Second, if the user changes their password in LDAP, the harvest will fail. Both of these would be solved by eliminating the stored password in favor of a simple 'authenticated' flag.
I suspect the reason this is done is that MetacatClient is used to do much of the document insertion, etc. So the system may need to be architected somewhat differently, such as by using an IPC-based version of MetacatClient that wouldn't communicate over http. Such a client has been planned since we first created the MetacatClient, but has never been implemented.