简介
XML 已经成为一种用于在因特网上交换数据的有价值机制。SOAP，这种发送 XML 消息的方式，促使进程以一种前所未有的方式相互通信，而 UDDI 看起来正在快速成为整合 Web 服务的供应商和用户的标准；服务本身是 XML 以 WSDL （即“Web 服务描述语言”）形式描述的。如果没有 XML，将不可能有这种灵活性和能力，并且，正如许多人所说的，将有必要发明元语言。

安全性领域是另一个快速增长的领域。在不同团体之间建立信任的传统方法在公共因特网上已不合适，实际上，在大型 LAN 和 WAN 上也不合适。在这些情况下，基于非对称密码术的信任机制可能会非常有用，但实际上，部署和密钥管理的方便性、互操作性的范围和提供的安全性远不如各种的“公钥基础设施”（Public Key Infrastructures (PKI)）的热情的供应商曾让我们相信的那样。处理层次数据结构，以及带有机密、访问权限或完整性等不同需求的数据的子集特别困难。另外，具有不同于 XML 文档的现今标准安全性控制的应用程序一点都不简单。

目前，一些团体正积极投身于检查这些问题和开发标准的活动中。其中主要的相关开发是 XML 加密和相关的 XML 签名、“可扩展访问控制语言（XACL）”和相关的“安全性断言标记语言（SAML — 以前是互为竞争对手的 AuthML 和 S2ML 的结合）”。所有这些都由 OASIS 和“XML 密钥管理规范（XKMS）”驱动。本文将 介绍 XML 加密和 XML 签名。

“XML 安全性套件”
部分原因是由于这些标准仍处于发展阶段，因此，开发人员可用的工具集和库的数量仍然有限，但十分确信的一点是，这正在开始发生变化。IBM 已经向“Java 社区过程（JCP）”提交了两种相关的“Java 规范请求（JSR）”。它们是 JSR-105、“XML 数字签名 API”和 JSR-106、“数字加密 API”。
“IBM 东京研究实验室”在 1999 年开发了“XML 安全性套件”作为 XML 签名的原型实现。它包含一些自动生成 XML 数字签名、实现 W3C 的“规范”XML 工作草案，以及通过 XML 加密的实验性实现来提供元素级加密的实用程序。它还提供一种在应用到 XML 文档时处理安全性特定要求的方式。还引入了“可扩展访问控制语言（XACL）”的 XML 模式定义。

developerWorks 有一篇 Doug Tidwell 著的文章详细讲述了该套件，可在 alphaWorks 站点获得该套件的最新版本。（请参阅参考资料。）

XML 加密和 XML 签名
象其它任何文档一样，可以将 XML 文档整篇加密，然后安全地发送给一个或多个接收方。例如，这是 SSL 或 TLS 的常见功能，但是更令人感兴趣的是如何对同一文档的不同部分进行不同处理的情况。XML 的一个有价值的好处是可以将一整篇 XML作为一个操作发送，然后在本地保存，从而减少了网络通信量。但是，这就带来了一个问题：如何控制对不同元素组的授权查看。商家可能需要知道客户的名称和地址，但是，无需知道任何正在使用的信用卡的各种详细信息，就像银行不需要知道购买货物的详细信息一样。可能需要防止研究人员看到有关个人医疗记录的详细信息，而管理人员可能正好需要那些详细信息，但是应该防止他们查看医疗历史；而医生或护士可能需要医疗详细信息和一些（但不是全部）个人资料。

密码术现在所做的远远不止隐藏信息。消息摘要确定文本完整性，数字签名支持发送方认证，相关的机制用于确保任何一方日后无法拒绝有效事务。这些都是远程交易必不可少的元素，现在，用于处理整个文档的机制开发得相当好。

有了一般的加密，对 XML 文档整体进行数字化签名不是问题。然而，当需要对文档的不同部分（可能由不同的人）签名，以及需要与选择性的方法一起来这样做时，就会出现困难。也许不可能或者不值得强制不同部分的加密工作由特定人员按特定顺序进行，然而成功地处理文档的不同部分将取决于是否知道这点。此外，由于数字签名断言已经使用了特定专用密钥来认证，所以要小心签名人是以纯文本形式查看文档项的，这可能意味着对由于其它原因而加密的部分内容进行了解密。在另一种情况下，作为更大集合中的一部分，可能对已经加密过的数据进行进一步加密。在牵涉单一 XML 文档（可能由一些不同的应用程序和不同的用户处理在工作流序列中使用的 Web 表单或一系列数据）的事务集中考虑的不同可能性越多，就越可能看到巨大的潜在复杂性。

还有其它问题。XML 语言的强项之一是，搜索是明确的，无二义性的：DTD 或 Schema 提供了相关语法的信息。如果将包括标记在内的文档的一部分作为整体加密，就会丧失搜索与那些标记相关的数据的能力。此外，如果标记本身被加密，那么一旦泄漏，它们将被利用对采用的密码术进行纯文本攻击。

这些是工作组正在考虑的一些方面。

XML 加密示例
XML 加密语法的核心元素是 EncryptedData 元素，该元素与 EncryptedKey 元素一起用来将加密密钥从发起方传送到已知的接收方，EncryptedData 是从 EncryptedType 抽象类型派生的。要加密的数据可以是任意数据、XML 文档、XML 元素或 XML 元素内容；加密数据的结果是一个包含或引用密码数据的 XML 加密元素。当加密元素或元素内容时，EncryptedData 元素替换 XML 文档加密版本中的该元素或内容。当加密的是任意数据时，EncryptedData 元素可能成为新 XML 文档的根，或者可能成为一个子代元素。当加密整个 XML 文档时，EncryptedData 元素可能成为新文档的根。此外，EncryptedData 不能是另一个 EncryptedData 元素的父代或子代元素，但是实际加密的数据可以是包括现有 EncryptedData 或 EncryptedKey 元素的任何内容。

加密工作草案给出了一些示例来演示：加密的颗粒度如何根据要求的不同而不同，以及可能出现什么结果。清单 1 中的代码片断显示了带有信用卡和其它个人信息的未加密 XML 文档。在某些情况下（例如，隐藏支付机制的信息），可能希望加密除客户名称以外的所有信息，清单 2 的代码片断演示了如何这样做。

清单 1. 显示 John Smith 的银行帐户、5000 美元限额、卡号和有效期的的信息

     <?xml version='1.0'?>
       <PaymentInfo xmlns='http://example.org/paymentv2'>
         <Name>John Smith<Name/>
         <CreditCard Limit='5,000' Currency='USD'>
           <Number>4019 2445 0277 5567</Number>
           <Issuer>Bank of the Internet</Issuer>
           <Expiration>04/02</Expiration>
         </CreditCard>
       </PaymentInfo>

清单 2. 除名称之外全部被加密的加密文档

     <?xml version='1.0'?>
       <PaymentInfo xmlns='http://example.org/paymentv2'>
         <Name>John Smith<Name/>
         <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'
          xmlns='http://www.w3.org/2001/04/xmlenc#'>
             <CipherData><CipherValue>A23B45C56</CipherValue></CipherData>
         </EncryptedData>
       </PaymentInfo>

但是，在其它情况下，可能只需要隐藏一些敏感内容 — 可能来自商家或其它第三方 — 清单 3 演示了这点。（请注意，显示了与加密内容相关的标记名。）

清单 3. 只隐藏了信用卡号的加密文档

     <?xml version='1.0'?>
       <PaymentInfo xmlns='http://example.org/paymentv2'>
         <Name>John Smith<Name/>
         <CreditCard Limit='5,000' Currency='USD'>
           <Number>
             <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
              Type='http://www.w3.org/2001/04/xmlenc#Content'>
                 <CipherData><CipherValue>A23B45C56</CipherValue>
                 </CipherData>
             </EncryptedData>
           </Number>
           <Issuer>Bank of the Internet</Issuer>
           <Expiration>04/02</Expiration>
         </CreditCard>
       </PaymentInfo>

