X-Original-To: pgsql-docs-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 6C8E953820 for ; Fri, 29 Apr 2005 13:48:29 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 28935-05 for ; Fri, 29 Apr 2005 16:48:18 +0000 (GMT) Received: from candle.pha.pa.us (candle.pha.pa.us [64.139.89.126]) by svr1.postgresql.org (Postfix) with ESMTP id E357453810 for ; Fri, 29 Apr 2005 13:48:17 -0300 (ADT) Received: (from pgman@localhost) by candle.pha.pa.us (8.11.6/8.11.6) id j3TGmFx13138; Fri, 29 Apr 2005 12:48:15 -0400 (EDT) From: Bruce Momjian Message-Id: <200504291648.j3TGmFx13138@candle.pha.pa.us> Subject: Re: Using Encryption Patch to Docs In-Reply-To: <20050429164435.EF70C4309@cbbrowne.com> To: Christopher Browne Date: Fri, 29 Apr 2005 12:48:15 -0400 (EDT) Cc: PostgreSQL-documentation X-Mailer: ELM [version 2.4ME+ PL121 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.01 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200504/32 X-Sequence-Number: 2962 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 @@ > > > > + > + Use of Encryption in <productname>PostgreSQL</productname> > + > + encryption > + > + > + There is increasing interest in having verifiable mechanisms > + to maintain the privacy of data in databases. In the United > + States, legislation called HIPAA (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. > + > + Questions frequently come up as to what functionality > + PostgreSQL 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. > + > + > + > + Passwords stored in MD5 form > + > + Passwords are normally not stored in > + plaintext form in the database; they are hashed > + using the built-in MD5 function, and that is > + what is stored in the database. > + > + > +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) > + > + > + > + > + Connections protected using SSL > + > + There are various options to control how mandatory it is > + to use SSL to protect data connections. At the most > + paranoid end of the spectrum, you can configure > + pg_hba.conf to have the database reject > + connections that do not come in via > + SSL. > + > + 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. > + > + Connections authenticated using SSL > + > + 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. > + > + Using OS level encryption for entire database > + partitions > + > + On Linux, encryption can be layered on top of a filesystem > + mount using what is called a loopback device; 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 > + gbde. > + > + 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. > + > + > + In contrast, this mechanism does nothing to protect > + against attacks when the filesystem is mounted, because when > + mounted, the OS provides a view 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. > + > + > + Using the contrib function library > + pgcrypto so the database engine manages > + encryption of certain fields. > + > + 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 unencrypted form while it is being > + communicated between client and server, and the use of an SSL > + layer of superencryption alleviates that > + problem. > + > + 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. > + > + Using cryptographic tools on the client > + > + 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 paranoia 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. > + > + Peter Wayner's book, Translucent > + Databases, discusses how to do this in considerable > + detail. > + > + > + > + > + > > >