7.20.3 login functions

The standard login script provides the following functions for external use:

is_login_conn (c: connection): bool

Returns true if the given connection is one analyzed by login (currently, Telnet or Rlogin), false otherwise.

hot_login (c: connection, msg: string, tag: string)

Marks the given connection as hot, logs the given message, and demultiplexes demux the subsequent server-side contents of the connection to a filename based on tag and the client-side to a filename based on the name "keys". No return value.

is_hot_id (id: string, successful: bool, confused: bool): bool

Returns true if the username id should be considered sensitive, given that the user either did or did not successfully authenticate, and that the analyze was or was not in a confused state (See: login analyzer confusion).

is_forbidden_id (id: string): bool

Returns true if the username id is present in forbidden_ids or forbidden_id_patterns.

edit_and_check_line (c: connection, line: string, successful: bool): check_info

Tests whether the given line of text seen on connection c includes a sensitive username, after first applying BS and DEL keystroke editing (see: login variables). successful should be true if the user has successfully authenticated, false otherwise.

The return value is a check_info record, which contains four check_info fields:

expanded_line

All of the different editing interpretations of the line, separated by commas. For example, if the original line is

"rob<DEL><BS><BS>ot"

then the different editing interpretations are "ro<BS><BS>ot" and "root", so the return value will be:

"rob<DEL><BS><BS>ot,ro<BS><BS>ot,root"

Deficiency: Ideally, these values would be returned in a list of some form, so that they can be accessed separately and unambiguously. The current form is really suitable only for display to a person, and even that can be quite confusing if line happens to contain commas already. Or, perhaps an algorithm of “simply pick the shortest” would find the correct editing every time anyway.

hot: bool

True if any editing sequence resulted in a match against a sensitive username.

hot_id: string

The version of the input line (with or without editing) that was considered hot, or an empty string if none.

forbidden: bool

True if any editing sequence resulted in a match against a username considered “forbidden”, per is_forbidden_id.

edit_and_check_user (c: connection, user: string, successful: bool, fmt_s: string): bool

Tests whether the given username used for authentication on connection c is sensitive, after first applying BS and DEL keystroke editing (See: login variables). successful should be true if the user has successfully authenticated, false otherwise.

fmt_s is a fmt format specifying how the username information should be included in the connection's addl field. It takes two string parameters, the current value of the field and the expanded version of the username as described in expanded_line.

If edit_and_check_line indicates that the username is sensitive, then edit_and_check_user records the connection into its own demultiplexing files . If the username is forbidden, then unless the analyzer is confused, we attempt to terminate the connection using terminate_connection.

Returns true if the connection is now considered “hot,” either due to having a sensitive username, or because it was hot upon entry to the function.

edit_and_check_password(c: connection, password: string): bool

Checks the given password to see whether it contains a sensitive username. If so, then marks the connection as hot and logs the sensitive password. No return value.

Note: The purpose of this function is to catch instances in which the event engine becomes out of synch with the authentication dialog and mistakes what is, in fact, a username being entered, for a password being entered. Such confusion can come about either due to a failure of the event engine's heuristics, or due to deliberate manipulation of the event engine by an attacker.