可能还有必要加密文档中的所有信息，清单 4 演示了这点。

清单 4. 隐藏了全部内容的加密文档

<?xml version='1.0'?>
       <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
        Type='http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml'>
                <CipherData><CipherValue>A23B45C56</CipherValue></CipherData>
       </EncryptedData>

CipherData 可以封装，也可以引用原始加密数据。在第一种情况下，CipherValue 元素的内容显示原始数据，而在第二种情况，使用 CipherReference 元素，这包括了一个指向加密数据位置的 URI。

规范的 XML
对应用了密码散列算法的消息进行最轻微的更改也会产生不同的值。这为消息完整性方面提供了信任，并适于通常用法，但是也引入了进一步的复杂性 — 两个 XML 文档虽然在逻辑上相等，但可能在确切文本比较中不同。象行定界符、空标记、在属性中使用十六进制而不是名称以及在特定情况下存在注释或注释变体这样的事情都可以成为文档的逻辑结构不受影响而实际彼此不同的实例。规范的 XML 规范描述了一种生成文档的物理表示（也成为范式）的方法，该范式解释允许的变体，以便如果两个文档具有同一范式，则认为两个文档在给定应用程序上下文中是逻辑相等的。

对于加密、特别是数字签名来说，这尤为重要，因为很明显，逻辑上相同的文本变体不应该表示文档的完整性及其发送方的认证是可疑的。用不同工具（譬如，解析器）生成不同文本（并因而生成不同消息摘要）进行处理时也可能发生这样的事。因此，在生成签名和验证计算期间，应该在范式上进行消息摘要。如果摘要匹配，这将确定：即使文本形式可能不同，它们在其上计算的范式也匹配。

XML 签名示例
可以将 XML 签名应用到任意数据内容。那些应用到相同 XML 文档中数据的签名称为封装或被封装的签名，而那些数据在签名元素外部的签名称为 分离签名。清单 5 取自签名候选推荐文档，它是一个简单分离签名的实例。

清单 5. 一个简单分离签名的示例

        [s01] <Signature Id="MyFirstSignature"
                xmlns="http://www.w3.org/2000/09/xmldsig#">
          [s02]   <SignedInfo>
          [s03]   <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/
                  REC-xml-c14n-20010315"/>
          [s04]   <SignatureMethod Algorithm="http://www.w3.org/2000/09/
                  xmldsig#dsa-sha1"/>
          [s05]   <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
          [s06]     <Transforms>
          [s07]       <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-
                      20010315"/>
          [s08]     </Transforms>
          [s09]     <DigestMethod Algorithm="http://www.w3.org/2000/09/
                       xmldsig#sha1"/>
          [s10]     <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
          [s11]   </Reference>
          [s12] </SignedInfo>
          [s13]   <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
          [s14]   <KeyInfo>
          [s15a]    <KeyValue>
          [s15b]      <DSAKeyValue>
          [s15c]        <p>...</p><Q>...</Q><G>...</G><Y>...</Y>
          [s15d]      </DSAKeyValue>
          [s15e]    </KeyValue>
          [s16]   </KeyInfo>
          [s17] </Signature>

实际签名的信息是位于 s02 行和 s12 行之间，即 SignedInfo 元素。在签名的部分中包含用于计算 SignatureValue 元素的算法的引用，而那个元素本身位于签名部分之外（在 s13 行上）。s04 行上的 SignatureMethod 引用的是将规范的 SignedInfo 转换成 SignatureValue 所用的算法。它是密钥相关的算法和摘要算法（在这里是 DSA 和 SHA-1）的组合，可能还具有象填充这样的操作。KeyInfo 元素（在这里位于 s14 行和 s16 行之间 — 该元素是可选的）指出用来验证签名的密钥。

转换
正如前面所提到的，加密、签名、修改和可能进行的更多签名所发生的顺序有很多种可能性。用户可能需要向已经部分加密或部分签名的表单字段中输入更多数据，并且需要能够在不妨碍以后的验证和解密的前提下这样做。为解决这种情况，W3C 最近发布了一个有关 XML 签名的解密转换工作草案。（请参阅参考资料。）

下面这个示例摘自那个文档，它演示了如何建议文档接收方采用正确的解密和签名验证顺序。第一个代码段显示了要签名的文档部分 — order 元素；其中，第 7 行到第 11 行的 cardinfo 元素是关于个人和财务方面的详细信息，它是纯文本，但也存在一些加密数据（第 12 行）。

清单 6. XML 文档中的 order 元素

        [01] <order Id="order">
          [02]   <item>
          [03]     <title>XML and Java</title>
          [04]     <price>100.0</price>
          [05]     <quantity>1</quantity>
          [06]   </item>
          [07]   <cardinfo>
          [08]     <name>Your Name</name>
          [09]     <expiration>04/2002</expiration>
          [10]     <number>5283 8304 6232 0010</number>
          [11]   </cardinfo>
          [12]   <EncryptedData Id="enc1"xmlns="http://www.w3.org/
                 2001/04/xmlenc#">...</EncryptedData>
          [13] </order>

清单 7. 经过签名和进一步加密、且现在显示转换信息的 order 文档

        [01] <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
          [02]   <SignedInfo>
          [03]     ...
          [04]     <Reference URI="#order">
          [05]       <Transforms>
          [06]         <Transform Algorithm="http://www.w3.org/2001/04/
xmlenc#decryption">
          [07]           <DataReference URI="#enc1"
                          xmlns="http://www.w3.org/2001/04/xmlenc#"/>
          [08]         </Transform>
          [09]         <Transform Algorithm="http://www.w3.org/TR/2000/
                       CR-xml-c14n-20001026"/>
          [10]       </Transforms>
          [11]       ...
          [12]     </Reference>
          [13]   </SignedInfo>
          [14]   <SignatureValue>...</SignatureValue>
          [15]   <Object>
          [16]     <order Id="order">
          [17]       <item>
          [18]         <title>XML and Java</title>
          [19]         <price>100.0</price>
          [20]         <quantity>1</quantity>
          [21]       </item>
          [22]       <EncryptedData Id="enc2"
                     xmlns="http://www.w3.org/2001/04/xmlenc#">...</EncryptedData>
          [23]       <EncryptedData Id="enc1"
                     xmlns="http://www.w3.org/2001/04/xmlenc#">...</EncryptedData>
          [24]     </order>
          [25]   </Object>
          [26] </Signature>

第 1 行到 第 26 行的 Signature 元素现在包含前面的 order 元素（位于第 16 行到第 24 行），和以前的加密纯文本 cardinfo（显示在第 22 行这一行中）。有两个转换引用：解密（第 6 行到第 8 行）和规范化（第 9 行）。解密转换指示签名验证器解密除 DataRef 元素中第 7 行指定的数据之外的所有加密数据。解密了第 22 行中的 EncryptedData 元素之后，规范化 order 元素并且恰当地验证签名。

其它相关语言和规范
隐藏 XML 文档中的敏感信息、建立完整性以及认证这些文档的不同部分的来源主要通过遵循加密和签名规范中列出的步骤来处理的，在引用的 W3C 草案中描述该规范（请参阅参考资料）。另外，还有其它紧密相关的领域，例如认证用户或系统、标识授权级别和管理密钥，所有这些都与 XML 安全性相关。

SAML 是一个由 OASIS 驱动的模型，它尝试融合相互竞争的 AuthML 和 S2ML 规范，使认证和授权信息的互换便于进行。“可扩展访问控制标记语言”是与 SAML 紧密相关的，但它更着重于特定 XML 文档的上下文中的面向主题特权对象的安全性模型，它也由 OASIS 指导，又是被称为 XACML 或 XACL（即使在同一些文档中）。通过用 XACL 编写规则，策略制订者可以定义，对于特定 XML 文档和前面所述的情况中的相关事情，由谁来实施哪些访问特权。

