BrowserUk, I have a great respect for your abilities in algorithmic and systemic thinking -- and thus, from an engineering perspective, I find myself siding with you very nearly always.
So I am left to conclude that either I am not describing the problem sufficiently, or you are missing something. I'd be interested to see which.
So -- how would you address this situation:
You work for a company which has a heavily distributed base of employees. Culturally, policy and responsibility is pushed down to the lowest level; there is very little truly controlled from a central location.
The culture also honors this approach, taking the cost of destandardization as a good trade for increased productivity from empowering the individual and permitting local management to . . . well, manage. So you will be limited in making cultural, procedural, and administrative changes.
However, you have locally-controlled, but corporately-accessible databases scattered all over the company, and one of the things that is needed is for people to query these various databases a lot -- custom work, looking for things happening in other parts of the company in an effort to exploit prior art and use already-invented wheels rather than inventing new ones.
It's been this way for decades, and, of necessity, they've gotten good at it.
Someone at some point built a system which kept track of all the access credentials, so these folks can code up a Perl script which goes and snags a bunch of data, correlates it the way they want, and so on. This, too, has been in use for more than a decade. Everyone knows the process, and uses it effectively.
It is seen as too costly to revamp the way work is done. Management likes what happens when localized empowerment couples with centralized access -- so you're stuck with people calling this centralized routine to get the database, instance, port, username, password, etc., and feed it into whatever routines they've written to query the various databases from their Perl scripts.
But someone has caught on to the idea that keeping the passwords in clear text is a bad idea. Since that's controlled managed centrally, it's an area where you can make some changes.
What approach would you take to try to lessen the impact of cleartext passwords in a Perl module? Remember that these folks still have to be able to access the same databases, which are not centrally controlled.
What would you do to try to help with the cleartext-in-module issue?
Update: Department of Redundancy Department
Update: Verbiage adjust