nanogui: Access control
Subject:
Access control
From:
Alex Holden ####@####.####
Date:
13 Dec 2000 13:17:43 -0000
Message-Id: <Pine.LNX.4.04.10012131239160.603-100000@hyperspace.linuxhacker.org>
Hi, I've been looking at what it would take to make nano-X network
capable (as an optional config choice of course). The stumbling block is
access control- I could make it network capable without any access control
whatsoever in about an hour, but I think that would be a really bad idea.
It seems we have several options for an access control policy:
Host based access modelled after X11's XAddHost(). Two main problems with
this; it's succeptible to address spoofing, and any user on a host which
is on the access list can access the server. I don't like this method and
don't think it's worth implementing.
Plaintext password based access. Basically this would use the server
machine's local password mechanism to provide a simple authentication
method. Inherently succeptible to packet sniffer based attacks, but no
more so than FTP, telnet, POP3, etc. I think it would be a good idea to
include this as an option (which can be disabled) for applications where
the network is known to be secure, and code size limitations prevent the
user from using a more secure algorithm.
Hashed challenge response based access. This has the advantage that an
implementation of it would be very small, several public domain
implementations of common hash algorithms such as MD5 exist, and it does
prevent plaintext passwords from being sent over the wire. It has the
disadvantage that it's not cryptographically strong. This method is used
by APOP, CHAP, and some other common protocols. I like the simplicity of
this method, but I've no idea exactly how strong it is, and whether it
would provide an acceptable level of security or not. Remember that I'm
not talking about encrypting the data which goes across the link after
authentication, just providing a method of access control which doesn't
require you to send your account password over the wire as plaintext- if
you were planning to use the system over a public network you'd be better
off tunneling the whole thing through SSH or similar anyway.
Private key encryption based authentication using DES or similar. This
method is relatively simple, and I believe it should be cryptographically
secure. I believe this involves having a private key stored on both the
client and the server, and using that to send a challenge/response (with
the response containing the password) in an encrypted form. This has the
disadvantage that if somebody manages to gets hold of the private key from
one of the clients, they can use it to snoop for passwords.
Public key encryption based authentication, similar to SSH. This is quite
big and complex, but should be the most secure. If I understand it right,
each client and server has it's own public and private key, and these are
used to exchange some kind of complex challenge/response protocol. To be
honest I don't think it's worth the code size and complexity penalty
required to implement this- if you need this level of security, tunnel the
data through a SSH pipe instead.
So, to sum up, I'm currently planning to implement a password based
authentication method which can optionally use an MD5 hash algorithm to
avoid sending the passwords as plaintext. Oh, and the authentication will
be seperate from the TCP/IP networking support, so it should be possible
to open up the permissions on the named socket and use the authentication
in local mode too if you want.
--
------- Alex Holden -------
http://www.linuxhacker.org/
http://www.robogeeks.org/