W3C 委员会现在正在考虑 XKMS，它打算建立一个位于 XML 签名标准顶部的密钥管理协议。有了 SAML、XACL 和其它倡议，XKMS 是构成应用于 XML 文档的安全性这个大框架中的重要元素。有了它，可以立杆见影地极大简化认证和签名密钥的管理；它通过将数字证书处理功能、撤回状态检查和认证路径位置和验证从所涉及的应用程序分离来做到这点 — 例如，通过把密钥管理委托给因特网 Web 服务。

在满足使用的便利性、可靠性和强健性方面，XML 安全性还有很多路要走。但是目前，正在取得良好的进展。

--
束发读诗书  修德兼修身  仰观与俯察  韬略胸中存
躬耕从未忘忧国  谁知热血在山林  凤兮  凤兮  思高举  世乱时危久沉吟
茅庐承三顾  促膝纵横论  半生遇知己  蛰人感与深
明朝挥剑随君去  羽扇纶巾赴征尘  龙兮  龙兮  风云会  长啸一声舒怀襟
天道常变易  运数杳谁寻  成败在人谋  一诺竭忠悃
丈夫在世当有为  为民播下太平春  归去  归去来兮  我宿愿  余年还做垄畝民

※ 来源:·BBS 水木清华站 smth.org·[FROM: 162.105.30.*]

转载自《VFP网络工作室》 (文/曲景东)

    一、 前 言
　 在 应 用 软 件 中， 数 据 库 管 理 软 件 是 应 用 的 最 广 泛 的 软 件。 数 据 库 管 理 软 件 的 安 全 性、 保 密 性 是 开 发、 应 用 人 员 较 为 关 心 的。 如 何 防 止 无 关 人 员 浏 览 数 据 库， 如 何 防 止 数 据 库 被 非 法 修 改、 破 坏 ？ 常 用 的 方 法 是 给 数 据 库、 管 理 程 序 加 上 密 码。 那 么， 加 了 密 码 就 安 全 了 吗 ？ 怎 样 才 能 使 密 码 安 全 呢 ？
　　二、 传 统 的 密 码 加 密 方 法
　 从dBASE 到dBASEIII ， 从 FOXBASE 到FOXBASE ＋， 从FOXPRO 到VISUAL FOXPRO， 常 用 加 密 码 的 方 法 给 程 序、 数 据 库 加 密。 常 见 的 密 码 有 以 下 几 种： 固 定 密 码， 简 单 加 密 的 固 定 密 码， 加 密 变 化 的 密 码， 具 体 分 析 如 下：
　 1、 固 定 密 码

　 固 定 密 码， 就 是 系 统 只 有 一 个 密 码， 而 且 是 固 定 的， 不 可 变 的。 常 见 于 用Dbase、FOXBASE、FOXBASE ＋、FOXPRO2.X 开 发 的 数 据 库 管 理 系 统。 常 用 如 下 语 句：

I=1
DO WHILE .T.
PWD=SPACE(8)
SET CONS OFF
@12,35 SAY " 口 令!!!"
ACCEPT TO PWD
IF TRIM(PWD)< >"123456"
IF I >=3
@20,32 SAY "口令错误，您不能使用！"
RETURN
ENDIF
@12,30 SAY "第" ＋STR(I,1)+"次口令错！"
I ＝I ＋1
ELSE
@20,28 SAY "欢迎使用本系统！"
EXIT
ENDIF
ENDDO

　 从 以 上 语 句 不 难 看 出， 其 核 心 是： 变 量PWD 与 输 入 值 的 比 较。 密 码“1234” 是 程 序 设 计 时 设 定 的， 以 后 应 用 时 是 无 法 修 改 的， 如 果 修 改， 就 要 改 变 源 程 序。 当 然， 也 可 以 编 写 一 段 子 程 序 用 来 修 改 密 码， 修 改 前， 其 判 断 旧 密 码 是 否 正 确， 也 用 IF TRIM(PWD)< >"123456" 语 句。 其 灵 活 性 很 差， 在pctool 等 工 具 出 现 后， 保 密 性 就 显 得 差 了。

　 2、 简 单 加 密 的 固 定 密 码

　 简 单 加 密 的 固 定 密 码， 是 指 把 密 码 进 行 简 单 的 加 密， 但 密 码 仍 然 是 固 定 的， 不 变 的。 简 单 加 密 一 般 有 两 种：“ 钥 匙 盘” 法 和“ 变 换 法”。“ 钥 匙 盘” 法， 就 是 把 密 码 存 放 在 一 张 软 盘 上， 使 用 时， 把“ 钥 匙 盘” 插 入 计 算 机， 系 统 程 序 读 取 软 盘 中 的 密 码。 或 把 密 码 和 操 作 员 姓 名 存 到 数 据 库 中， 此 数 据 库 存 放 于 软 盘 内， 使 用 时 把“ 钥 匙 盘” 插 入 计 算 机， 系 统 读 取 软 盘 中 的 密 码 和 操 作 员 姓 名， 下 面 是 此 法 的 主 要 语 句：

　 USE A:KLK && 到KLK 数 据 库 内 查 找 输 入 的 操 作 员 的 姓 名；

I=1
DO WHILE .T.
STORE SAPCE(8) TO XM
@ 10,26 SAY "请输入操作员姓名：" GET XM
READ
LOCATE ALL FOR LTRIM(TRIM(XM))=LTRIM(TRIM(NAME))
IF .NOT. EOF()
EXIT &&操作员姓名输入正确，向下执行；
ENDIF
IF I >=3
&&操作员姓名输入计数，输入次数超过3次，退出系统；（代码同前）
…
ENDIF
ENDDO
IF I< 5 &&姓名正确后，比较输入口令正确否；
MKL ＝SPACE(8)
I=1
DO WHILE I< 3
SET CONS OFF
@12,30 SAY " 口令！ ！"
ACCEPT TO MKL
SET CONS ON
IF TRIM(MKL)=TRIM(KL)
EXIT &&口令正确，向下执行；
ELSE
IF I >=3
I=5
EXIT
ENDIF
@12,30 SAY "第" ＋STR(I,1)+"次口令错！"
I ＝I ＋1
ENDIF
ENDDO
ENDIF
IF I=5
@20,32 SAY "口令错误，您不能使用！"
ELSE
@20,32 SAY "欢迎使用！"
ENDIF
RETURN

　 这 种 加 密 方 法 保 密 性 要 好 一 些， 但 每 次 使 用 都 要 用“ 钥 匙 盘” 进 入 系 统， 很 繁 琐。

　 变 换 法， 就 是 通 过 对 密 码 的 运 算， 使 密 码 发 生 变 化 的 方 法， 一 般 采 用 换 算 法， 常 用 的 加 密 语 句 如 下：

　 PSD ＝CHR(65)+CHR(66)+CHR(67)+"9"

　 函 数CHR()， 是 用 来 换 算ASCII 码 的， 换 算 后 的PSD 是ABC9。 用 这 种 简 单 的 换 算， 可 以 避 免 密 码 被 直 接 发 现， 如 果 和 上 述 方 法 混 合 应 用， 保 密 性 就 加 强 了。

　 3、 简 单 加 密 变 化 的 密 码

　 以 上 密 码 都 是 固 定 的， 下 面 介 绍 一 种 经 简 单 加 密 变 换 的 密 码。 这 是 利 用 时 间 函 数 来 加 密 的 算 法， 密 码 每 天 都 不 同。 密 码 由 变 化 的 时 间 和 固 定 字 符 构 成。 其 核 心 语 句 为：

　 kl=DATE()

　 PWD= SUBSTR(CDOW(kl),1,3)+"1234"

