Reducing the Risk of Brute Force attacks used to reveal Firebird User Passwords [CORE5789]

[firebird-automations]

Submitted by: Tony Whyman (twhyman)

Votes: 1

User authentication mechanisms such as SRP are already resistant to brute force attacks where an attacker cycles through many different passwords in an attempt to login to a user account. However, a brute force attack will always succeed given a long enough period in which to sustain the attack. It is thus important that attackers are given limited windows of opportunity in which to conduct a brute force attack.

At present, it appears that Firebird allows a user an unlimited number of failed login attempts and without reporting a possible brute force attack. The only mitigation to brute force attacks appears to be an eight second delay inserted after every fourth failed login (see src/remote/server/server.cpp in the Firebird source tree). This still allows an attacker to cycle through 60/8 * 4 * 60 * 24 = 43200 failed logins per day. That is after only four days or so an attacker could cycle through all 171,476 words in the Oxford English Dictionary.

Given that Firebird does not enforce any rules for password selection, the tendency for users to select common passwords, the availability of dictionaries of well used passwords and the lack of any alert sent to a DBA to warn about an attack, it probably will not take many days to break a Firebird user's password and without anyone being aware that this has been done. There is a need both to log failed login attempts, so that a System Administrator is aware of a possible attack, and to rate limit login attempts in order to frustrate the attacker.

CORE5786 has reported the need to record failed login attempts in a suitable log file.

Additionally, Firebird should also implement some form of advanced rate limiting to restrict the rate of failed login attempts for a given user. This might be by:

* Inserting a delay time between receiving a failed login request and reporting the failure to the client.

* An exponential increase in the delay time for each successive failed login between receiving a failed login request for a given user and reporting the failure to the client.

* Rate limiting the total number of failed login attempts for each user from a given remote system during a given period to a configurable number.

[firebird-automations]

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov \[ alexpeshkoff \]

[firebird-automations]

Commented by: @AlexPeshkoff

Exponential increase is good measure. But telling true I'd much better like the more generic way to solve this problem suggested by James Starkey a few years ago.

https://sourceforge.net/p/firebird/mailman/message/34382044/

Details of implementation may vary (for example no need storing vault on client box, it can be sent to him during auth process) but the overall idea is to make authentication immune even in a case when whole security database is stolen. Looks like with this suggestion implemented we will need blacklisting by IP/login only to avoid DoS attack.

[firebird-automations]

Commented by: Tony Whyman (twhyman)

>Exponential increase is good measure. But telling true I'd much better like the more generic way to solve this problem suggested by James Starkey a few years ago. My first observation is that I see no problem in having multiple layers of protection when it comes to resisting brute force attacks. The second is that exponential backoff is something that can be part of the Remote Provider and hence common to all authentication plugins, while password vaults or similar are something that is part of a specific authentication plugin.

Looking at the existing code, adding exponential backoff should be a straightforward enhancement to what is already there and can be rolled out quickly. I would just get on with this and then look for a good password vault algorithm.

I assume that Jim's idea is not that different from SSH passphrase protected RSA keys. This works very well but the SSH implementation requires the private key to be available on each client system that you may want to use. It does not readily allow a user to log in from any client system that is available to them. That is more secure by less flexible. A good candidate for an alternative plugin but not necessarily suitable for all users and hence why I would still prefer a common solution.