Authentication and Password Security - Implementing Database Security and Auditing - page 97

4.1.1 Anatomy of the vulnerability: Weak

authentication options

Most databases will allow you to control how authentication is done. This
means that if you're not careful and don't understand all the implications,
you could end up with rather weak authentication (i.e., a gaping hole in the
security of your database).
Let's look at an example from the world of DB2 UDB. DB2 allows you
to choose among several authentication options. One of the options is
called CLIENT, but it may as well have been called “no authentication.”
CLIENT authentication in DB2 UDB means that the database performs
no authentication on the server. If it gets a connection request, it assumes
that authentication has already happened on the client and accepts the cre-
dentials from the client without doing any further authentication. This is a
bad assumption because it allows me to plug into the network and almost
instantaneously connect to the DB2 instance without anyone having really
checked me out.
CLIENT authentication in DB2 assumes that people protect the client
workstations—a bad assumption. It has a concept of TRUSTED CLI-
ENTS representing all clients that have a “true” operating system, which
can perform authentication. For example, a Windows 9x machine will
never be a trusted client. However, the issue is not so much whether the OS
can authenticate or not (it may have been so seven years ago, but no more);
the issue is that workstations and laptops are not always a good security
environment, and it is dangerous to rely on authentication at the endpoints
for your database security. Just out of interest, I recently went around the
group I am working with at a client to see what their passwords were like. I
asked five people in sales and eleven people in technical support. Four of
the five people in sales had a Windows account with no password whatso-
ever. The support people were a little better in their own accounts, but all
the machines they were working on had a privileged account with the same
password that was well known and easy to guess. The support people used
this because they all had a need to sign on to each other's machines to run
tests or troubleshoot issues. The system administrator passwords on these
machines were good, but two of the support people had the password writ-
ten on a sticky note stuck to the monitor because it was so difficult to
remember. Do you really want to trust your database to that kind of an
authentication environment?