Logon Triggers As A Security Mechanism

Question

I’d like to get people's opinions on an idea that's been proposed by my organization's architecture team.
I work in a rapid development environment with an extensive database code base.  A good amount of DDL, Code Complication, and adhoc DML occurs on a weekly basis. 
Currently, we do not share database passwords with anyone.  Our process is far from optimal and the passwords can, at times, land in the hands of developers; but, for the most part, we do our best to keep the passwords secure. We have 20+ databases with 100+ applications and 400+ developers.
The proposed approach from the architecture team involves the sharing of database passwords with development teams, and the use of logon triggers as our security mechanism.  The logon trigger would allow the logon when it’s coming from an approved program/module & host, and would throw an error and block the logon for unapproved.
What’s your opinion of this proposal?  Has anyone ever seen the approach before?  If so, was it successful?

Answer 1

As others have pointed out, the proposal clearly decreases security.  The question is, though, is that the goal?  Is the trade-off of less security worth whatever it is you gain?
You haven't told us anything about the problem you're trying to solve.  You've merely told us the solution that some other team proposed.  Without knowing what the problem is, it's hard to make any guesses about appropriate trade-offs, whether there are alternatives that haven't been discussed, etc.
I've certainly seen situations where there were human bottlenecks in getting code changes applied to development environments that caused developers to do things like re-implement database functionality in the middle tier or overload a column just to avoid the hassle putting a request in to the DBA group to promote the PL/SQL change.  This sort of thing can quickly turn an application into an unmaintainable pile of spaghetti code.  If that's the problem you face today and you can't add additional human resources to relieve the promotion bottleneck, that may be a reasonable trade-off.
By the same token, I've seen plenty of situations where developers had way too much power to accidentally screw up the shared environment by testing a script that inadvertently deleted a bunch of data or that otherwise broke everyone else's code.  That sort of environment can easily make the DBA group more of a bottleneck as now everyone is waiting on the DBA to restore a ton of data rather than to just run a script. 
I've seen login triggers used to add security where the goal was to keep honest people from making an honest mistake.  For example, I've used login triggers in situations where I wanted to prevent myself (or someone else) from inadvertently accessing the wrong environment accidentally.  It's relatively easy to circumvent a login trigger so the question becomes whether you are trying to deal with active attackers or human error.  If you've got a database of sensitive financial information and you've spent oodles of time and effort to encrypt the data in prod and mask the data in the lower environments, using a login trigger will barely phase a developer from being able to log in and steal all the data you've stored.  On the other hand, if you've got a database that doesn't have a lot of sensitive information and your lower environments already contain a complete copy of prod that gets refreshed without masking periodically, you may not be overly concerned that a rogue developer would want to access production to steal some data.  That doesn't protect you from the rogue developer that wants to cripple the system out of revenge, of course, but that's likely to be less of a concern to different companies. 
As with all things, it's a matter of figuring out what problem you're trying to solve and figuring out what trade-offs you're willing to make.
Justin