Eloquence B.07.10 Release Notes - Database
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:
This specifies the number of failed login attempts before imposing a delay on subsequent login attempts. The default is 0 to disable this function.
This specifies the number of failed login attempts before rejecting subsequent login attemts. The default is 0 to disable this function.
Number of seconds to remember recently failed login attempts. A previous lockout will also be reset after this time if no further login attempts happened during this period. The default value is 60 seconds.
Number of seconds to delay subsequent login attempts after encountering LoginFailCount1 failures. The default value is 5 seconds.
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
The following defaults are used:
For example:
[db-access] allow = 127.0.0.1This restricts access to the database to the local system and is the default.
[http-access] allow = allThis 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.106This 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.