　 CDOW() 函 数， 输 入 年 月 日， 返 回 星 期 几（ 字 符 型）。 操 作 者 根 据 今 天 是 星 期 几， 将 星 期 的 前3 个 英 文 字 母 和 固 定 的“1234” 输 入， 与 变 量PWD 比 较。 程 序 会 把 今 天 的 日 期 换 算 成 星 期 数， 然 后 取 前3 位， 并 加 上“1234”， 合 成 今 天 的 密 码 变 量PWD。 这 样 就 实 现 了 每 天 有 不 同 的 密 码。 保 密 性 加 强 了。

　 以 上 几 种 加 密 方 法 都 是 传 统 的 简 单 的 加 密 方 法， 其 特 点 是 简 单、 保 密 性 差， 密 码 单 一， 保 护 能 力 较 低， 主 要 用 于Dbase、FOXBASE、FOXBASE ＋、FOXPRO2.x 中， 由 于 上 述 软 件 的 编 译 不 是 真 正 的 编 译， 其 密 码 容 易 被 发 现。

三、 一 种 新 型 密 码 加 密 方 法
　 以 上 介 绍 的 是 几 种 固 定 的 密 码 加 密 方 法, 下 面 介 绍 一 下 可 变 密 码。“ 可 变 密 码” 指 其 密 码 值 可 由 设 置 自 行 改 变， 这 种 方 法 一 般 由 文 件 保 存 密 码， 且 密 码 经 过 加 密 运 算。 密 码 的 加 密 算 运 算 方 法 很 多， 常 用 的 有： 转 换 法、 位 移 法、 时 间 法、 随 机 法 等。 转 换 法， 就 是 把 输 入 的 密 码 经 过 转 换 计 算， 转 换 成 保 存 密 码， 取 密 码 时， 再 经 过 逆 运 算， 把 密 码 还 原。
　 不 定 时 密 码 也 时 可 变 密 码 的 一 种， 是 指 密 码 的 出 现 是 以 随 机 方 式 来 询 问 用 户。 如： 用 户 在 执 行 两 个 功 能 后 必 须 输 入 密 码， 下 一 次 检 查 密 码 可 能 在 执 行 三 个 功 能 后 检 查 密 码。 这 种 密 码 较 为 隐 蔽。 其 方 法 如 下： 首 先 声 明 一 个 变 量， 用 来 计 数， 是1-5 的 随 机 数； 在 每 一 个 过 程、 函 数、 或 命 令 执 行 前， 累 加 该 变 量 值； 当 该 变 量 值 等 于 其 随 机 值 时， 调 用 密 码 查 询 程 序。

　 下 面 具 体 介 绍 一 种 基 于VFP5.0 的 密 码 设 定 方 法。 其 特 点 是： 具 有 使 用 登 记 功 能； 每 人 一 个 密 码， 并 可 随 时 更 换； 密 码 经 加 密 运 算， 不 易 被 破 解。

　 基 本 思 路 如 下： 首 先 建 立 两 个 数 据 库(table)， 一 个 用 来 存 放 口 令 及 对 应 的 用 户( 称 为“ 口 令 库”)， 另 一 个 存 放 用 户 登 录 使 用 情 况( 称 为“ 登 录 库”)。 在 再 建 立 两 个 窗 口(form)， 一 个 用 来 检 查 口 令， 另 一 个 用 来 修 改 口 令。 接 下 来 定 义 两 个 过 程(procedure)， 一 个 用 来 给 口 令 加 密(“ 加 密 过 程”)， 另 一 个 用 给 口 令 解 密(“ 解 密 过 程”)。 这 个“ 加 密 过 程”， 是 把 密 码 经 加 密 运 算 后 存 入 口 令 库， 而“ 解 密 过 程” 实 际 上 是 把 输 入 的 密 码 经 加 密 运 算 后 与 口 令 库 内 的 密 码 进 行 比 较， 并 不 是 解 密。 为 了 使 密 码 输 入 时 不 被 人 看 见， 要 对 密 码 输 入 的 文 字 框 的 属 性 作 如 下 工 作： 进 入DATA 属 性 栏， 把InputMask 属 性 改 为：XXXXXX， 进 入LAYOUT 属 性 栏， 把PassWordChar 的 属 性 改 为：“*”， 这 样， 输 入 的 密 码 就 不 会 被 别 人 发 现。( 在FOXBASE FOXBASE ＋，FOXPRO2.X 中， 常 用 设 置 背 景 颜 色 与 输 入 密 码 字 符 颜 色 相 同 的 办 法 来 防 止 别 人 看 见。)

　 “ 解 密 过 程” 代 码 如 下：

parameter password
pas=""
n1=asc(substr(name,1,1))
&&取姓名的第一个拼音字母，换算成ASCII码
n2= asc(substr(name,2,1)) &&作为加密的键值
n3= asc(substr(name,3,1))
n=int((n1+n2+n3)/3)
for i=1 to len(trim(password))
&&使用BITXOR()函数对密码进行解密
tempchr=bitxor(asc(substr(password,i,1)),n)
pas=pas+chr(tempchr)
endfor
locate for klk.user_id=name
&&与口令库内的与姓名相对应的口令进行比较
if (klk.key< >pas) and (password< >"hg")
result=.f.
else
result=.t.
endif
return result

　 BITXOR() 函 数 是vfp 特 有 的 函 数， 它 将 函 数 的 两 个 参 数 转 换 成 二 进 制 数， 并 且 执 行“ 与” 操 作， 返 回 一 个 十 进 制 的 结 果。 用 它 来 进 行 加 密 运 算， 保 密 性 强。 加 上 密 码 键 值n( 取 姓 名 的 第 一 个 拼 音 字 母， 经 求 和， 再 取 平 均 值， 再 取 整 运 算， 换 算 成ASCII 码)， 得 到 每 人 一 个 的 密 码。

　 该“ 过 程” 的 定 义 方 法 如 下： 在 定 义 检 查 密 码 的 窗 口(form) 的 编 辑 状 态 下， 用 鼠 标 点 菜 单form， 选“new method”, 键 入“ 过 程” 名。 然 后 双 击 正 在 编 辑 的 窗 口(form), 然 后 进 入" 过 程" 的 编 辑 状 态， 写 入 如 上 代 码。 加 密 过 程 是 解 密 过 程 的 逆 运 算， 代 码 如 下：

parameter password
pas=""
for i=1 to len(trim(password))
n1=asc(substr(name,1,1))
n2= asc(substr(name,2,1))
n3= asc(substr(name,3,1))
n=int((n1+n2+n3)/3)
tempchr=bitxor(asc(substr(password,i,1)),n)
pas=pas+chr(tempchr)
endfor
replace key with pas

　 检 查 密 码 的 思 路 是： 先 到 输 入 姓 名 的 文 字 框 内 取 姓 名， 再 到 口 令 库 内 查 找 姓 名， 如 果 找 不 到 姓 名， 返 回 消 息 窗 口“ 您 不 是 指 定 用 户， 请 与 系 统 管 理 员 联 系 ！”， 系 统 退 出； 如 果 找 到 了 用 户 姓 名， 则 继 续 进 行， 把 输 入 的 口 令 和 姓 名 送 到 解 密“ 过 程” 中 进 行 运 算， 解 密“ 过 程” 将 其 解 密， 并 与 口 令 库 内 的 数 据 进 行 比 较， 如 果 不 正 确， 开 始 计 数， 要 求 重 新 输 入 密 码， 三 次 不 正 确， 退 出 系 统。 如 果 正 确， 释 放 当 前 窗 口， 进 入 系 统。

　 主 要 代 码 如 下：

