SQL Server数据库 的这种为用户提供一个安全、可靠和高效的平台用于企业数据管理和商业智能应用的工作性能，就直接很明显的强调了加密数据的重要性。所以，为了防止某些别有用心的人从外部访问数据库，盗取数据库中的用户姓名、密码、信用卡号等其他重要信息，在我们创建数据库驱动的解决方案时，我们首先需要考虑的的第一条设计决策就是如何加密存储数据，以此来保证它的安全，免受被他人窥测。
SQL Server中有哪一种支持可以用于加密对象和数据?从一开始就讨论一下SQL Server欠缺什么是明智的，或者是对于SQL Server中的加密部分你不应该做什么。
首先，SQL Server有两个内置的密码函数 ——即，pwdencrypt() 和 pwdcompare()。同时，还有两个SQL Server用来管理密码哈希的没有正式记录的函数:pwdencrypt() 将密码哈希过后进行存储; pwdcompare()将提供的字符串与哈希后的字符串进行比较。不幸的是，这个哈希函数不是非常安全，它可以通过字典攻击算法被破解(类似命令行应用程序!)。
这些函数随着SQL Server的版本发展而不断进行修改，这也是另一个没有使用它们的原因。早期版本的SQL Server对密码进行的哈希，在后来的版本中无法解密，所以如果你依赖一个版本中的函数，那么当升级的时候，所有你的加密数据就都没有用了，除非你可以首先对其解密——这也就违背了加密的最初的目的。
第二，你可能会尝试去创建一个针对你的数据库的自制的加密解决方案， 但是有以下三个理由说明你不要这样做:
除非你是加密专家，否则胡乱编写的加密系统只会提供非常低级的价值不高的保护。新鲜的是，单向密码哈希或者 “ROTx “形式的加密几乎不需要费事就可以被轻松打败。
如果由于你自己的能力的缺乏而导致加密被破解，那么你的数据就完蛋了。你需要将所有的东西进行没有加密的备份，是吗?(即使你加密了，那里有没有安全漏洞?)
当市面上提供有专业级别的，具有工业强度的加密解决方案的时候，你就不值得花费时间去自己做。把你的时间用于构建一个好的，坚固的数据库，而不是再重新发明一次车轮。
那么，什么才是好的加密数据的方式呢?
对于新手，微软提供了一个自己生成的加密解决方案，CryptoAPI 。对于轻量级的加密，军用级别的安全就不在考虑范围之内，它具有相对容易实现的优势:管理员可以安装一个名为CAPICOM 的ActiveX 控制，它可以在T-SQL存储过程中提供CryptoAPI 功能。CAPICOM 支持各种类型的双向加密和单向哈希算法，所以管理员可以挑选最适合应用程序的问题的部分。
如果你对使用微软的解决方案不感兴趣，还有一些很好的第三方的方案可以使用。一家名为ActiveCrypt 的软件有限责任公司制造了XP_CRYPT ，它是SQL Server的插件，可以在视图、程序和触发器中通过扩展存储过程和用户自定义函数(在SQL Server 2000中)来完成加密。你可以下载一个支持无线的MD5,DES ，以及SHA1哈希的免费版本的应用程序; 其他的加密模型就是在比特深度上进行的。(完全版本是无限的。)在你自己的代码中，你可以使用XP_CRYPT，与ActiveX 控制一样(在受限的免费版本中)。对于ASP程序员来说，一个名为AspEncrypt 的组件提供了一种将高级加密整合到你的代码中的简单方式。
对数据库文件自身进行加密或者提供传输层上的安全保护怎么样?对于前者，大家可以在Windows系统中持续使用加密文件系统。然而，你必须保存加密密钥的备份，在出现问题的时候，这个数据有可能会丢失。对于后者，有IPSec和SQL Server自己的SSL加密，都是SQL Server和Windows自带的大家的主要精力应该放在避免以明文存储敏感数据，因为从数据库中抽取没有加密的数据同样是最容易受到攻击的薄弱环节。
以上介绍的SQL Server数据库加密数据是很有用处的，在大家以后的工作中会起到很大的作用，当然前提是真正的读懂了其中的意思，并且很好的掌握了。
【编辑推荐】
如何用sql语句添加数据库用户/密码
sp_addlogin [ @loginame = ] login[ , [ @passwd = ] password ][ , [ @defdb = ] database ][ , [ @deflanguage = ] language ][ , [ @sid = ] sid ][ , [ @encryptopt = ] encryption_option ]参数[@loginame =] login登录的名称。 login 的数据类型为 sysname，没有默认设置。 [@passwd =] password登录密码。 password 的数据类型为 sysname，默认设置为 NULL。 sp_addlogin 执行后，password 被加密并存储在系统表中。 [@defdb =] database登录的默认数据库（登录后登录所连接到的数据库）。 database 的数据类型为 sysname，默认设置为 master。 [@deflanguage =] language用户登录到 SQL Server 时系统指派的默认语言。 language 的数据类型为 sysname，默认设置为 NULL。 如果没有指定 language，那么 language 被设置为服务器当前的默认语言（由 sp_configure 配置变量 default language 定义）。 更改服务器的默认语言不会更改现有登录的默认语言。 language 保持与添加登录时所使用的默认语言相同。 [@sid =] sid安全标识号 (SID)。 sid 的数据类型为 varbinary(16)，默认设置为 NULL。 如果 sid 为 NULL，则系统为新登录生成 SID。 尽管使用 varbinary 数据类型，非 NULL 的值也必须正好为 16 个字节长度，且不能事先存在。 SID 很有用，例如，如果要编写 SQL Server 登录脚本，或要将 SQL Server 登录从一台服务器移动到另一台，并且希望登录在服务器间具有相同的 SID 时。 [@encryptopt =] encryption_option指定当密码存储在系统表中时，密码是否要加密。 encryption_option 的数据类型为 varchar(20)，可以是下列值之一。 值 描述 NULL 加密密码。 这是默认设置。 skip_encryption 密码已加密。 SQL Server 应该存储值而且不用重新对其加密。 skip_encryption_old 已提供的密码由 SQL Server 较早版本加密。 SQL Server 应该存储值而且不用重新对其加密。 此选项只供升级使用。 返回代码值0（成功）或 1（失败）
如何使sqlserver2000数据库更安全
当你连接一个SQL服务器时，你通常应该使用一个口令。 口令不以明文在连接上传输。 所有其它信息作为能被任何人读懂的文本被传输。 如果你担心这个，你可使用压缩协议(SQL3.22和以上版本)使事情变得更难。 甚至为了使一切更安全，你应该安装SSH。 用它，你能在一个SQL服务器与一个SQL客户之间得到一个加密的TCP/IP连接。 为了使一个SQL系统安全，强烈要求你考虑下列建议：对所有SQL用户使用口令。 记住，如果other_user没有口令，任何人能简单地用sql -u other_user db_name作为任何其它的人登录。 对客户机/服务器应用程序，客户可以指定任何用户名是常见的做法。 在你运行它以前，你可以通过编辑sql_install_db脚本改变所有用户的口令，或仅仅SQL root的口令，象这样：shell> mysql -u root mysqlmysql> Update user SET PassWord=PASSWord(new_passWord)WHERE user=root;mysql> FLUSH PRIVILEGES; 不要作为Unix的root用户运行MySQL守护进程。 mysqld能以任何用户运行，你也可以创造一个新的Unix用户mysql使一切更安全。 如果你作为其它Unix用户运行mysqld，你不需要改变在user表中的root用户名，因为MySQL用户名与Unix用户名没关系。 你可以作为其它Unix用户编辑启动脚本mysqld。 通常这用su命令完成。 如果你把一个Unix root用户口令放在脚本中，确保这个脚本只能对root是可读的。 检查那个运行mysqld的Unix用户是唯一的在数据库目录下有读/写权限的用户。
怎么把mysql数据库中现有的数据进行des加密，加密后的结果和java中des加密的结果一样。
最近需要对数据进行加密/解密, 因此选用了CryptoJS库, 对数据做DES算法的加密/解密首选查看官方示例, 将密文进行Base64编码, 掉进一个大坑
发表评论