next up previous contents
Next: Commands implemented Up: Characteristics of a POP3 Previous: Characteristics of a POP3   Contents

RFC 1081 and security

POP3's weakest point from a security standpoint is that the password is transmitted in clear text, allowing any potential attacker to sniff the network for passwords. This limitation, however, can not be handled by a wrapper, as the wrapper must still adhere strictly to the POP3 protocol to be useful; doing otherwise would make it necessary to write new POP3 clients, or perhaps even redefining the protocol. A couple of points in the AUTHORIZATION state can be strengthened by the wrapper:

The RFC specifies that after the USER command is specified the system must check if the user exists, and return +OK if a valid username was given, or -ERR if the specified username does not exist. This can unknowingly disclose information about the server's accounts. Quoting from RFC 1081 [7]:

USER name
Arguments: a server specific user-id (required)
Restrictions: may only be given in the AUTHORIZATION state after the POP3 greeting or after an unsuccessful USER or PASS command
Possible Responses:
+OK name is welcome here  
-ERR never heard of name  
Examples:  
C: USER mrose  
S: +OK mrose is a real hoopy frood  
...  
C: USER frated  
S: -ERR sorry, frated doesn't get his mail here
Most POP3 servers nowadays choose to always give a positive answer to USER. Some, however, will still answer negatively. The wrapper should intercept this reply, giving always a possitive answer for this command.

A POP3 server does not need to put a limit to unsuccessful login attempts, according to the RFC. This can be used by an attacker to try to use brute force to guess somebody's password. The wrapper will take two steps to prevent this: First of all, it will limit to a user-set number the number of failed login requests that can be allowed in a single session. Of course, a new session can be established, but it is an extra hurdle for the attacker, an automatic program will be somewhat harder to do. The wrapper will also add some waiting time every time a password is not correctly provided --two or three seconds is advised--, making it much harder to perform a large number of login attempts.

When the connection progresses to the TRANSACTION state there are still some points that should be monitored. First of all, the number of valid messages. Whenever a STAT is performed byt he user, ProtoWrap will not only report the answer to the client, but will also store the result. This is to learn the number of messages waiting to be retrieved. If the client tries to access (via TOP or via RETR) a message below the first one or after the last one, or does not specify a valid number. Each time the DELE command is used, the deleted message number should be added to a hash, to prevent the deleted messages to be requested again. Of course, if a request is denied by the wrap it should never reach the server.


next up previous contents
Next: Commands implemented Up: Characteristics of a POP3 Previous: Characteristics of a POP3   Contents
Gunnar Wolf
2001-03-12