"Password validation services" -- how can we avoid creating more of them?

David Wolfskill david at catwhisker.org
Thu Dec 28 15:04:01 PST 2006


Authentication seems to me to be a fairly well understood art by now; at
the same time, we (sysadmins, some of whom ought to know better) deploy
services that have their authentication mechanism(s) set up in such a
way that these mechanism may be abused by folks to acquire
authentication information that may be used to allow impersonation of
valid users of the service.

For example:  set up an SSH server that allows the use of "passwords"
for authentication and is accessible from anywhere on the Internet.
If one actually checks the logs, one finds that there are periodic
probes -- often in the form of "dictionary attacks" -- against
often-used logins.  Once a valid login is guessed or determined, it's a
simple matter to have one or more processes try various passwords
(possibly as simple as a brute-force attack) until a particualr working
login/password combination is found.

The best cure for this I know of is to do at least one of the following:

* Disallow password authentication in favor of public key authentication
  (or some form(s) of Kerberos  authentication that require more than
  just a password), or some 2-factor mechanism such as a SecureID fob.

* Restrict the use of password authentication to connections such that
  both the endpoints and all intermediate points are on "trusted"
  (and adequately secure) machines and networks.

But we still deploy services such as HTTPS or IMAPS that "need" to be
open to access from untrusted networks & machines, and which (often?)
only provide "password" as an aythentication mechanism.  I submit that
to the extent that this occurs, it is a Bad Thing.

Were it up to me, I'd just set up SSH servers to only use public key
authentication, and have folks access everything via SSH tunnels.  As
things stand, I've been accessing mail that way for some time:  I run
mutt on my desktop, which is configured to go talk to the IMAP server
somewhere else via an SSH tunnel.  (Of course, I run mutt within
screen(1), but that's for different reasons.)

And yes, I've run graphical Web browsers on remote machines accessed
via SSH tunnels; it's not necessarily fast, but it does work.  (It is
more tolerable within a LAN than over a WAN, certainly.)

Anyone have better (or at least "other") ideas?

Thanks!

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
Believe SORBS at your own risk: 63.193.123.122 has been static since Aug 1999.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://www.baylisa.org/pipermail/baylisa/attachments/20061228/05fafee2/attachment.bin>


More information about the Baylisa mailing list