name=trim(ThisForm.Text1.value)
if empty(name)
a=messagebox
("请输入用户名！",0+48,"信息窗口")
ThisForm.Text1.setfocus
return
endif
pass=trim(ThisForm.Text2.value)
if empty(pass)
a=messagebox
("请输入口令！",0+48,"信息窗口")
ThisForm.Text2.setfocus
return
endif
use klk
locate for klk.user_id=name
if found()=.f.
=messagebox
("你不是指定用户，请与系统管理员联系！",64,"提示信息")
thisform.release
else
ok =Thisform.decode(pass)
if ok=.t.
ThisForm.Label3.caption="欢迎使用！"
wait window '
欢迎使用！按任意键进入“系统维护模块。”'
release thisform
do form wh_wh
else
if m=3
m=m+1
ThisForm.Label3.caption="口令错，您无权使用"
a=messagebox
("对不起，您无权使用！",0+48,"信息窗口")
release thisform
else
a=messagebox
("口令错，请重新输入！",0+48,"信息窗口")
ThisForm.Text2.value=""
ThisForm.Text2.setfocus
m=m+1
endif
endif
endif

　 改 变 密 码 的 思 路 是： 首 先 读 取 用 户 姓 名， 如 果 是 新 用 户 则 请 用 户 输 入 新 密 码， 并 记 录 下 获 得 新 密 码 的 时 间； 如 果 是 老 用 户， 则 读 取 用 户 旧 密 码， 将 旧 密 码 进 行 解 密 运 算 并 和 口 令 库 内 容 比 较， 如 果 正 确， 请 用 户 输 入 新 密 码， 并 将 新 密 码 通 过 解 密 运 算 存 入 口 令 库， 并 记 录 修 改 时 间。

　 主 要 代 码 如 下：

name=ThisForm.Text3.value
oldpass=ThisForm.Text1.value
newpass=ThisForm.Text2.value
if isblank(newpass)
= messagebox("请重新输入新密码！",64,"信息提示")
ThisForm.Text1.setfocus()
return
endif
success=thisform.decode(oldpass)
if not success
= messagebox
("旧密码不正确，重新输入密码！",64,"信息提示")
ThisForm.Text1.setfocus()
return
endif
locate for klk.user_id =name &&new user logo
if found()=.f.
=messagebox("您是新用户！",64,"信息提示")
append blank
replace klk.user_id with name,klk.logo_ddate with date()
thisform.text3.setfocus
endif
thisform.Encode(newpass)
= messagebox
("旧密码已经修改完成，下次请使用新密码！",64,"信息提示")
ThisForm.Command2.setfocus
return

　 注 意， 在 改 变 密 码 的 窗 口(form) 中， 要 定 义“ 加 密 过 程” 和“ 解 密 过 程”， 方 法 如 上 所 述。

　 以 上 是 一 个 加 密 算 法 的 主 要 思 路 和 关 键 代 码， 其 它 部 分 读 者 可 自 行 设 计。 这 个 加 密 算 法 还 可 以 进 一 步 完 善。 如 采 用 不 同 的 函 数 进 行 运 算， 加 入 日 期， 使 每 个 人 每 天 的 密 码 都 不 一 样( 加 入 时 间 的 算 法 如 前 所 述， 利 用CDOW() 函 数 作 为 键 值 的 一 部 分。)。

转载自《VFP网络工作室》 (文/曲景东)

    一、 前 言
　 在 应 用 软 件 中， 数 据 库 管 理 软 件 是 应 用 的 最 广 泛 的 软 件。 数 据 库 管 理 软 件 的 安 全 性、 保 密 性 是 开 发、 应 用 人 员 较 为 关 心 的。 如 何 防 止 无 关 人 员 浏 览 数 据 库， 如 何 防 止 数 据 库 被 非 法 修 改、 破 坏 ？ 常 用 的 方 法 是 给 数 据 库、 管 理 程 序 加 上 密 码。 那 么， 加 了 密 码 就 安 全 了 吗 ？ 怎 样 才 能 使 密 码 安 全 呢 ？
　　二、 传 统 的 密 码 加 密 方 法
　 从dBASE 到dBASEIII ， 从 FOXBASE 到FOXBASE ＋， 从FOXPRO 到VISUAL FOXPRO， 常 用 加 密 码 的 方 法 给 程 序、 数 据 库 加 密。 常 见 的 密 码 有 以 下 几 种： 固 定 密 码， 简 单 加 密 的 固 定 密 码， 加 密 变 化 的 密 码， 具 体 分 析 如 下：
　 1、 固 定 密 码

　 固 定 密 码， 就 是 系 统 只 有 一 个 密 码， 而 且 是 固 定 的， 不 可 变 的。 常 见 于 用Dbase、FOXBASE、FOXBASE ＋、FOXPRO2.X 开 发 的 数 据 库 管 理 系 统。 常 用 如 下 语 句：

I=1
DO WHILE .T.
PWD=SPACE(8)
SET CONS OFF
@12,35 SAY " 口 令!!!"
ACCEPT TO PWD
IF TRIM(PWD)< >"123456"
IF I >=3
@20,32 SAY "口令错误，您不能使用！"
RETURN
ENDIF
@12,30 SAY "第" ＋STR(I,1)+"次口令错！"
I ＝I ＋1
ELSE
@20,28 SAY "欢迎使用本系统！"
EXIT
ENDIF
ENDDO

　 从 以 上 语 句 不 难 看 出， 其 核 心 是： 变 量PWD 与 输 入 值 的 比 较。 密 码“1234” 是 程 序 设 计 时 设 定 的， 以 后 应 用 时 是 无 法 修 改 的， 如 果 修 改， 就 要 改 变 源 程 序。 当 然， 也 可 以 编 写 一 段 子 程 序 用 来 修 改 密 码， 修 改 前， 其 判 断 旧 密 码 是 否 正 确， 也 用 IF TRIM(PWD)< >"123456" 语 句。 其 灵 活 性 很 差， 在pctool 等 工 具 出 现 后， 保 密 性 就 显 得 差 了。

　 2、 简 单 加 密 的 固 定 密 码

　 简 单 加 密 的 固 定 密 码， 是 指 把 密 码 进 行 简 单 的 加 密， 但 密 码 仍 然 是 固 定 的， 不 变 的。 简 单 加 密 一 般 有 两 种：“ 钥 匙 盘” 法 和“ 变 换 法”。“ 钥 匙 盘” 法， 就 是 把 密 码 存 放 在 一 张 软 盘 上， 使 用 时， 把“ 钥 匙 盘” 插 入 计 算 机， 系 统 程 序 读 取 软 盘 中 的 密 码。 或 把 密 码 和 操 作 员 姓 名 存 到 数 据 库 中， 此 数 据 库 存 放 于 软 盘 内， 使 用 时 把“ 钥 匙 盘” 插 入 计 算 机， 系 统 读 取 软 盘 中 的 密 码 和 操 作 员 姓 名， 下 面 是 此 法 的 主 要 语 句：

　 USE A:KLK && 到KLK 数 据 库 内 查 找 输 入 的 操 作 员 的 姓 名；

I=1
DO WHILE .T.
STORE SAPCE(8) TO XM
@ 10,26 SAY "请输入操作员姓名：" GET XM
READ
LOCATE ALL FOR LTRIM(TRIM(XM))=LTRIM(TRIM(NAME))
IF .NOT. EOF()
EXIT &&操作员姓名输入正确，向下执行；
ENDIF
IF I >=3
&&操作员姓名输入计数，输入次数超过3次，退出系统；（代码同前）
…
ENDIF
ENDDO
IF I< 5 &&姓名正确后，比较输入口令正确否；
MKL ＝SPACE(8)
I=1
DO WHILE I< 3
SET CONS OFF
@12,30 SAY " 口令！ ！"
ACCEPT TO MKL
SET CONS ON
IF TRIM(MKL)=TRIM(KL)
EXIT &&口令正确，向下执行；
ELSE
IF I >=3
I=5
EXIT
ENDIF
@12,30 SAY "第" ＋STR(I,1)+"次口令错！"
I ＝I ＋1
ENDIF
ENDDO
ENDIF
IF I=5
@20,32 SAY "口令错误，您不能使用！"
ELSE
@20,32 SAY "欢迎使用！"
ENDIF
RETURN

