DESLOGIN(1)

NAME
deslogin - DES authenticated and encrypted Network login

SYNOPSIS
deslogin [ -dv ] [ -g gateway ] [ [ user@]domain[:port] ]

DESCRIPTION

Deslogin is a network login program similar to telnet but more secure. Unlike telnet, it does not transmit passwords across the network. Since passwords (actually pass phrases) may be arbitrarily long, they don't fall prey to password guessing attacks like the eight-character ones of telnet and login do.

Deslogin also encrypts both directions of the data stream of the login session, so network snooping cannot reveal sensitive information accessed during the session (such as using the su command to become root). Encryption also protects the connection from being hijacked.

Deslogin attempts to connect to the specified remote system as the specified user at the specified port. If no system or user is given, deslogin will prompt you. If no port is specified, the default one from /etc/services (usually 3005) is used. If no user name is given, the local user name from (getlogin(3)) is used.

Deslogin prompts you for a pass phrase. This phrase, known only to you and the remote machine, is used to authenticate your identity to the remote host. You may use an arbitrarily long sequence of characters for the phrase. I find that short sentences make excellent easy-to-use choices.

If the authentication is successful, you will be logged into the remote host with your standard shell, user-id, and environment. All information transmitted or received from the remote host is encrypted using the United States Data Encryption Standard in cipher-feedback mode. The data encryption key is unique for each deslogin invocation. This prevents playback attacks and drastically reduces the time the login passphrase is subject to attack. If any part of authentication fails, deslogin exits without comment.

Often (almost always), the remote host will place an inactivity timer on your login session. This helps prevent the remote host from being compromised if you walk away from your machine while a deslogin session is active. Typically this timer is kept short (default is 20 minutes) to reduce the window of opportunity for someone walking up to your machine while you are away. Don't leave deslogin sessions unattended. If you don't have any input/output going to your session for the inactivity period, the session is shut down immediately without warning. If the timeout is too short, talk to the installer of deslogind(3) on the remote host.

  Options

