While that's an option, it's a real pain. Worse, it's still less secure that
using Windows Auth to the SQL DB. I've actually done this before (we were
hitting an Oracle DB that didn't support Windows Auth), using both the COM+
method recommend by the PAG group, and using the DPAPI method others have
recommended. It worked, but it's alot of overhead both for the devs and the
sys admins to worry about.

If you can use it, Windows Auth to the SQL Database is better in every way.

Well, SQL Auth is considered to be insecure. It's easily cracked (I've used
the tools, and verified this, much to my client's amazement), doesn't have
any metering on it to prevent brute force attacks, transmits the credentials
to the database in plain-text, and doesn't integrate at all into the
standard security infrastructure already being used by the organization.
There no way to enforce password strength rules, and the passwords are store
as case insensitive hashes. There's no default monitoring of the invalid
password attempts, no automatic account lock-out, etc. There's a ton of
documentation on this found on the web.

All of the DBA's that I work with prefer Windows Auth to SQL Auth for ease
of use reasons as well. It's one less set of passwords to remember, less
configuration in the long run, fewer plain-text passwords floating around in
email & config files. It's much easier to switch between databases without
having to continually enter passwords.

It's also easier to manage in the HR case - when you fire an Admin or a Dev,
you don't have to change all the SQL Passwords, just lock-out his account.
When you hire someone new, you don't have to email them the credentials. You
just add the role to their Active Directory account, and it works.

If you ever want to scare yourself, go download Cain & Able off the web, and
watch the insecure traffic fly across your network. You'll have all the
account credientals in no time. Makeing sure the network layer is secure is
important!

--
Chris Mullins