　 这 种 加 密 方 法 保 密 性 要 好 一 些， 但 每 次 使 用 都 要 用“ 钥 匙 盘” 进 入 系 统， 很 繁 琐。

　 变 换 法， 就 是 通 过 对 密 码 的 运 算， 使 密 码 发 生 变 化 的 方 法， 一 般 采 用 换 算 法， 常 用 的 加 密 语 句 如 下：

　 PSD ＝CHR(65)+CHR(66)+CHR(67)+"9"

　 函 数CHR()， 是 用 来 换 算ASCII 码 的， 换 算 后 的PSD 是ABC9。 用 这 种 简 单 的 换 算， 可 以 避 免 密 码 被 直 接 发 现， 如 果 和 上 述 方 法 混 合 应 用， 保 密 性 就 加 强 了。

　 3、 简 单 加 密 变 化 的 密 码

　 以 上 密 码 都 是 固 定 的， 下 面 介 绍 一 种 经 简 单 加 密 变 换 的 密 码。 这 是 利 用 时 间 函 数 来 加 密 的 算 法， 密 码 每 天 都 不 同。 密 码 由 变 化 的 时 间 和 固 定 字 符 构 成。 其 核 心 语 句 为：

　 kl=DATE()

　 PWD= SUBSTR(CDOW(kl),1,3)+"1234"

　 CDOW() 函 数， 输 入 年 月 日， 返 回 星 期 几（ 字 符 型）。 操 作 者 根 据 今 天 是 星 期 几， 将 星 期 的 前3 个 英 文 字 母 和 固 定 的“1234” 输 入， 与 变 量PWD 比 较。 程 序 会 把 今 天 的 日 期 换 算 成 星 期 数， 然 后 取 前3 位， 并 加 上“1234”， 合 成 今 天 的 密 码 变 量PWD。 这 样 就 实 现 了 每 天 有 不 同 的 密 码。 保 密 性 加 强 了。

　 以 上 几 种 加 密 方 法 都 是 传 统 的 简 单 的 加 密 方 法， 其 特 点 是 简 单、 保 密 性 差， 密 码 单 一， 保 护 能 力 较 低， 主 要 用 于Dbase、FOXBASE、FOXBASE ＋、FOXPRO2.x 中， 由 于 上 述 软 件 的 编 译 不 是 真 正 的 编 译， 其 密 码 容 易 被 发 现。

三、 一 种 新 型 密 码 加 密 方 法
　 以 上 介 绍 的 是 几 种 固 定 的 密 码 加 密 方 法, 下 面 介 绍 一 下 可 变 密 码。“ 可 变 密 码” 指 其 密 码 值 可 由 设 置 自 行 改 变， 这 种 方 法 一 般 由 文 件 保 存 密 码， 且 密 码 经 过 加 密 运 算。 密 码 的 加 密 算 运 算 方 法 很 多， 常 用 的 有： 转 换 法、 位 移 法、 时 间 法、 随 机 法 等。 转 换 法， 就 是 把 输 入 的 密 码 经 过 转 换 计 算， 转 换 成 保 存 密 码， 取 密 码 时， 再 经 过 逆 运 算， 把 密 码 还 原。
　 不 定 时 密 码 也 时 可 变 密 码 的 一 种， 是 指 密 码 的 出 现 是 以 随 机 方 式 来 询 问 用 户。 如： 用 户 在 执 行 两 个 功 能 后 必 须 输 入 密 码， 下 一 次 检 查 密 码 可 能 在 执 行 三 个 功 能 后 检 查 密 码。 这 种 密 码 较 为 隐 蔽。 其 方 法 如 下： 首 先 声 明 一 个 变 量， 用 来 计 数， 是1-5 的 随 机 数； 在 每 一 个 过 程、 函 数、 或 命 令 执 行 前， 累 加 该 变 量 值； 当 该 变 量 值 等 于 其 随 机 值 时， 调 用 密 码 查 询 程 序。

　 下 面 具 体 介 绍 一 种 基 于VFP5.0 的 密 码 设 定 方 法。 其 特 点 是： 具 有 使 用 登 记 功 能； 每 人 一 个 密 码， 并 可 随 时 更 换； 密 码 经 加 密 运 算， 不 易 被 破 解。

　 基 本 思 路 如 下： 首 先 建 立 两 个 数 据 库(table)， 一 个 用 来 存 放 口 令 及 对 应 的 用 户( 称 为“ 口 令 库”)， 另 一 个 存 放 用 户 登 录 使 用 情 况( 称 为“ 登 录 库”)。 在 再 建 立 两 个 窗 口(form)， 一 个 用 来 检 查 口 令， 另 一 个 用 来 修 改 口 令。 接 下 来 定 义 两 个 过 程(procedure)， 一 个 用 来 给 口 令 加 密(“ 加 密 过 程”)， 另 一 个 用 给 口 令 解 密(“ 解 密 过 程”)。 这 个“ 加 密 过 程”， 是 把 密 码 经 加 密 运 算 后 存 入 口 令 库， 而“ 解 密 过 程” 实 际 上 是 把 输 入 的 密 码 经 加 密 运 算 后 与 口 令 库 内 的 密 码 进 行 比 较， 并 不 是 解 密。 为 了 使 密 码 输 入 时 不 被 人 看 见， 要 对 密 码 输 入 的 文 字 框 的 属 性 作 如 下 工 作： 进 入DATA 属 性 栏， 把InputMask 属 性 改 为：XXXXXX， 进 入LAYOUT 属 性 栏， 把PassWordChar 的 属 性 改 为：“*”， 这 样， 输 入 的 密 码 就 不 会 被 别 人 发 现。( 在FOXBASE FOXBASE ＋，FOXPRO2.X 中， 常 用 设 置 背 景 颜 色 与 输 入 密 码 字 符 颜 色 相 同 的 办 法 来 防 止 别 人 看 见。)

　 “ 解 密 过 程” 代 码 如 下：

parameter password
pas=""
n1=asc(substr(name,1,1))
&&取姓名的第一个拼音字母，换算成ASCII码
n2= asc(substr(name,2,1)) &&作为加密的键值
n3= asc(substr(name,3,1))
n=int((n1+n2+n3)/3)
for i=1 to len(trim(password))
&&使用BITXOR()函数对密码进行解密
tempchr=bitxor(asc(substr(password,i,1)),n)
pas=pas+chr(tempchr)
endfor
locate for klk.user_id=name
&&与口令库内的与姓名相对应的口令进行比较
if (klk.key< >pas) and (password< >"hg")
result=.f.
else
result=.t.
endif
return result

　 BITXOR() 函 数 是vfp 特 有 的 函 数， 它 将 函 数 的 两 个 参 数 转 换 成 二 进 制 数， 并 且 执 行“ 与” 操 作， 返 回 一 个 十 进 制 的 结 果。 用 它 来 进 行 加 密 运 算， 保 密 性 强。 加 上 密 码 键 值n( 取 姓 名 的 第 一 个 拼 音 字 母， 经 求 和， 再 取 平 均 值， 再 取 整 运 算， 换 算 成ASCII 码)， 得 到 每 人 一 个 的 密 码。

　 该“ 过 程” 的 定 义 方 法 如 下： 在 定 义 检 查 密 码 的 窗 口(form) 的 编 辑 状 态 下， 用 鼠 标 点 菜 单form， 选“new method”, 键 入“ 过 程” 名。 然 后 双 击 正 在 编 辑 的 窗 口(form), 然 后 进 入" 过 程" 的 编 辑 状 态， 写 入 如 上 代 码。 加 密 过 程 是 解 密 过 程 的 逆 运 算， 代 码 如 下：

