Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
P
Postgres FD Implementation
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
Abuhujair Javed
Postgres FD Implementation
Commits
99354440
Commit
99354440
authored
May 08, 2005
by
Bruce Momjian
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Add encryption section to documentation.
Christopher Browne
parent
545828a7
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
127 additions
and
1 deletion
+127
-1
doc/src/sgml/runtime.sgml
doc/src/sgml/runtime.sgml
+127
-1
No files found.
doc/src/sgml/runtime.sgml
View file @
99354440
<!--
$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.31
5 2005/04/23 03:27:40
momjian Exp $
$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.31
6 2005/05/08 03:29:06
momjian Exp $
-->
<chapter Id="runtime">
...
...
@@ -5109,6 +5109,132 @@ psql -h localhost -p 3333 template1
</sect1>
<sect1 id="encryption-approaches">
<title>Use of Encryption in <productname>PostgreSQL</productname></title>
<indexterm zone="encryption-approaches">
<primary>encryption</primary>
</indexterm>
<para> There is increasing interest in having verifiable mechanisms
to maintain the privacy of data in databases. In the United
States, legislation called <acronym>HIPAA</acronym> (Health
Insurance Portability and Accountability Act) requires that
personal health information is handled securely. The European
Union has similarly been developing directives as to how personal
data is to be managed there.</para>
<para> Questions frequently come up as to what functionality
<productname>PostgreSQL</productname> offers with regard to
supporting the use of data encryption. It uses and provides use of
encryption tools in several ways that may be useful to provide
protection against certain classes of attacks.</para>
<itemizedlist>
<listitem><para> Passwords stored in MD5 form </para>
<para> Passwords are normally not stored in
<quote>plaintext</quote> form in the database; they are hashed
using the built-in MD5 function, and <emphasis>that</emphasis> is
what is stored in the database. </para>
<programlisting>
sample=# alter user foo password 'some dumb value';
ALTER USER
sample=# select usename, passwd from pg_shadow where usename = 'foo';
usename | passwd
---------+-------------------------------------
foo | md5740daa4aaa084d85eb97648084a43bbb
(1 row)
</programlisting>
</listitem>
<listitem><para> Connections protected using SSL</para>
<para> There are various options to control how mandatory it is
to use SSL to protect data connections. At the most
<quote>paranoid</quote> end of the spectrum, you can configure
<filename>pg_hba.conf</filename> to have the database reject
connections that do <emphasis>not</emphasis> come in via
SSL.</para>
<para> The use of SSL, alone, is useful for protecting
communications against interception. It may not be necessary
for connections that take place across a carefully controlled
network; if connections are coming in from less controlled
sources, its use is highly recommended.</para></listitem>
<listitem><para> Connections authenticated using SSL</para>
<para> It is possible for both the client and server to provide
to one another SSL keys or certificates. It takes some extra
configuration on each side where these are used, but this likely
provides stronger verification of identity than the mere use of a
text password. </para></listitem>
<listitem><para> Using OS level encryption for entire database
partitions</para>
<para> On Linux, encryption can be layered on top of a filesystem
mount using what is called a <quote>loopback device;</quote> this
permits having a whole filesystem partition be encrypted on disk,
decrypted by the operating system. On FreeBSD, the equivalent
facility is called GEOM Based Disk Encryption, or
<acronym>gbde</acronym>.</para>
<para> This mechanism may be expected to be useful for protecting
against the threat that someone might pull disk drives out and
try to install them somewhere else to draw data off of them.
</para>
<para> In contrast, this mechanism does nothing to protect
against attacks when the filesystem is mounted, because when
mounted, the OS provides a <quote>view</quote> of the filesystem
accessible in plain text form. Furthermore, you need some way
for the encryption key to be passed to the operating system in
order to mount the filesystems, which encourages having the key
accessible somewhere on the host that mounts the disk.
</para></listitem>
<listitem><para> Using the contrib function library
<function>pgcrypto</function> so the database engine manages
encryption of certain fields.</para>
<para>If much of the data can be in plain text form, and only a
subset is particularly sensitive, this mechanism supports
treating them differently. The encrypted data is only ever
presented in <quote>unencrypted</quote> form while it is being
communicated between client and server, and the use of an SSL
layer of <quote>superencryption</quote> alleviates that
problem.</para>
<para> Unfortunately, in this approach, the encryption keys need
to be present on the server, even if only for a moment, which
presents the possibility of them being intercepted by someone
with access to the database server. As a result, this mechanism
is not suitable for storage of data that is too sensitive for
system administrators to have access to it. </para></listitem>
<listitem><para> Using cryptographic tools on the client </para>
<para> If it is not safe to trust the system administrators at
least somewhat, you may find it necessary to encrypt data at the
client level such that unencrypted data never appears on the
database server. This sort of <quote>paranoia</quote> is quite
appropriate for applications where it would be damaging for data
to be seen by inappropriate readers that might generally be
considered trustworthy, as can be the case with
medical and legal records.</para>
<para> Peter Wayner's book, <citation>Translucent
Databases</citation>, discusses how to do this in considerable
detail.</para></listitem>
</itemizedlist>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment