Password Sniffing

Perhaps the most significant security risk on the Internet today is the use of plaintext, reusable passwords that are sent over internal and external networks. These are the same passwords that Metcalfe described in RFC602. Only now, the problem is not that they are easily guessable: the problem is that they are being sent in a form that is subject to eavesdropping.

Usernames and passwords are the most common way of authenticating users on the Internet today. They are widely used by many Internet protocols, including remote login (Telnet/rlogin), file transfer (FTP), remote email reading (POP3/IMAP), and web access (HTTP).

Consider FTP. Some Internet service providers install FTP servers on their web servers so that customers can update their web pages. Unfortunately, the FTP protocol sends the user's username and password without encryption:

vineyard: {95} % ftp company.net

Connected to company.net.

220 company.net FTP server (Version wu-2.4(1) Fri Dec 29 06:15:49 GMT 1995) ready.

Name (company.net:sascha): sascha

331 Password required for sascha.

Password: mypassword

230 User sascha logged in. Remote system type is UNIX.

Using binary mode to transfer files. ftp>

In this example, anyone who is able to monitor the network between the FTP server and the client will be able to read the letters s, a, s, c, h, a, m, y, p, a, s, s, w, o, r, and d. To make matters worse, the password mypassword is reusable, which means that it can be used again and again until Sascha changes his password. Some Internet service providers do not even allow users to change their own FTP passwords.

For years there have been programs widely available on the Internet that silently monitor all network traffic, scanning for packets by people who have typed usernames and passwords. These programs are called password sniffers because they "sniff " usernames and passwords from the network. The username/password pairs are then either stored for later use or sent over the Internet to the attacker's computer (or to another system that the attacker has compromised). Because the passwords are reusable, the attacker can use them

13.2.2.1 Protection against sniffing

The only way to defeat password sniffing is to avoid using plaintext usernames and reusable passwords. Today, there are three common alternatives.

13.2.2.1.1 Use a token-based authentication system.

Examples are the SecureID system from Security Dynamics (see Figure 13.1) or the SecureNet Key from Digital Pathways. These tokens are actually small hand-held computers that allow you to use a different password every time you log into the remote site. As the eavesdroppers do not posses the token, they cannot access your account at a later time.

Figure 13.1. Security Dynamics' SecureID card

13.2.2.1.2 Use a non-reusable password system.

An example is S/Key. With S/Key, users are given printouts with a list of hundreds of passwords. Each time they use a password, they cross it out, and use the next (see Figure 13.2).

13.2.2.1.3 Use a system that relies on encryption.

Doing so prevents the sending of your password in the clear over the network. These systems include Kerberos, Secure Shell (ssh), Secure Copy (scp), Secure Telnet (Stel)73_{, and Secure Socket Layer}

(SSL)/Transport Layer Security (TLS). Encryption schemes can be used with conventional reusable

passwords; they can be used with nonreusable passwords such as S/Key for additional protection, or they can be used with a public key digital signature certificate system.

The process of logging into an NT server for NetBIOS traffic is pretty secure; passwords are doubly encrypted as they pass from client to server, and at no point do they revert to plaintext. However, shares can be hijacked fairly easily once a session has been authenticated, as with an FTP or Telnet session.

Cryptographic techniques have the advantage of encrypting all information transmitted between the two network computers. They also protect ongoing connections from session hijacking —which occurs when an attacker seizes control of a network session after a legitimate user has authenticated. Unfortunately,

encryption schemes require that you have specially modified versions of both the Internet servers and clients for each protocol that you wish to protect. There are also interoperability concerns because of encryption restrictions by various governments and proprietary incompatibilities.

Encryption can be staged at one or more levels:

•

In the most specific cases, applications can be written or retrofitted for secured transfer. Because the encryption and authentication are typically negotiated in the application's client/server handshake, sessions are limited to individual protocols or services.

•

Encryption at the transport layer (e.g., TCP/IP) or network layer (e.g., IP), on the other hand, can often be applied to a variety of services. Potentially, the encryption will be transparent to the application; system network services can substitute encrypted transport for nonencrypted transport without affecting the application. SSL and TLS are examples of transport-level encryption standards.

•

Virtual private network (VPNs) are typically built upon standards for network-level encryption and authentication. The IPSec proposal is quickly becoming the de facto VPN standard (see RFCs 1825 through 1829). Note that the degree of encryption available to you depends on where the secured session is conducted; government restrictions limit the extent of cryptographic methods.

We strongly recommend the use of encryption to protect all administrative Telnet and file transfer sessions between a web server and an administrative workstation. If possible, they should be used to protect all Telnet and file transfer sessions.

In document Web Security & Commerce pdf (Page 190-192)