[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] GNUmed options for security (authentication) includin
Re: [Gnumed-devel] GNUmed options for security (authentication) including kerberos
Sat, 16 Dec 2006 20:14:33 +0100
On Fri, Dec 15, 2006 at 09:26:19AM -0800, Jim Busser wrote:
> I was looking over some wiki pages and came across
> 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.
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346