FirebirdDB
/
firebird
зеркало из https://github.com/FirebirdSQL/firebird.git


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197
							<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
	<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
	<title>Make firebird's SRP implementation current NIST guidance compliant</title>
	<meta name="generator" content="LibreOffice 5.1.6.2 (Linux)"/>
	<meta name="created" content="00:00:00"/>
	<meta name="changed" content="2018-06-20T19:32:59.045535257"/>
	<meta name="DCTERMS.issued" content="2018-04-09T10:14:20.507318741"/>
	<meta name="DCTERMS.language" content="en-US"/>
	<meta name="DCTERMS.modified" content="2018-04-09T10:14:29.569131327"/>
	<meta name="DCTERMS.provenance" content=""/>
	<meta name="DCTERMS.source" content="http://xml.openoffice.org/odf2xhtml"/>
	<meta name="DCTERMS.subject" content=","/>
	<meta name="DCTERMS.title" content=""/>
	<style type="text/css">
		p { margin-left: 0.79in; margin-right: 0.79in; color: #000000 }
		td p { margin-left: 0.79in; margin-right: 0.79in; color: #000000; font-size: 12pt }
		h1 { margin-left: 0.79in; margin-right: 0.79in; color: #000000 }
		h2 { margin-left: 0.79in; margin-right: 0.79in; color: #000000 }
		h2.cjk { font-family: "Noto Sans CJK SC Regular" }
		h2.ctl { font-family: "FreeSans" }
		p.p1 { margin-bottom: 0.1in; font-family: "Liberation Serif"; font-size: 12pt; line-height: 120% }
		p.p4 { margin-bottom: 0.1in; font-family: "Liberation Serif"; font-size: 12pt; line-height: 120% }
		td p.p6 { margin-bottom: 0.1in; font-family: "Liberation Serif"; font-size: 12pt; line-height: 120% }
		p.p5 { margin-bottom: 0.1in; font-family: "Liberation Serif"; font-size: 12pt; line-height: 120% }
		p.p7 { margin-bottom: 0.1in; font-family: "Liberation Serif"; font-size: 12pt; line-height: 120% }
		p.p2 { margin-bottom: 0.1in; font-family: "Liberation Serif"; font-size: 12pt; line-height: 120% }
		p.p9 { margin-bottom: 0.1in; font-family: "Liberation Serif"; font-size: 12pt; line-height: 120% }
		p.p10 { margin-bottom: 0in; font-family: "Liberation Serif"; font-size: 12pt; line-height: 120% }
	</style>
</head>
<body lang="en-US" text="#000000" dir="ltr">
</p>
<h1><a name="a__Replacement_of_use_of_SHA-1_in_the_SRP_Client_Proof_with_a_SHA-2_Message_Digest"></a>
Replacement of use of SHA-1 in the SRP Client Proof with a SHA-2
Message Digest</h1>
<p class="p1">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
(<a href="http://dx.doi.org/10.6028/NIST.SP.800-131Ar1">http://dx.doi.org/10.6028/NIST.SP.800-131Ar1</a>)
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.</p>
<p class="p4">The SHA-256 message digest may be used instead of SHA-1
for generating the Client Proof. Alternatively, SHA-1 (default for
FB3) may is used in FB3.0.4 due to compatibility issues. Default may
be changed in future point releases of FB3! Separate AuthServer and
AuthClient plugins are available for each supported message digest,
with the following names:</p>
<table cellpadding="1" cellspacing="4">
	<tr>
		<td>
			<p align="left">Srp</p>
		</td>
		<td>
			<p align="left">SHA-1 Client Proof</p>
		</td>
	</tr>
	<tr>
		<td>
			<p align="left">Srp256</p>
		</td>
		<td>
			<p align="left">SHA-256 Client Proof</p>
		</td>
	</tr>
</table>
<p class="p5">Both client and server must have an SRP authentication
plugin in common in order to enable successfully authentication of a
user's password. 
</p>
<p class="p5">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.</p>
<p class="p4">The “firebird.conf” default configuration file
entries for AuthServer and AuthClient are now:</p>
<p class="p4">AuthServer = Srp<br/>
AuthClient = Srp, Srp256,
Legacy_Auth (Non -windows clients)<br/>
AuthClient = Srp, Srp256,
Win_Sspi, Legacy_Auth (windows clients)</p>
<p class="p4">With these settings, a Firebird client can use Srp to
authenticate using either SHA-256 or SHA-1 to compute the client
proof and is thus backwards compatible with  Firebird 3 servers. If
you need NIST compliance and/or higher security you can set</p>
<p class="p4">AuthServer = Srp256</p>
<p class="p4">in firebird.conf. This will break compatibility with
pre-3.0.4 clients.</p>
<p class="p7">A deployment where both client and servers support the
legacy Srp (using SHA-1) and the SHA-2 authentication plugin (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.</p>
<h2 class="western"><a name="a__REASON_FOR_CHANGE"></a>REASON FOR
CHANGE</h2>
<p class="p1">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.</p>
<p class="p2">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.</p>
<p class="p2">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.</p>
<p class="p2">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 &nbsp;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).</p>
<p class="p9">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 &lt;<a href="mailto:[email protected]">[email protected]</a>&gt;
(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:</p>
<p class="p10" style="margin-bottom: 0.2in">FIPS 180-2
SHA-224/256/384/512 implementation</p>
<p class="p10" style="margin-bottom: 0.2in">Last update: 02/02/2007</p>
<p class="p10" style="margin-bottom: 0.2in">Issue date: &nbsp;04/30/2005</p>
<p class="p10" style="margin-bottom: 0.2in">https://github.com/ouah/sha2</p>
<p class="p10" style="margin-bottom: 0.2in">&nbsp;</p>
<p class="p10" style="margin-bottom: 0.2in">Copyright (C) 2005, 2007
Olivier Gay &lt;[email protected]&gt;</p>
<p class="p10" style="margin-bottom: 0.2in">All rights reserved.</p>
<p class="p10" style="margin-bottom: 0.2in">&nbsp;</p>
<p class="p10" style="margin-bottom: 0.2in">Redistribution and use in
source and binary forms, with or without</p>
<p class="p10" style="margin-bottom: 0.2in">modification, are
permitted provided that the following conditions</p>
<p class="p10" style="margin-bottom: 0.2in">are met:</p>
<p class="p10" style="margin-bottom: 0.2in">1. Redistributions of
source code must retain the above copyright</p>
<p class="p10" style="margin-bottom: 0.2in">&nbsp; &nbsp;notice, this
list of conditions and the following disclaimer.</p>
<p class="p10" style="margin-bottom: 0.2in">2. Redistributions in
binary form must reproduce the above copyright</p>
<p class="p10" style="margin-bottom: 0.2in">&nbsp; &nbsp;notice, this
list of conditions and the following disclaimer in the</p>
<p class="p10" style="margin-bottom: 0.2in">&nbsp; &nbsp;documentation
and/or other materials provided with the distribution.</p>
<p class="p10" style="margin-bottom: 0.2in">3. Neither the name of
the project nor the names of its contributors</p>
<p class="p10" style="margin-bottom: 0.2in">&nbsp; &nbsp;may be used
to endorse or promote products derived from this software</p>
<p class="p10" style="margin-bottom: 0.2in">&nbsp; &nbsp;without
specific prior written permission.</p>
<p class="p10" style="margin-bottom: 0.2in">&nbsp;</p>
<p class="p10" style="margin-bottom: 0.2in">THIS SOFTWARE IS PROVIDED
BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND</p>
<p class="p10" style="margin-bottom: 0.2in">ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE</p>
<p class="p10" style="margin-bottom: 0.2in">IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE</p>
<p class="p10" style="margin-bottom: 0.2in">ARE DISCLAIMED. &nbsp;IN
NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE</p>
<p class="p10" style="margin-bottom: 0.2in">FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL</p>
<p class="p10" style="margin-bottom: 0.2in">DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS</p>
<p class="p10" style="margin-bottom: 0.2in">OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION)</p>
<p class="p10" style="margin-bottom: 0.2in">HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT</p>
<p class="p10" style="margin-bottom: 0.2in">LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY</p>
<p class="p10" style="margin-bottom: 0.2in">OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF</p>
<p class="p10" style="margin-bottom: 0.2in">SUCH DAMAGE.</p>
</body>
</html>