环视制作者
为了防⽌某些别有⽤⼼的⼈从外部访问数据库，盗取数据库中的⽤户姓名、密码、信⽤卡号等其他重要信息，在我们创建数据库驱动的解决⽅案时，我们⾸先需要考虑的的第⼀条设计决策就是如何加密存储数据，以此来保证它的安全，免受被他⼈窥测。
SQL Server中有哪⼀种⽀持可以⽤于加密对象和数据?从⼀开始就讨论⼀下SQL Server⽋缺什么是明智的，或者是对于SQL Server中的加密部分你不应该做什么。
⾸先，SQL Server有两个内置的密码函数——即，pwdencrypt() 和 pwdcompare()。同时，还有两个SQL Server⽤来管理密码哈希的没有正式记录的函数:pwdencrypt() 将密码哈希过后进⾏存储; pwdcompare()将提供的字符串与哈希后的字符串进⾏⽐较。不幸的是，这个哈希函数不是⾮常安全，它可以通过字典攻击算法被破解(类似命令⾏应⽤程序!)。 web前端性能优化这些函数随着SQL Server的版本发展⽽不断进⾏修改，这也是另⼀个没有使⽤它们的原因。早期版本的SQL Server对密码进⾏的哈希，在后来的版本中⽆法解密，所以如果你依赖⼀个版本中的函数，那么当升级的时候，所有你的加密数据就都没有⽤了，除⾮你可以⾸先对其解密——这也就违背了加密的最初的⽬的。
悬浮机器人
第⼆，你可能会尝试去创建⼀个针对你的数据库的⾃制的加密解决⽅案，但是有以下三个理由说明你不要这样做:
除⾮你是加密专家，否则胡乱编写的加密系统只会提供⾮常低级的价值不⾼的保护。新鲜的是，单向密码哈希或者 "ROTx "形式的加密⼏乎不需要费事就可以被轻松打败。
如果由于你⾃⼰的能⼒的缺乏⽽导致加密被破解，那么你的数据就完蛋了。你需要将所有的东西进⾏没有加密的备份，是吗?(即使你加密了，那⾥有没有安全漏洞?)
空烟卷
当市⾯上提供有专业级别的，具有⼯业强度的加密解决⽅案的时候，你就不值得花费时间去⾃⼰做。把你的时间⽤于构建⼀个好的，坚固的数据库，⽽不是再重新发明⼀次车轮。
那么，什么才是好的加密数据的⽅式呢?
对于新⼿，微软提供了⼀个⾃⼰⽣成的加密解决⽅案，CryptoAPI 。对于轻量级的加密，军⽤级别的安全就不在考虑范围之内，它具有相对容易实现的优势：管理员可以安装⼀个名为CAPICOM 的ActiveX 控制，它可以在T-SQL存储过程中提供CryptoAPI 功能。CAPICOM ⽀持各种类型的双向加密和单向哈希算法，所以管理员可以挑选最适合应⽤程序的问题的部分。
如果你对使⽤微软的解决⽅案不感兴趣，还有⼀些很好的第三⽅的⽅案可以使⽤。⼀家名为ActiveCry琉璃砖
pt 的软件有限责任公司制造了
XP_CRYPT ，它是SQL Server的插件，可以在视图、程序和触发器中通过扩展存储过程和⽤户⾃定义函数(在SQL Server 2000中)来完成加密。你可以下载⼀个⽀持⽆线的MD5,DES ，以及SHA1哈希的免费版本的应⽤程序; 其他的加密模型就是在⽐特深度上进⾏的。(完全版本是⽆限的。)在你⾃⼰的代码中，你可以使⽤XP_CRYPT，与ActiveX 控制⼀样(在受限的免费版本中)。对于ASP程序员来说，⼀个名为AspEncrypt 的组件提供了⼀种将⾼级加密整合到你的代码中的简单⽅式。
对数据库⽂件⾃⾝进⾏加密或者提供传输层上的安全保护怎么样?对于前者，⼤家可以在Windows系统中持续使⽤加密⽂件系统。然⽽，你必须保存加密密钥的备份，在出现问题的时候，这个数据有可能会丢失。对于后者，有IPSec和SQL Server⾃⼰的SSL加密，都是SQL Server和Windows⾃带的⼤家的主要精⼒应该放在避免以明⽂存储敏感数据，因为从数据库中抽取没有加密的数据同样是最容易受到攻击的薄弱环节。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议