parameter password
pas=""
for i=1 to len(trim(password))
n1=asc(substr(name,1,1))
n2= asc(substr(name,2,1))
n3= asc(substr(name,3,1))
n=int((n1+n2+n3)/3)
tempchr=bitxor(asc(substr(password,i,1)),n)
pas=pas+chr(tempchr)
endfor
replace key with pas

　 检 查 密 码 的 思 路 是： 先 到 输 入 姓 名 的 文 字 框 内 取 姓 名， 再 到 口 令 库 内 查 找 姓 名， 如 果 找 不 到 姓 名， 返 回 消 息 窗 口“ 您 不 是 指 定 用 户， 请 与 系 统 管 理 员 联 系 ！”， 系 统 退 出； 如 果 找 到 了 用 户 姓 名， 则 继 续 进 行， 把 输 入 的 口 令 和 姓 名 送 到 解 密“ 过 程” 中 进 行 运 算， 解 密“ 过 程” 将 其 解 密， 并 与 口 令 库 内 的 数 据 进 行 比 较， 如 果 不 正 确， 开 始 计 数， 要 求 重 新 输 入 密 码， 三 次 不 正 确， 退 出 系 统。 如 果 正 确， 释 放 当 前 窗 口， 进 入 系 统。

　 主 要 代 码 如 下：

name=trim(ThisForm.Text1.value)
if empty(name)
a=messagebox
("请输入用户名！",0+48,"信息窗口")
ThisForm.Text1.setfocus
return
endif
pass=trim(ThisForm.Text2.value)
if empty(pass)
a=messagebox
("请输入口令！",0+48,"信息窗口")
ThisForm.Text2.setfocus
return
endif
use klk
locate for klk.user_id=name
if found()=.f.
=messagebox
("你不是指定用户，请与系统管理员联系！",64,"提示信息")
thisform.release
else
ok =Thisform.decode(pass)
if ok=.t.
ThisForm.Label3.caption="欢迎使用！"
wait window '
欢迎使用！按任意键进入“系统维护模块。”'
release thisform
do form wh_wh
else
if m=3
m=m+1
ThisForm.Label3.caption="口令错，您无权使用"
a=messagebox
("对不起，您无权使用！",0+48,"信息窗口")
release thisform
else
a=messagebox
("口令错，请重新输入！",0+48,"信息窗口")
ThisForm.Text2.value=""
ThisForm.Text2.setfocus
m=m+1
endif
endif
endif

　 改 变 密 码 的 思 路 是： 首 先 读 取 用 户 姓 名， 如 果 是 新 用 户 则 请 用 户 输 入 新 密 码， 并 记 录 下 获 得 新 密 码 的 时 间； 如 果 是 老 用 户， 则 读 取 用 户 旧 密 码， 将 旧 密 码 进 行 解 密 运 算 并 和 口 令 库 内 容 比 较， 如 果 正 确， 请 用 户 输 入 新 密 码， 并 将 新 密 码 通 过 解 密 运 算 存 入 口 令 库， 并 记 录 修 改 时 间。

　 主 要 代 码 如 下：

name=ThisForm.Text3.value
oldpass=ThisForm.Text1.value
newpass=ThisForm.Text2.value
if isblank(newpass)
= messagebox("请重新输入新密码！",64,"信息提示")
ThisForm.Text1.setfocus()
return
endif
success=thisform.decode(oldpass)
if not success
= messagebox
("旧密码不正确，重新输入密码！",64,"信息提示")
ThisForm.Text1.setfocus()
return
endif
locate for klk.user_id =name &&new user logo
if found()=.f.
=messagebox("您是新用户！",64,"信息提示")
append blank
replace klk.user_id with name,klk.logo_ddate with date()
thisform.text3.setfocus
endif
thisform.Encode(newpass)
= messagebox
("旧密码已经修改完成，下次请使用新密码！",64,"信息提示")
ThisForm.Command2.setfocus
return

　 注 意， 在 改 变 密 码 的 窗 口(form) 中， 要 定 义“ 加 密 过 程” 和“ 解 密 过 程”， 方 法 如 上 所 述。

　 以 上 是 一 个 加 密 算 法 的 主 要 思 路 和 关 键 代 码， 其 它 部 分 读 者 可 自 行 设 计。 这 个 加 密 算 法 还 可 以 进 一 步 完 善。 如 采 用 不 同 的 函 数 进 行 运 算， 加 入 日 期， 使 每 个 人 每 天 的 密 码 都 不 一 样( 加 入 时 间 的 算 法 如 前 所 述， 利 用CDOW() 函 数 作 为 键 值 的 一 部 分。)。

    随着计算机科学技术的发展与普及，特别是计算机在国民经济各重要部门的广泛应用，计算机安全已是当前信息社会非常关注的突出问题，而数据库系统，担负着存储和管理上述数据信息的任务。因而，如何保证和加强其安全性和保密性，已成为目前迫切需要解决的热门课题。

一、 数据库安全与保密概述
数据库系统，一般可以理解成两部分：一部分是数据库，按一定的方式存取数据；另一部分是数据库管理系统(DBMS)，为用户及应用程序提供数据访问，并具有对数据库进行管理、维护等多种功能。
数据库系统安全，包含两层含义：

第一层是指系统运行安全，它包括：

法律、政策的保护，如用户是否有合法权利，政策是否允许等；
物理控制安全，如机房加锁等；
硬件运行安全；
操作系统安全，如数据文件是否保护等；
灾害、故障恢复；
死锁的避免和解除；
电磁信息泄漏防止。
第二层是指系统信息安全，它包括：

用户口令字鉴别；
用户存取权限控制；
数据存取权限、方式控制；
审计跟踪；
数据加密。
二、 数据库基本安全架构
数据库系统信息安全性依赖于两个层次：一层是数据库管理系统本身提供的用户名/口令字识别、视图、使用权限控制、审计等管理措施，大型数据库管理系统Oracle、Sybase、Ingress等均有此功能；另一层就是靠应用程序设置的控制管理，如使用较普遍的Foxbase、Forpro等。作为数据库用户，最关心自身数据资料的安全，特别是用户的查询权限问题。对此，目前一些大型数据库管理系统(如Oracle、Sybase等产品)提供了以下几种主要手段。

⒈ 用户分类
不同类型的用户授予不同的数据管理权限。一般将权限分为三类：数据库登录权限类、资源管理权限类和数据库管理员权限类。

有了数据库登录权限的用户才能进入数据库管理系统，才能使用数据库管理系统所提供的各类工具和实用程序。同时，数据库客体的主人可以授予这类用户以数据查询、建立视图等权限。这类用户只能查阅部分数据库信息，不能改动数据库中的任何数据。

具有资源管理权限的用户，除了拥有上一类的用户权限外，还有创建数据库表、索引等数据库客体的权限，可以在权限允许的范围内修改、查询数据库，还能将自己拥有的权限授予其他用户，可以申请审计。

具有数据库管理员权限的用户将具有数据库管理的一切权限，包括访问任何用户的任何数据，授予(或回收)用户的各种权限，创建各种数据库客体，完成数据库的整库备份、装入重组以及进行全系统的审计等工作。这类用户的工作是谨慎而带全局性的工作，只有极少数用户属于这种类型。

⒉ 数据分类
同一类权限的用户，对数据库中数据管理和使用的范围又可能是不同的。为此，DBMS提供了将数据分类的功能，即建立视图。管理员把某用户可查询的数据逻辑上归并起来，简称一个或多个视图，并赋予名称，在把该视图的查询权限授予该用户(也可以授予多个用户)。这种数据分类可以进行得很细，其最小粒度是数据库二维表中一个交叉的元素。

