Skip site navigation (1) Skip section navigation (2)

Re: Using Encryption Patch to Docs

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Christopher Browne <cbbrowne(at)cbbrowne(dot)com>
Cc: PostgreSQL-documentation <pgsql-docs(at)postgresql(dot)org>
Subject: Re: Using Encryption Patch to Docs
Date: 2005-04-29 16:48:15
Message-ID: 200504291648.j3TGmFx13138@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-docs
Your patch has been added to the PostgreSQL unapplied patches list at:

	http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---------------------------------------------------------------------------


Christopher Browne wrote:
> ? out
> Index: runtime.sgml
> ===================================================================
> RCS file: /projects/cvsroot/pgsql/doc/src/sgml/runtime.sgml,v
> retrieving revision 1.315
> diff -u -r1.315 runtime.sgml
> --- runtime.sgml	23 Apr 2005 03:27:40 -0000	1.315
> +++ runtime.sgml	29 Apr 2005 16:43:22 -0000
> @@ -5109,6 +5109,132 @@
>  
>   </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
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql-docs by date

Next:From: Bruce MomjianDate: 2005-04-30 03:52:26
Subject: Re: [COMMITTERS] pgsql: Remove replicaiton FAQ item.
Previous:From: Peter EisentrautDate: 2005-04-28 22:23:33
Subject: Re: pgsql: Mention that PAM requires the user already exist in the database,

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group