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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
