Encryption - Implementing Database Security and Auditing - page 299

10.1 Encrypting data-in-transit

In Chapter 3, you learned quite a bit about the database server as a net-

worked service. You learned that most database environments use TCP/IP
and that the database server listens to certain ports and accepts connections
initiated by database clients. While the ports are configurable, most people
tend to use the default server ports (e.g., 1433 for Microsoft SQL Server,
1521 for Oracle, 4100 for Sybase, 50000 for DB2, and 3306 for MySQL).
Database clients connect to the server over these agreed-upon ports to ini-
tiate a conversation, and depending on the database type and the server
configuration, redirect to another port or complete the entire conversation
on the same server port.
In the same way that you know this, so do hackers. Moreover, because
many hackers are system and network geeks, they know a lot about the
TCP/IP protocol and specifically about sniffing TCP/IP traffic. At a high
level, this means that with the right tools and the right access to the net-
work, anybody can tap into your database conversations and eavesdrop on
database access—capturing and stealing both the statements that you issue
as well as the data returned by the database server.
Eavesdropping on your database communications is relatively easy
because database communications are mostly in clear text—or close enough
to clear text. Therefore, by using simple utilities and mostly free tools, a
hacker can listen in and steal information. The way to stop this from hap-
pening—and the topic of this section—is to encrypt the communications
between database clients and database servers. This type of encryption is
called because all (or pieces of the) communica-

tions between the client and the server are encrypted. The encryption
occurs at the endpoints. Although I have yet to define what endpoints are
(and these will be different in different encryption schemes), one side will
encrypt the data being passed over the network and the other will decrypt
it—the data stored in the tables and the data used within the application is
not encrypted.
Although encryption of data-in-transit is becoming popular, I don't
want to give you the wrong impression—most people do not encrypt data-
in-transit, and for many environments that is perfectly fine. If you feel that
a potential eavesdropper is something you cannot live with, then you
should definitely encrypt data-in-transit. If you consider this to be unlikely

encryption of data-in-transit

and you think that on the odd chance that this occurs no heads will roll,

then it may not be worth the effort and the performance degradation. Deg-
radation depends on the encryption method as well as the database, but as