Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!

TUCoPS :: Password Security :: elimin~1.htm

Eliminating Plaintext Passwords on Your Network
Eliminating Plaintext Passwords on Your Network Security logo

Eliminating Plaintext Passwords on Your Network
A work-in-progress, based on experiences at the San Diego Supercomputer Center.

At SDSC, eliminating plaintext passwords is one of a handful of key strategies we have implemented which have been quite effective at preventing intrusions to our hosts.


We manage to support thousands of users, spread out across the planet, without mandating homogeneity of client software or simply not providing service. Our users can remotely access our systems as effectively as they can locally. We could not do so and keep our systems secure without eliminating plaintext passwords.

This stategy and effort to eliminate plaintext passwords came out of several security yearly reviews performed at SDSC from 1994 through 1997. In these reviews, we analyzed all the security events from those years and determined the underlying causes of the problems. It was obvious from these analyses that the easiest and most common way for our user accounts (and hosts) to be compromised was network password sniffers running at the home sites of our thousands of users. In one year (1997), sniffers running at other sites accounted for almost all of our significant security events.

It was plain that something had to be done.

Plaintext Authentication is a Problem

Most commonly used protocols/applications transmit resable passwords in the clear(plaintext passwords).
These protocols include...

  • TELNET - remote login
  • rlogin/rsh/rcp - remote login
  • FTP - file transfer
  • POP - mail retrieval
  • IMAP - mail retrieval
  • HTTP "Basic Authentication."
... and many others, including most Windows remote access programs, many other file sharing tools, etc.

Why is this a problem? Because anyone monitoring (eavedropping) on the network tranmission can intercept and use those passwords to gain access to your systems. And most of the intrusions we've seen include the use of a sniffer (eavesdropping software): a intruder will install a sniffer just to see if they can pick up some good passwords while they are in the neighborhood.

Compromise of a user password is on of the most difficult intrusions to detect. When a valid username and password is presented, how does the system know whether or not it is being presented by the actual authorized user? How do you, as a system administrator, know whether or not a particular session belongs to the actual user or an intruder with a stolen password? You might be able to make an inference based on the source of the intrusion, or some pattern of behavior like time of access, but that's prone to error and rather cumbersome to implement.

The best strategy is to prevent interception of passwords in the first place. This can be done in several ways:

  1. Keep all machines standalone, without any network access.

    While this certainly rememdies the password interception problem, it also can limit the usefulness of your computers.

  2. Only allow services on networks and systems that you control, so that sniffers can't be installed.

    This too can work, but limits what your users can do remotely, while travelling, etc.

  3. Use software and protocols which either do not transmit passwords, or encrypt passwords so that the intercepted information is not useable by an intruder.

(We like number 3.)

The Technology

The key to eliminating plaintext passwords is realizing that there is no one solution that fixes everything. Instead, we rely on a combination of solutions for the different services we support. In some cases, we support multiple services to allow our users to choose their own client software.

Here is a matrix of the solutions we use:
Type Protocol Server Client
Remote Access Kerberos-enabled servers ktelnet
Apache+SSL+Kerberos Authentication Module
SSL-capable web browser
Ssecure Shell (SSH) ssh 1.2.27 w/Kerberos any ssh version 1 compatible client
Reading E-mail IMAP/SSL UW imapd with sslwrap Outlook
Netscape Mail
POP/SSL qpopper with sslwrap Outlook
APOP qpopper Eudora
KPOP qpopper Eudora
SSL Webmail IMHO
any ssl-capable web browser
Sending E-mail SMTP AUTH Sendmail
SSL Webmail IMHO
any ssl-capable web browser

Network Services
All the services for which we provide non-plaintext authentication...
Documentation and Tutorials
Installation and Configuration of...


Literature and Documentation


NSF logo San Diego Supercomputer Center (SDSC)
National Partnership for Advanced Computational Infrastructure (NPACI)
University of California, San Diego (UCSD)
9500 Gilman Drive, Mail Code 0505
La Jolla, California 92093-0505
858-534-5000 [phone], 858-534-5152 [fax], [email]

Last Modified: Friday, 17-May-2002 16:42:51 PDT

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2015 AOH