gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] GNUmed options for security (authentication) includin


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] GNUmed options for security (authentication) including kerberos
Date: Sat, 16 Dec 2006 20:14:33 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

On Fri, Dec 15, 2006 at 09:26:19AM -0800, Jim Busser wrote:


> I was looking over some wiki pages and came across
> 
>       
> http://salaam.homeunix.com/bin/view/Gnumed/DebianKerberosLDAPBindGnumedWalkthrough
> 
> Am I correct that a browser based client (like Oscar) --- if required  
> to use https --- avoids interception (in the clear) of the user's id  
> and password at any point along the network?
I would think so, yes.

> Am I correct to think that when one accesses a GNUmed server that was  
> set up following the basic installation procedures, there is no  
> protection against such interception, unless extra measures (like  
> kerberization of the server as per Syan's notes) are taken?
Sort of. The basic installation instructions do not cover
protocol-level encryption so far. However, they do recommend
using MD5 for authentication of non-local connects. This
means the password isn't sent in the clear over the wire but
rather as an MD5 hash. This has a bit of advantage but not
really *that* much - because an attacker could just sniff
the md5 hash and re-send that when it's asked by the server.

It is easy to obtain more protection, however. If I were to
look for ways to encrypt my connection to the database I
would go for (in this order):

a) SSL-connecting directly to PostgreSQL. This requires to
   say "hostssl ..." in pg_hba.conf instead of "host ...".

b) SSH-tunneling to the server machine and then using md5
   authentication over the encrypted tunnel.

Both methods provide wire-level encryption *below* the level
at which the username and password could be sniffed.

If none of this works only *then* would I worry about using
Kerberos. I mean, Kerberos probably isn't a bad solution in
and by itself and should it run on a site anyway one might
as well use it. I wonder, though, whether it's worth the
not-insignificant effort just for GNUmed to PostgreSQL.

Given a choice I would try SSL/SSH. Those are fairly
standard on most UNIX/LINUX installations.

> If skipping this step or equivalent could be considered poor practice  
> (poor protection of access to patient data) then must we make some  
> reference to this in the installation notes?
You are correct.

Unless the installation is entirely local - running on
client and server on a single machine - and all users are
trusted and unauthorized physical access to the machine is
not possible. In such cases it may well suffice to use
non-TCP/IP UNIX Domain Sockets with IDENT authentication.

> - are there any extra dependencies for client machines to access  
> kerberized GNUmed or do the basic installations of Linux distros and  
> Windows include support for kerberos so the user would need set up  
> nothing extra on the client machine(s)?
Extra depencancies would exist: kerberos client libraries.

> - when adding a new office worker or doctor into kerberized GNUmed  
> would each new person somehow have to be separately registered with  
> kerberos? Would this require user maintenance of a public and private  
> key separate from their GNUmed userid & password?
I guess both, yes.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

[Prev in Thread] Current Thread [Next in Thread]