-d  enable debug output (can't be used by attacker to compromise keys)

-v  Verbose mode. Enable verbose output of messages.

-g gateway
    Specifies a host:port to use as a gateway. Deslogin sessions can be routed through a gateway process installed on a "firewall" machine. The :port is optional. If not specified the default port from /etc/services (usually 3006) is used. Firewalls often exist at entrances to secure networks. This option causes deslogin to prompt you for a gateway passphrase which is used to authenticate yourself to the gateway. This passphrase is probably different than the passphrase for the host you are logging into. Once the gateway is satisfied of your identity, it routes your login session to a remote machine, which will authenticate you and encrypts the session in the usual manner. You have no access to the gateway machine, and no user (even root) on the gateway will be able to examine information flowing through the gateway.

WARNINGS

Do not leave deslogin sessions unattended. Someone can walk right up to your keyboard and do anything you can.

You should take great care to preserve the secrecy of your passphrase(s). Don't let people watch the keyboard while you type in the passphrase; it's been done with telephone access cards with binoculars in airports! Don't write down your passphrase; pick a sentence that is easy for you to remember; any characters are allowed, including punction and spaces.

Always invoke deslogin on the local host. Do not use telnet (rlogin, xterm, etc.) to a remote machine, and then invoke deslogin on that machine to get to another. If you do, the keystrokes of your passphrase will appear on the network between the local and remote telnet hosts.

On machines served by X-windows, use the "Secure Keyboard" option from the xterm "main menu" usually invoked by the CTRL-<left mouse button>. This feature is supposed to prevent X-windows clients authorized to connect to your server from being able to intercept your keystrokes into that xterm window. The window should change color when this option is in effect. You only need to protect keystrokes while you are entering the passphrase. If you are concerned about your session data being snooped, you still need to ensure that other X clients cannot access your Xserver root and session windows. Xwindows has other security holes such as unix-domain sockets in filesystem directories, frame buffer and keyboard device files.

Even then, you must make sure that the terminal pty (/dev/ttyp*) associated with your xterm window is not subject to hijacking or eavesdropping. You can find out the pty by using the tty(1) command. Check the permissions and ownership of that device file to ensure that it cannot be read by intruders on your local machine.

The same applies to the device special files for your screen frame buffer and keyboard interface.

Deslogin erases the memory storing your passphrase, and the resulting keys immediately after entry. Only a hashed form of your session key remains buried in the data segment of your deslogin process. It is possible for a sufficiently determined attacker with root permission to your local machine to read the memory of your deslogin process and compromise your session key. This won't help them determine your passphrase though.

In order to prevent idle traffic analysis by casual users, you should avoid specifying any arguments to deslogin; just respond to the prompts instead.

Beware of "trojan horses". When you invoke deslogin, make sure that you aren't invoking another program in a directory in your PATH environment variable which has been placed there by a hostile user. If you PATH includes directories on remote machines, (especially including the current directory: '.'), be sure that the remote machines are trusted by you. Invoking deslogin by its full path name on a local filessytem prevents this problem if the attacker hasn't replaced the original.

It is still possible that someone on the network between the two deslogin hosts can attempt to record or insert data (possibly from a previous session) into your encrypted data stream. If this happens, you will see garbage characters appear on your screen since the inserted data will be from a session using a different session key. I've used this program for several years and have never seen this happen, but it's possible.

Summary: Deslogin is designed to protect you from unsecure networks traversed between your (secure) local host and a secure remote host. It is best to use deslogin on a local machine which is not subject to a determined attack from hostile local users. This is quite commonly a valid assumption; just be aware when you are making it. If you have reason to strongly distrust root capable users on the local machine, do not use deslogin to access a highly secure machine.

AUTHENTICATION PROTOCOL

Deslogin uses a "challenge-response" protocol to authenticate users. The remote host encrypts a 64-bit unique unpredictable nonce and sends it as the "challenge". Deslogin then asks you for your passphrase which is hashed into a 56-bit DES authentication key used to decrypt the challenge and send back the 64-bit "response". The remote host (which shares knowledge of your passphrase) decrypts the response and compares the result with the nonce used to generate the challenge. If they're equal, authentication succeeds and a unique session key is generated by encrypting the challenge with your DES key. The authentication key is immediately destroyed and the session key is then used to encrypt all other data transferred.

ENVIRONMENT

See the deslogin(1) manual page under the ENVIRONMENT section for useful environment variables such as TERM and RHOSTNAME.

MISSING FEATURES

A more secure system would allow you to authenticate the identity of the remote host. In practice this is not likely to be a serious problem since someone attempting to "spoof" a remote host can only trick you into "signing" the authentication challenge packet by encrypting it with the DES key corresponding to your passphrase. The conjecture is that DES has properties that make this computationally infeasible. Some disagree.

Some method for the local netlogin to authenticate itself to you should be devised to prevent trojan horses from masquerading as netlogin and tricking you into revealing your passphrase.

There needs to be a way for users to change their passphrases. Currently, the administrator on the remote machine must set the passphrase. This could be construed as a "feature" since it allows the administrator to verify the passphrase difficult to guess.

ACKNOWLEDGEMENTS

The author has made every attempt to produce a secure and portable authenticated login program. I havn't had time to integrate this with telnet and the myriads of telnet protocol extensions, which would have been the "right" way to implement this program. Comments and improvements will be greatly appreciated and should be directed to the author:

David A. Barrett (barrett@asgard.cs.Colorado.EDU)

Copyright 1994 by David. A. Barrett.

This program is not to be distributed for profit or included in such software without written permission from the author. No permission is required for non-profit use.

FILES
/dev/tty    to output prompt and read passphrase

SEE ALSO
cipher(1), telnet(1), rlogin(1), deslogind(1), deslogingw(1), tty(1), getlogin(3).