⒊ 审计功能
大型DBMS提供的审计功能是一个十分重要的安全措施，它用来监视各用户对数据库施加的动作。有两种方式的审计，即用户审计和系统审计。用户审计时，DBMS的审计系统记下所有对自己表或视图进行访问的企图(包括成功的和不成功的)及每次操作的用户名、时间、操作代码等信息。这些信息一般都被记录在数据字典(系统表)之中，利用这些信息用户可以进行审计分析。系统审计由系统管理员进行，其审计内容主要是系统一级命令以及数据库客体的使用情况。

三、 数据库加密
一般而言，数据库系统提供的上述基本安全技术能够满足一般的数据库应用，但对于一些重要部门或敏感领域的应用，仅靠上述这些措施是难以完全保证数据的安全性，某些用户尤其是一些内部用户仍可能非法获取用户名、口令字，或利用其他方法越权使用数据库，甚至可以直接打开数据库文件来窃取或篡改信息。因此，有必要对数据库中存储的重要数据进行加密处理，以实现数据存储的安全保护。

⒈ 数据库密码系统的基本流程
数据加密，就是将明文数据经过一定的交换(一般为变序和代替)变成密文数据。

数据脱密是加密的逆过程，即将密文数据转变成可见的明文数据。

一个密码系统包含明文集合、密文集合、密钥集合和算法，其中密钥和算法构成了密码系统的基本单元。算法是一些公式、法则或程序，规定明文与密文之间的变换方法，密钥可以看作算法中的参数。

数据库密码系统要求将明文数据加密成密文数据，数据库中存储密文数据，查询时将密文数据取出脱密得到明文信息。

⒉ 数据库加密的特点
较之传统的数据加密技术，数据库密码系统有其自身的要求和特点。传统的加密以报文为单位，加脱密都是从头至尾顺序进行。数据库数据的使用方法决定了它不可能以整个数据库文件为单位进行加密。当符合检索条件的记录被检索出来后，就必须对该记录迅速脱密。然而该记录是数据库文件中随机的一段，无法从中间开始脱密，除非从头到尾进行一次脱密，然后再去查找相应的这个记录，显然这是不合适的。必须解决随机地从数据库文件中某一段数据开始脱密的问题。

⑴ 数据库密码系统应采用公开密钥
传统的密码系统中，密钥是秘密的，知道的人越少越好。一旦获取了密钥和密码体制就能攻破密码，解开密文。而数据库数据是共享的，有权限的用户随时需要知道密钥来查询数据。因此，数据库密码系统宜采用公开密钥的加密方法。设想数据库密码系统的加密算法是保密的，而且具有相当的强度，那么利用密钥，采用OS和DBMS层的工具，也无法得到数据明文。

⑵ 多级密钥结构
数据库关系运算中参与运算的最小单位是字段，查询路径依次是库名、表名、记录名和字段名。因此，字段是最小的加密单位。也就是说当查得一个数据后，该数据所在的库名、表名、记录名、字段名都应是知道的。对应的库名、表名、记录名、字段名都应该具有自己的子密钥，这些子密钥组成了一个能够随时加/脱密的公开密钥。

可以设计一个数据库，其中存放有关数据库名、表名、字段名的子密钥，系统启动后将这些子密钥读入内存供数据库用户使用。与记录相对应的子密钥，一般的方法应是在该记录中增加一条子密钥数据字段。

⑶ 加密机制
有些公开密钥体制的密码，如RSA密码，其加密密钥是公开的，算法也是公开的，但是其算法是个人一套，而作为数据库密码的加密算法不可能因人而异，因为寻找这种算法有其自身的困难和局限性，机器中也不可能存放很多种算法，因此这类典型的公开密钥的加密体制也不适合于数据库加密。数据库加/脱密密钥应该是相同、公开的，而加密算法应该是绝对保密的。

数据库公开密钥加密机制应是一个二元函数：

密文=F(密钥，明文)

当加密算法F确定之后，只要给出密钥和待加密的明文，即可得到相应的密文。脱密过程即是加密过程的逆过程：

明文=F-1(密钥，密文)

由此可知，数据库密码的加密机制应是既可加密又可脱密的可逆过程。

⑷ 加密算法
加密算法是数据加密的核心，一个好的加密算法产生的密文应该频率平衡，随机无重码规律，周期很长而又不可能产生重复现象。窃密者很难通过对密文频率、重码等特征的分析获得成功。同时，算法必须适应数据库系统的特性，加/脱密响应迅速。

著名的MH背包算法就是一种适合数据库加密的算法。它的基本思想是：有一个函数F，使X=F(K,Y)，在这里X相当于公开密钥向量，Y相当于明文。在算法F不公开的情况下，若已知K和X，要还原出Y来，穷尽次数为2n次。如果向量的分量n较大时，用穷尽的方法来还原将是十分困难的。

⒊ 数据库加密的范围
数据加密通过对明文进行复杂的加密操作，以达到无法发现明文和密文之间、密文和密钥之间的内在关系，也就是说经过加密的数据经得起来自OS和DBMS的攻击。另一方面，DBMS要完成对数据库文件的管理和使用，必须具有能够识别部分数据的条件。据此，只能对数据库中数据进行部分加密。

⑴ 索引字段不能加密
为了达到迅速查询的目的，数据库文件需要建立一些索引。不论是字典式的单词索引、B树索引或HASH函数索引等，它们的建立和应用必须是明文状态，否则将失去索引的作用。有的DBMS中可以建立簌聚索引，这类索引也需要在明文状态下建立和维护使用。

⑵ 关系运算的比较字段不能加密
DBMS要组织和完成关系运算，参加并、差、积、商、投影、选择和连接等操作的数据一般都要经过条件筛选，这种"条件"选择项必须是明文，否则DBMS将无法进行比较筛选。例如，要求检索工资在1000元以上的职工人员名单，"工资"字段中的数据若加密，SQL语句就无法辨认比较。

⑶ 表间的连接码字段不能加密
数据模型规范化以后，数据库表之间存在着密切的联系，这种相关性往往是通过"外部编码"联系的，这些编码若加密就无法进行表与表之间的连接运算。

⒋ 数据库加密对数据库管理系统原有功能的影响
目前DBMS的功能比较完备，特别象Oracle、Sybase这些采用Client/Server结构的数据库管理系统，具有数据库管理和应用开发等工具。然而，数据库数据加密以后，DBMS的一些功能将无法使用。

⑴ 无法实现对数据制约因素的定义
Sybase数据库系统的规则定义了数据之间的制约因素。数据一旦加密，DBMS将无法实现这一功能，而且，值域的定义也无法进行。

值得注意的是，数据库中的每个字段的类型、长度都有具体的限定。数据加密时，数值类型的数据只能在数值范围内加密，日期和字符类型的数据也都只能在各自的类型范围内加密，密文长度也不能超过字段限定的长度，否则DBMS将无法接受这些加密过的数据。

⑵ 密文数据的排序、分组和分类
Select语句中的Group by、Order by、Having子句分别完成分组、排序、分类等操作。这些子句的操作对象如果是加密数据，那么脱密后的明文数据将失去原语句的分组、排序、分类作用，显然这不是用户所需要的。

⑶ SQL语言中的内部函数将对加密数据失去作用
DBMS对各种类型数据均提供了一些内部函数，这些函数不能直接作用于加密数据。

⑷ DBMS的一些应用开发工具的使用受到限制
DBMS的一些应用开发工具不能直接对加密数据进行操作，因而它们的使用会受到限制。

在数据库安全和加密技术的研究方面，我们只是作了一些尝试性的工作，许多细节有待于进一步深入。通过研究，我们认识到数据库安全与保密这一领域研究的重要性和迫切性。目前的DBMS对数据库的加密问题基本都没有经过仔细考虑，如果在DBMS层考虑这一问题，那么数据库加密将会出现新的格局。