EQ Eloquence B.07.10 Release Notes - Database
Overview / Security Enhancements

Security Enhancements

Eloquence B.07.10 security improvements include:


Lockout users after repeated failed login failures

The Eloquence database internally stores any passwords in an encrypted format (using a suitable oneway hash function). In addition, passwords are encrypted before transmitted the over the network.

However this does not protect the database against the use of weak passwords.

To provide additional protection against attempts to "guess" database passwords, repeated login failures are output to the log file and, in addition, may result in delaying or rejecting subsequent login attempts from the same user.

A user in this context is defined by IP address and operating system specific login.

When enabled, the server maintains information on recently failed login attempts. As a consequence of multiple failed login attempts, further logins could be delayed or rejected. After a configurable period the user lockout is reset automatically.

The following new configuration items are supported in the [Server] section:

For example:

 # Impose delays after 3 repeated login failures
 LoginFailCount1 = 3

 # Lockout user after 5 repeated login failures
 LoginFailCount2 = 5

 # Number of seconds to remember last failed login attempt
 LoginFailTimeout = 300

 # Cause a 5 second delay after LoginFailCount1 attempts
 LoginFailDelay = 5

This configuration will impose a 5 second delay after 3 failed login attempts and lockout the user for the next 5 minutes after 5 failed attempts.


Enable/restrict database access by IP address

The database server was enhanced to allow selectively enabling or restricting access by IP address.

While a firewall or packet filter would typically be used to enable/block access to the database from remote systems, the Eloquence database also provides a simple way to restrict access from the network.

Access to the database or the http status may be specified for a range of IP addresses.

The following new configuration items are supported in the new [db-access] and [http-access] sections:

 {allow|deny} = {All | ip-address [/ [netmask | addrbits]]}

Where

If overlapping definitions are specified the most specific definition applies (based on unmasked bits in netmask). Unless specifically allowed, the access is denied.

The following defaults are used:

For example:

 [db-access]
 allow = 127.0.0.1
This restricts access to the database to the local system and is the default.

 [http-access]
 allow = all
This enables access to the http status for any remote system and is the default.

 [db-access]
 allow = 127.0.0.1
 allow = 194.64.71.0/24
 deny = 194.64.71.106
This enables access to the database for the local system and the IP addresses from the 194.64.71.0/24 network except the system with the IP address 194.64.71.106.


No longer return encoded passwords to unprivileged users

The server has been modfied to no longer return the encoded password for unprivileged users. Previously, the dbdumpcat utility could be used to retrieve encoded database passwords.
Unless the user has the dba/uadmin privilege only the encoded password for the current user is returned, for other users a dummy value is returned if a password exists.

This change is intended to make it harder to obtain the encoded passwords form the database with an unprivileged account. Eloquence passwords are stored encoded by a one-way hash function and can't be retrieved with a reasonable effort. However a poorly choosen password could be guessed (eg. comparing words from a dictionary) and compared against the encoded value.


Enable user to change own password

The database server and the dbutil utility were enhanced to allow a user (other than "public") to change the own password. In previous versions changing a user password was a privileged operation and required the dba/uadmin privilege.

The following syntax option was added to the dbutil utility in addition:

 CHANGE PASSWORD TO "whatever";

This may be used to change (or remove) the password of the current user. As an alternative, the previous syntax may also be used but requires the specified user matches the current user.



© 2006 Marxmeier Software AG - 2006-01-04