New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposed Security Patch: Replacement of use of SHA-1 in the SRP Client Proof with SHA-256 [CORE5788] #6051
Comments
Commented by: Tony Whyman (twhyman) Patch to Firebird 3.0.3 source code tree |
Modified by: Tony Whyman (twhyman)Attachment: srp_sha256.patch [ 13234 ] |
Modified by: @AlexPeshkoffassignee: Alexander Peshkov [ alexpeshkoff ] |
Commented by: @AlexPeshkoff > The SRP client class is modified to use only SHA-256 for generating the client proof. > The SRP server class is modified to use either SHA-1 or SHA-256 for verifying the client proof, with the verification method depending on the length of the client proof. I suggest you to leave current SRP plugin as is and add instead new one, with enhanced security. |
Commented by: Tony Whyman (twhyman) > Does it mean that with suggested change fbclient 3.0.4 will not be able to attach to server 3.0.3 ? >That's OK. But what modification of SHA is used to work with stored on the disk hashes? Will old passwords work for new server/client pair? For new server with old client? >I suggest you to leave current SRP plugin as is and add instead new one, with enhanced security. On the other hand, if you retain a legacy SRP client in place then it becomes all too easy for a client to be mis-configured to use the legacy client rather than the updated version and as there is no server logging mechanism for a DBA to monitor whether clients are using SHA-256, there is no easy means to ensure that clients are up-to-date. |
Commented by: Tony Whyman (twhyman) I also thought it useful to pre-empt the question on why it is not necessary to replace SHA-1 in computation of the password verifiers with the following explanation: The SRP password verifier is computed as: <password verifier> = v = g^x mod N where x = H(<salt>, H( I, ':',<raw password>)) and H() is the hash algorithm. as such, the password verifier is protected from attack by the intractability of the Discrete Logarithm Problem in that while the computation of v = g^x mod N is computationally feasible in a reasonable time, the inverse i.e. computing the logarithm (base g) of v mod N is not computationally feasible. Therefore SHA-1 is not being relied upon to protect the password. It is simply used as a message digest and I see no reason to propose its replacement. The double hash in the SRP password verifier appears to be a Firebird local choice and I not sure why this was done. |
Commented by: @AlexPeshkoff > As long as users upgrade their server software first and then their clients then they will not have an issue. > On the other hand, if you retain a legacy SRP client in place then it becomes all too easy for a client to be mis-configured to use the legacy client rather than the updated version and as there is no server logging mechanism for a DBA to monitor whether clients are using SHA-256, there is no easy means to ensure that clients are up-to-date. I can't agree that there are absolutely no ways to check who is using old auth plugin, for example: MON$USER SYSDBA DBA who really needs to avoid old plugin can just remove it from firebird.conf. > Note that there is no proposed change to the SRP User Manager ... |
Commented by: Tony Whyman (twhyman) >Very good - 2 different AuthServer plugins will share same security database and manager for it, no problems with this. Our code is 100% ready for it. The issue is over whether there is one or two AuthClient plugins: one for SHA-1 and one for SHA-256. If you look at the patch, there is a single line change to the code between the original SHA-1 version and the SHA-256 version (+selecting a different header file). If would be easy enough to have common source code for both plugins with an ifdef used to select which client proof is generated. As to having two AuthClient plugins - one for legacy SHA-1 and one for SHA-256 - I am not going to object that strongly. It does however have to be carefully documented so that DBA's can configure their clients properly. The one thing I would strongly object to is a scenario where a client first tried SHA-256 and then SHA-1 if that did not work. This is because this opens up a well known attack strategy where an attacker deliberately blocks the "good" SHA-256 exchange in order to solicit the "weak" SHA-1 exchange. |
Commented by: @AlexPeshkoff > The one thing I would strongly object to is a scenario where a client first tried SHA-256 and then SHA-1 if that did not work. This is because this opens up a well known attack strategy where an attacker deliberately blocks the "good" SHA-256 exchange in order to solicit the "weak" SHA-1 exchange. That's one of the reasons why there should not be universal SRP on server (even compliant with NIST guidelines) - only with correct server configuration admin may be sure that such scenario is not taking place. Trying to ensure something on client is not a way to go. |
Commented by: Tony Whyman (twhyman) OK, its easy enough to have two servers and I suppose that a DBA can always configure use of both. Again, the documentation needs to be very clear if you want to do this. |
Commented by: Tony Whyman (twhyman) Updated patch attached with separate AuthClients and AuthServers for SHA-1 and SHA-256 client proofs I have updated the proposed patch to use template classes to avoid code duplication between the different plugins. This made it trivial to add clients and servers for the other SHA-2 hashes and hence it defines clients/servers for Srp (SHA-1), Srp224 (SHA-224), Srp256, Srp384 and Srp512. The default server set is Srp256, Srp and the default client is Srp256. The default result is the same as for the earlier patch. The difference is that the DBA can now configure the combination of Srp client and server plugins that they deem suitable. The patch also includes a proposed README file and updated http://Firebird.conf.in. |
Modified by: Tony Whyman (twhyman)Attachment: srp_sha256_v2.patch [ 13235 ] |
Commented by: @AlexPeshkoff Tony, just to make sure - is proposed SHA* implementation OK for non-intel CPUs? |
Commented by: @AlexPeshkoff Patch brings authentication subsystem into non-working state, login is impossible, i.e. appears it was never tested by author. |
Commented by: Tony Whyman (twhyman) It was tested. Have you remembered to update the "firebird.conf" file as described in the document update? |
Commented by: @AlexPeshkoff It was new clean build and firebird.conf was default. Srp256 did not start at all (though was present in plugins list). So client had only Legacy_Auth loaded but server - only Srp, that's why no handshake. |
Commented by: Tony Whyman (twhyman) I tested the patch with 3.0.3. Which build did you apply it to? There may be a conflict with another patch. |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Commented by: @hvlad Alex, patch works for me (while it was a puzzle of how to apply it). SQL> show version; SQL> select * from mon$attachments where mon$system_flag = 0; MON$ATTACHMENT_ID 759 |
Commented by: @AlexPeshkoff OK, I will try it once again. |
Commented by: @AlexPeshkoff The reason of a bug was badly written function After fixing this code patch works for me, I apply it with modified according to FB backward compatibility rules set of plugins. |
Commented by: @AlexPeshkoff Status of Srp256 plugin in FB3 & FB4. In master branch Srp256 (with enhanced security) becomes single default authentication plugin. That means that with default configuration clients earlier than FB 3.0.4 will be not able to attach to FB4. This should not be severe problem - hopefully most of clients will be upgraded when FB4 is released. In B3_0_Release default plugin is old Srp - I've decided not to break compatibility with existing clients in point release. Hope that fits requirements of most users. People who need enhanced security should upgrade all clients to at least 3.0.4 and set In all cases hashes stored in security database are fully compatible between Srp & Srp256, i.e. security.db does not require any upgrade. |
Modified by: @AlexPeshkoffstatus: Reopened [ 4 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 4.0 Beta 1 [ 10750 ] Fix Version: 3.0.4 [ 10863 ] |
Commented by: Tony Whyman (twhyman) >>Tony, just to make sure - is proposed SHA* implementation OK for non-intel CPUs? It should be. The original author of the SHA2 code has claimed "The implementation has been tested on numerous UNIX systems and on both little endian and big endian platforms." I have only be able to verify this on intel platforms and hopefully someone else will confirm the above is true. |
Commented by: Tony Whyman (twhyman) >>The reason of a bug was badly written function >>You returned a pointer to on-stack object that is destroyed by stack of later calls. I always preferred Pascal reference counted strings anyway ;) |
Modified by: @mrotteveel |
Submitted by: Tony Whyman (twhyman)
Block progress on JDBC536
Attachments:
srp_sha256.patch
srp_sha256_v2.patch
Votes: 1
This proposed patch results from a security review of the 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".
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 shared session 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. This is because (a) users that comply with NIST Guidance as a matter of policy may feel unable to use Firebird/SRP and hence choose or migrate to a different database, and (b) users that rely on SRP/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 patch 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 <mailto:olivier.gay@a3.epfl.ch> (see https://github.com/ouah/sha2). This has been adapted for Firebird as a set of classes that follow the model of the existing Firebird::Sha1 class. Classes are provided for SHA-224, SHA-256, SHA-384 and SHA-512. A SHA-2 compliancy confidence test is also included.
The SRP RemotePassword class is modified to additionally include a method for generating a client proof using SHA-256 as the message hash.
The SRP client class is modified to use only SHA-256 for generating the client proof.
The SRP server class is modified to use either SHA-1 or SHA-256 for verifying the client proof, with the verification method depending on the length of the client proof. This is believed to be compliant with NIST Guidance for legacy use of SHA-1 and permits backwards compatibility with older clients.
The patch also modifies the makefiles for posix builds in order to include the SHA-2 classes in the "common" library and has been tested on Linux. It may be necessary to modify the build procedures for other platforms in order to use the patch.
It is proposed that this patch is expedited into the next step release of Firebird 3 and which should be made available as soon as possible.
Commits: 54bf8a3 406b169 b9a93f5
The text was updated successfully, but these errors were encountered: