性能比较：安全性设计选择 使用 .NET 建立分布式应用程序
Priya Dhawan
Microsoft Developer Network
2002年10月
适用于：
Microsoft® ASP.NET
Microsoft® .NET Framework SP1
Microsoft® Windows® 2000 Advanced Server SP2
Microsoft® SQL Server™ 2000 and Enterprise Edition SP2
Microsoft Application Center Test (ACT)
摘要：比较可用于客户端身份验证、散列算法、加密技术和数字签名的各种安全性选项的相对性能。
目录
[URL=http://www.microsoft.com/china/MSDN/library/archives/library/dnbda/html/bdADOtnetarch15.asp#bdadotnetarch15_topic1]简介[/URL]
[URL=http://www.microsoft.com/china/MSDN/library/archives/library/dnbda/html/bdADOtnetarch15.asp#bdadotnetarch15_topic2]测试工具和策略[/URL]
[URL=http://www.microsoft.com/china/MSDN/library/archives/library/dnbda/html/bdADOtnetarch15.asp#bdadotnetarch15_topic3]计算机配置[/URL]
[URL=http://www.microsoft.com/china/MSDN/library/archives/library/dnbda/html/bdADOtnetarch15.asp#bdadotnetarch15_topic4]性能测试结果[/URL]
[URL=http://www.microsoft.com/china/MSDN/library/archives/library/dnbda/html/bdADOtnetarch15.asp#bdadotnetarch15_topic5]小结[/URL]
简介
保护系统安全的设计选择会影响到性能、可缩放性和可用性。通常要在安全性、性能和可用性之间进行权衡。要使系统更安全，就需要在性能和可用性方面做出更多让步。设计一个安全的系统时，需要确定所有可能的威胁、弱点和攻击方式，并根据安全第一、性能第二的原则选择实现安全性的技术。
本文比较了可用于客户端身份验证、散列算法、加密技术和数字签名的各种安全性选项的相对性能。为简单起见，我们将不同类别的安全性分开，并将性能比较限制在每个类别的可用选项内；当然，在实际的安全系统中，整体安全性是由一个或多个类别组成的。
测试工具和策略
在测试过程中，我们使用了 Microsoft Application Center Test (ACT)。它可以对 Web 服务器进行强度测试，分析 Web 应用程序（包括 ASPX 页及其使用的组件）的性能和可伸缩性问题。有关如何创建和运行测试的详细信息，请参阅 ACT 文档。通过打开多个服务器连接并迅速发送 HTTP 请求，Application Center Test 可以模拟大量用户。它还允许我们建立真实的测试方案，在该方案中使用一组随机参数值调用同一个方法。此功能很重要，因为事实上用户不可能使用相同的参数值反复调用同一个方法。还有一个功能非常有用，即 Application Center Test 可以记录测试结果，从而可以提供有关 Web 应用程序性能的重要信息。
ACT 支持基本身份验证、Kerberos 身份验证和简要身份验证，但它不会自动处理 ASP.NET 窗体身份验证。我们明确编辑了请求的主体部分，以模拟客户端窗体提交操作。
我们使用单独的计算机作为域控制器。Active Directory 中包含一万个用户帐户。我们为 Application Center Test 创建了同样多的用户，以便运行测试时 ACT 可以随机选择用户。
计算机配置
下表简要介绍了执行测试所需的测试台配置。
表 1：客户端计算机配置
客户端数量 计算机/CPU CPU 数量 内存 硬盘 软件
1 Compaq Proliant 1130 MHz 2 1 GB 16.9 GB Windows 2000 Advanced Server SP 2
Application Center Test
表 2：Web 服务器配置
服务器数量 计算机/CPU CPU 数量 内存 硬盘 软件
1 Compaq Proliant 1000 MHz 2 1 GB 16.9 GB Windows 2000 Advanced Server SP 2
.NET Framework SP1
表 3：应用程序服务器配置
服务器数量 计算机/CPU CPU 数量 内存 硬盘 软件
1 Compaq Proliant 1126 MHz 2 1 GB 16.9 GB Windows 2000 Advanced Server SP 2
.NET Framework SP1
表 4：数据库服务器配置
服务器数量 计算机/CPU CPU 数量 内存 硬盘 软件
1 Compaq Proliant 700 MHz 4 4 GB 18 GB Windows 2000 Advanced Server SP 2
SQL Server Enterprise Edition SP 2
性能测试结果
吞吐量和滞后时间是关键的性能指标。如果返回数据的数量一定，则吞吐量是指单位时间（通常是 1 秒）内处理的客户端请求数量。由于在某一响应时间吞吐量达到峰值时的可用性可能无法让人接受，因此我们跟踪了滞后时间，利用每次测试后 Application Center Test 生成的测试报告，将其作为响应时间进行测定。
注意：生成的吞吐量和滞后时间性能值仅作为比较这些技术的基础，它们不代表绝对性能。
客户端身份验证
服务器通过接受客户端的凭据并按照指定授权机构验证这些凭据，对客户端进行身份验证。我们主要介绍 Microsoft® ASP.NET 支持的身份验证模式，包括 Microsoft IIS 5.0 身份验证模式和 ASP.NET 窗体身份验证。有关详细信息，请参阅《.NET Framework Developer's Guide》中的 [URL=http://msdn.microsoft.com/library/en-us/cpguide/html/cpconaspnetwebapplicationsecurity.asp]ASP.NET Web Application Security[/URL]（英文）。
获得默认页面
测试包括让某个 ACT 用户向客户发送单个请求。当请求页面时，要求用户提供用户名和密码进行身份验证。用户通过身份验证后，将返回带有一个简单字符串的页面。
注意：本测试中没有建立方案模型，在通过第一个请求的身份验证后，用户通过向 Web 服务器出示某种票据说明自己已获得身份验证来发送后续请求。
图 1：身份验证模式：RPS 和响应时间
注意：
匿名：不执行任何身份验证。
用户帐户存储在 Active Directory 中，Active Directory 位于单独的计算机上，不在 Web 服务器上。
FormsAuth_AD：使用 ASP.NET 窗体身份验证。用户帐户位于 Active Directory 中。
FormsAuth_SQL：使用 ASP.NET 窗体身份验证。用户帐户存储在 SQL Server 2000 中。出于安全性方面的考虑，请不要将密码明文存储在数据库中。应该生成并存储结合了 salt（采用加密算法生成的随机数）的单向用户密码散列，以增加安全性并减少与词典攻击相关的威胁。如果需要存储加密的用户密码，建议选择这种方法，因为它避免了与加密技术相关的密钥管理问题。
正如您所能想到的，匿名身份验证模式（不执行任何身份验证）可以提供最好的性能。Web 服务器不要求客户在浏览 Web 页之前发送用户凭据。如果希望大家都能访问您的站点，则可以选择此模式。
其他身份验证模式都要求客户发送额外的身份验证信息，需要与 Web 服务器之间进行额外的通信。在基本身份验证、简要身份验证和 Kerberos 身份验证中，HTTP 标头流的形式如下所示：
图 2：身份验证标头流
如图 1 所示，虽然简要身份验证模式和 Kerberos 身份验证模式具有不同的系统开销，但它们在性能上十分接近。在简要身份验证中，服务器向客户发送一个质询 (NONCE)，要求客户提供用户名和密码。用单向密码散列（包括正在访问的资源和领域）加密 NONCE，然后将 NONCE 发送到服务器，在服务器上对客户进行身份验证。密码不采用明文发送，与基本身份验证相比，这无疑是一个优点。简要身份验证的最大缺点是，尽管它是一种行业标准，但只有少数浏览器和 Web 服务器支持它，因而不能广泛使用。最先采用它的是 Microsoft® Internet Explorer 5.0 和 IIS 5.0 以及更高版本。它只适用于 Windows 2000 域帐户，还要求帐户将密码存储为加密的明文（注意，这一点与 Microsoft® .NET® Server 不同）。
在 Kerberos 身份验证中，浏览器试图从域登录中使用用户的凭据。如果服务器拒绝这些凭据，将会显示一个对话框，提示客户提供用户名和密码。凭据被直接发送到提供票证许可服务的服务器，由它对凭据进行身份验证并向客户发送一个 Kerberos 票据。此票据是临时的证书，为网络服务器提供识别用户的信息。客户通常会缓存该票据，以便使用它向服务器发送后续请求，直至票据过期。
如图 1 所示，基本身份验证和 FormsAuth_SQL 执行非常类似。在基本身份验证中，客户向 Web 服务器发送用户凭据，然后 Web 服务器与域控制器之间进行一次通信，以验证用户身份。请记住，基本身份验证非常不安全，因为密码是采用明文（实际上采用 base64 编码，非常容易破解）在网络上传输的。要使基本身份验证更安全，可以使用 SSL 建立安全会话。但是，基本身份验证还是不如实时网络身份验证协议（例如 Kerberos 身份验证和简要身份验证）安全，因为后者不会将用户的隐私信息发送给远程服务器。
ASP.NET 窗体身份验证的 HTTP 标头流的形式如下所示：
图 3：身份验证标头流
注意，ASP.NET 窗体身份验证比所有 Windows 身份验证方案都要慢。这可能是因为它在浏览某个页面之前需要进行多次重定向。在 FormsAuth_AD 中，系统以编程的方式在 Active Directory 中查询用户。对于给定密码的用户，如果 Active Directory 中存在对应的用户名，用户即可通过身份验证。与此类似，在 FormsAuth_SQL 中，系统调用 SQL 存储过程在数据库中查询用户。如果查询成功，则用户通过身份验证。我们没有将密码明文存储在数据库中，而是存储了结合 salt 的单向用户密码散列。我们使用了 SHA1 来生成散列。因此在 FormsAuth_SQL 模式中，当用户提交凭据时，系统首先从数据库中检索与该用户关联的散列和 salt。然后利用用户提供的密码和刚刚从数据库中检索到的 salt 生成散列。如果两个散列匹配，则用户通过身份验证。这一过程需要额外的通信，因为我们在对用户进行身份验证时使用了 SHA1 算法来生成散列。
ASP.NET 窗体身份验证与基本身份验证一样不安全，因为密码也是使用明文在网络上发送的。但还是有区别。窗体身份验证只发送一次凭据，此后便使用加密的票据；而基本身份验证的每一次请求都发送凭据。要使窗体身份验证更安全，您可以使用 SSL 建立安全会话，尽管这可能会影响到性能。如果使用不带 SSL 的窗体身份验证，很容易受到重复攻击的破坏。
请参阅 [URL=http://msdn.microsoft.com/library/en-us/dnbda/html/authaspdotnet.asp]ASP.NET: .NET Security Guidance[/URL]（英文）中的“Authentication”，其中讨论了这些身份验证方案的优缺点及其最适合的环境。
加密技术
加密技术利用服务器与客户之间的一个未公开的、预先共享的秘密信息，对在两者之间传输的数据进行加密，以提供数据保密、破坏行为检测和身份验证。我们将着重介绍散列算法（包括 SHA1 和 MD5）、对称算法（包括 DES、RC2、3DES 和 Rijndael）以及非对称算法（包括 RSA 和 DSA）。有关详细信息，请参阅《.NET Framework Developer's Guide》中的 [URL=http://msdn.microsoft.com/library/en-us/cpguide/html/cpconcryptographyoverview.asp]Cryptography Overview[/URL]（英文）。
散列算法
散列算法将任意大小的数据映射到一个较小的、固定长度的唯一值。我们来比较一下 SHA1 和 MD5 算法。有关详细信息，请参阅《.NET Framework Developer's Guide》中的 [URL=http://msdn.microsoft.com/library/en-us/cpguide/html/cpconcryptographyoverview.asp]Cryptography Overview[/URL]（英文）。
ComputeHash
该方法计算文件中存储的数据的散列。我们对大小为 4 KB、135 KB 和 1 MB 的数据进行了测试，以查看数据大小对性能的影响。
图 4：散列算法 (4 KB)：RPS 和响应时间
注意：
.NET Framework 支持各种散列算法，包括 MD5、SHA1、SHA256、SHA384 和 SHA512。各种 SHA 实现之间的唯一差别是它们生成的散列的大小。在测试中，我们只选择了 SHA1 和 SHA512。
我们使用了可以提供各种 SHA1 和 MD5 实现的 System.Security.Cryptography。
在 System.Security.Cryptography 中，只有一种 MD5 实现：MD5CryptoServiceProvider，它包装 CAPI。
在 CryptoAPI 中，当前尚不能使用 SHA256、SHA384 和 SHA512。这些算法直接在托管代码中实现。添加这些算法只是为了支持 AES 的新的密钥生成要求，而不是为了提供比 SHA1 更强大的算法。目前人们认为 SHA1 足以对数据进行散列计算。
对于 SHA1 和 SHA512，我们分别使用了 System.Security.Cryptography 中的托管实现 SHA1Managed 和 SHA512Managed。
如图 4 所示，所有算法的性能都十分接近，只是 SHA512 稍差一些。MD5 生成大小为 128 位的散列。SHA 中的计算过程在很大程度上模仿了 MD5。它生成 160 位散列。
散列越长，越能抵御强烈的攻击。SHA512 生成 512 位散列，SHA1 生成 160 位散列，而 MD5 生成 128 位散列；因此 SHA1 比 MD5 更能抵御强烈的攻击。这种结果还有一个前提，即假设算法本身没有漏洞。
图 5：散列算法 (135 KB)：RPS 和响应时间
随着数据大小的增加，我们看到各种算法之间的性能差异也在变大。在 5 个并发用户下，MD5 比 SHA1 大约快 33%。尽管目前尚没有任何已知方法可以攻击 MD5，但理论上开发出这种手段是可能的。
如果增加处理的数据量，SHA512 的性能会下降。它比 SHA1 大约慢 55%。
请记住，正如前面所讲，散列越长提供的安全性越高，但会使性能降低。
图 6：散列算法 (1 MB)：RPS 和响应时间
随着数据的增加，算法之间性能差异的加大更为明显。
当用户负载为 5 个并发用户时，MD5 比 SHA1 大约快 43%（在其他用户负载下大约快 20%）。SHA1 比 SHA512 大约快 72%。
对称密钥算法
所测试的方法首先加密数据，然后再对其进行解密。我们对大小为 4 KB、100 KB 和 500 KB 的数据进行了测试，观察数据大小对性能的影响。
图 7：对称密钥算法 (4 KB)：RPS 和响应时间
注意：
我们为 System.Security.Cryptography 中的 DES、3DES 和 RC2 使用了托管包装，用以包装 CryptoAPI 中的非托管实现。它们分别是 DESCryptoServiceProvider、TripleDESCryptoServiceProvider 和 RC2CryptoServiceProvider。System.Security.Cryptography 中只有一个 Rijindael 的纯托管实现，测试中使用了它。
算法用来加密和解密数据的密钥和块大小： 算法 密钥大小
（位）
块大小
（位）
DES 64 64
3DES 192 64
RC2 128 64
Rijndael 256 128
3DES、RC2 和 Rijndael 也支持其他密钥长度，但我们选择了每种算法所支持的最大密钥长度来加密和解密数据。攻击较长密钥需要更多时间和精力，从而可以提供更好的防范，这样我们便可以在算法提供最佳安全性时测试算法的性能。
由于增加了密钥的可能组合，较长的密钥更难以破解，因而可以提供更好的安全性。
密钥长度相同（例如 128 位）的不同算法并不一定提供相同的安全性。
对于较小的数据，我们发现 Rijndael，一种 AES（高级加密标准），是所有方法中最快的。它具有各种块长度和密钥长度，可以选择 128、192 或 256 位中的任意一种。它还具有可变数目的迭代循环以生成密文，这取决于密钥长度和块长度。
DES 使用 64 位密钥、64 位块来加密和解密数据。每个数据块迭代 16 次以生成加密文本。虽然它比 3DES 和 RC2 快，但是较短的密钥长度使得它易于被破解。随着当今计算机的速度越来越快，功能越来越强大，该算法也显得日益脆弱。
Triple DES (3DES) 是为提高 DES 的安全性而发明的，它使用三种不同的密钥进行三次 DES 加密。（注意，使用同一个密钥对数据进行三次加密是没有任何意义的。）它虽然只是 DES 的另一种模式，但是具有很高的安全性，因而在性能方面也要慢一些。3DES 采用 192 位密钥，该密钥被分成三个 64 位子密钥并用于加密过程。加密过程与 DES 完全相同，只是重复三次，使之更安全。首先用第一个子密钥对数据进行加密，然后用第二个子密钥进行解密，最后用第三个子密钥再次加密。
当加密的数据比较小时，RC2 是最慢的方法。它需要预先进行耗时的计算以生成一个依赖于密钥的表，当加密较小数据时，成本显然过高。RC2 是一种密钥长度可变的对称块加密算法，用来替代 DES。
图 8：对称密钥算法 (100 KB)：RPS 和响应时间
通过增加加密和解密数据的大小，我们可以看到与前面的测试完全不同的结果。DES 最快，其次是 RC2，而 RC2 又比 3DES 快大约 20%。注意，前面测试中曾提到，RC2 需要进行耗时的计算以生成依赖于密钥的表，由于增加了数据，这项开销被分摊到更多的数据上。在此测试中，Rijndael 的速度最慢，比 3DES 慢 25%。注意，我们为 Rijndael 加密使用了 256 位密钥，这使得它比其他方法更安全（尽管仍存在一些针对 Rijndael 的攻击压力，但在抵御强烈攻击方面要好一些），同时也使得它的速度最慢。与此类似，我们为 3DES 使用了 192 位密钥，这比用于 DES 和 RC2 加密的密钥要长一些。
需要再次指出的是，对于不同的算法，使用相同长度的密钥并不一定意味着它们将具有相同的安全性。不同算法具有不同的特点，因此不可能提供相同的安全性。
正如本文前面所提到的，安全性和性能通常是相互矛盾的。在选择适当的算法保护数据之前，您需要了解数据的重要性、部署成本并权衡可用性和性能。如果所要保护的数据很重要，则必须考虑牺牲一点性能来保证数据的安全。否则，则最好使用安全性较低的算法。
图 9：对称密钥算法 (500 KB)：RPS 和响应时间
随着加密和解密数据的增加，尽管不同算法之间的性能差异更为显著（3DES 和 Rijndael 之间除外），但在这次测试中还是能够看到相同的趋势。
非对称密钥算法
使用非对称密钥算法进行加密速度非常慢，尤其是当数据比较大时；因此它们不能用于大批量加密。大批量加密应该使用对称算法。非对称算法可以用来进行密钥交换。
两种常用的非对称算法是 RSA 和 DSA。RSA 可用于加密和生成签名，而 DSA 只能用于生成签名。我们根据生成数字签名的速度和验证签名的速度，对 RSA 和 DSA 算法进行了比较。
创建签名
图 10：创建签名 (100 KB)：RPS 和响应时间
注意：
我们使用了 System.Security.Cryptography 中的 RSACryptoServiceProvider 和 DSACryptoServiceProvider，它们分别是由 CryptoAPI 提供的非托管 RSA 实现和非托管 DSA 实现的托管包装。
RSA 使用 1024 位密钥。
DSA 使用 512 位密钥。
如图 10 所示，DSA 生成数字签名的速度比 RSA 快 29%。在 RSA 数字签名过程中，私有密钥仅用于加密消息摘要。被加密的方法成为数字签名。
虽然与 RSA 类似，但 DSA 不使用私钥加密消息摘要，也不使用公钥解密消息摘要。相反，DSA 使用特殊的数学函数生成数字签名，该签名由两个 160 位数字组成，这两个数字是从消息摘要和私钥中派生出来的。
图 11：创建签名 (500 KB)：RPS 和响应时间
随着数据的增加，DSA 仍然比 RSA 快。
验证签名
图 12：验证签名 (100 KB)：RPS 和响应时间
验证数字签名时，结果刚好相反。RSA 比 DSA 大约快 29%。RSA 使用公钥验证签名。它从得到的数据中生成一个新的消息摘要，使用发起人的公钥解密原来的消息摘要，然后对解密的摘要与新生成的摘要进行比较。如果两个摘要匹配，则消息的完整性得到验证。发起人的标识也得到确认，因为公钥只能解密使用对应私钥加密的数据。
DSA 也使用公钥来验证签名，但验证过程比 RSA 更复杂。
图 13：验证签名 (100 KB)：RPS 和响应时间
随着数据的增加，两个算法之间的性能差异变得越来越小，可以忽略不计。
小结
从这些测试中可以看出，身份验证方案、散列算法和加密技术需要不同数量的系统开销，因此在性能方面存在很大差异。传递给散列算法和加密技术的数据大小也非常重要。
当设计一个安全系统时，应该根据安全第一、性能第二的原则来选择实现技术。例如，不带 SSL 的基本身份验证可以获得较好的性能，但是，不管它的速度有多快，如果不能降低系统受到攻击的威胁，则对于该系统并没有什么用处。
本文没有包含身份验证与数据加密相结合的整体性能影响，而这是实际系统中采用的安全保护方式。根据所采用的各种方案的不同组合，一个安全系统的性能也会随之变化。
[返回] 中文XML论坛 - 专业的XML技术讨论区 →
XML.ORG.CN讨论区 - 高级XML应用 → 『 XML安全 』 → SSL/Kerberos/MD5/SHA1/SHA512/DES/3DES/RC2/Rijndael/RSA/DSA等的性能比较[转帖]
(订阅本版)
2006/2/17 22:54:00
新浪微博
SSL/Kerberos/MD5/SHA1/SHA512/DES/3DES/RC2/Rijndael/RSA/DSA等的性能比较[转帖]
