# Replacement of use of SHA-1 in the SRP Client Proof with a SHA-2 Message Digest

The Firebird implementation of the Secure Remote Protocol (SRP) for password based user authentication has been updated following a security review of the original Firebird SRP-6a implementation taking into account current NIST guidance on the use of SHA-1 – see NIST Special Publication 800-131A, Revision 1, Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths (http://dx.doi.org/10.6028/NIST.SP.800-131Ar1) chapter 9. This guidance disallows the general use of SHA-1 for “Digital Signature Generation” whilst permitting continued use for “Digital Signature Verification”. The background to making this change is given below.

By default, the SHA-256 message digest is now used instead of SHA-1 for generating the Client Proof. Alternatively, SHA-1 (deprecated and for legacy use only) may be used for the Client Proof. Separate AuthServer and AuthClient plugins are available for each supported message digest, with the following names:

Srp | SHA-1 Client Proof
Srp256 | SHA-256 Client Proof

Both client and server must have an SRP authentication plugin in common in order to enable successfully authentication of a user's password.

There is no change to the SRP User Manager. This is still called (“Srp”) and the User Manager and the security database are not affected by the choice of message digest used to compute the client proof.

The “firebird.conf” default configuration file entries for AuthServer and AuthClient are now:

AuthServer = Srp256
AuthClient = Srp256, Srp, Legacy_Auth (Non -windows clients)
AuthClient = Srp256, Srp, Win_Sspi, Legacy_Auth (windows clients)

With these settings, a Firebird Server is using Srp256 to authenticate a client using SHA-256 to compute the client proof and is thus compatible with Firebird 3.0.4 or newer clients. On the other hand, a Firebird client will authenticate the user with any server version down to at least 2.5.

A deployment where both client and servers support the legacy Srp (using SHA-1) and one or more of the SHA-2 authentication plugins (e.g. Srp256) should be avoided. This is because an attacker might be able to disrupt the Srp256 authentication thereby forcing Firebird to use the weaker Srp SHA-1 client proof without the user being aware.

## REASON FOR CHANGE

Review of the Firebird SRP implementation appears to indicate that most uses of SHA-1 continue to be permitted under NIST guidance except for its use in generating the client proof. The SRP client proof may be characterised as a “Poor Man's Digital Signature” in that it provides a two party proof of identity rather than the third party proof normally expected from a Digital Signature i.e. it is not a non-repudiable proof. Nevertheless, it is believed that generation of the client proof falls under the heading of “Digital Signature Generation” when considering the NIST Guidance.

Continued use of SHA-1 in order to generate the client proof appears to risk leakage of the encryption key used to encrypt “over-the-wire” encryption and which hence also provides peer entity authentication during the lifetime of the connection. This may result in an attacker being able to monitor confidential communication either during the connection or at some later date and this could include leakage of an encryption key used to encrypt the user database, if this is passed from client to server during the connection.

Such an attack is viable if weaknesses in SHA-1 can be exploited to allow a brute force attack on the client proof to be computationally feasible. All parts of the message on which the client proof is based may be known to an attacker with the exception of the shared session key and such an attack would concentrate on revealing this key. If it were possible to reveal the shared session key in real time then additionally a man-in-the-middle attack would be feasible.

The severity of this issue is viewed as Important but not Critical. Users that rely on SRP (using SHA-1)/over the wire encryption to protect confidential communication have a long term risk that the confidentiality of their data may be compromised. The attack may also be mitigated through the use of other procedures to protect communications (e.g. a secure VPN).

The update adds a new directory to the source code tree (src/common/sha2) containing an implementation of the SHA-2 family of message digests derived from the implementation published by Olivier Gay <olivier.gay@a3.epfl.ch> (see https://github.com/ouah/sha2). The following copyright notice is included at the request of the original author and applies to the files in src/common/sha2:

FIPS 180-2 SHA-224/256/384/512 implementation

Last update: 02/02/2007

Issue date: 04/30/2005

https://github.com/ouah/sha2

Copyright (C) 2005, 2007 Olivier Gay <olivier.gay@a3.epfl.ch>

All rights reserved.

Redistribution and use in source and binary forms, with or without

modification, are permitted provided that the following conditions

are met:

1. Redistributions of source code must retain the above copyright

notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright

notice, this list of conditions and the following disclaimer in the

documentation and/or other materials provided with the distribution.

3. Neither the name of the project nor the names of its contributors

may be used to endorse or promote products derived from this software

without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND

ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE

IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE

ARE DISCLAIMED. IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE

FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL

DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS

OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)

HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT

LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY

OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF

SUCH DAMAGE.