【问题标题】:High performance encrypt/decrypt in both PHP AND MySQLPHP 和 MySQL 中的高性能加密/解密
【发布时间】:2011-06-12 20:29:02
【问题描述】:

我想重新设计我的数据库/网站的某些方面,并且正在寻找 PHP 中相当强大的加密函数,MySQL 也支持这些函数。

我还需要加密/解密是 100% 可移植和兼容的

我通常会在 PHP 中加密,从 MySQL 中选择加密版本,然后在 PHP 中解密。 但有时我需要运行一个查询来解密 MySQL 中的字段,用于报告等目的

我查看了 mycrypt php 库,但不清楚 MySQL 支持哪些密码。 有什么建议吗?

【问题讨论】:

标签: php mysql cryptography


【解决方案1】:

经过一番 Google-fu 后,MySQL 似乎使用 128 位 AES 和电子密码本 (ECB) 模式。对于密钥,您需要使用正好是 16 个字节的值。

假设我使用_My-16-byte-key_ 作为我的密钥。

SELECT AES_ENCRYPT('The rooster crows at midnight!', '_My-16-byte-key_')

结果是:7e41520667dc20457db2f18644bad06dd62a2120be8b93cd5596d8ffea45ef0f

在 PHP 中,我可以使用mcrypt_decrypt 来反转它:

$secret = '7e41520667dc20457db2f18644bad06dd62a2120be8b93cd5596d8ffea45ef0f';
$key = '_My-16-byte-key_';
print mcrypt_decrypt(MCRYPT_RIJNDAEL_128, $key, pack('H*', $secret), 'ecb');

结果:

公鸡半夜打鸣!

我将把反向流程作为练习留给读者。 =)

【讨论】:

  • 感谢 Johan 的错字修正。 =)
  • 谢谢,这真的很有用。我对 MySQL 方面的 AES 有所了解,但我为 PHP 找到的只是第三方脚本或使用 AES 的库。很高兴看到它可以使用普通 PHP API 完成
【解决方案2】:

这里:http://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html
是 MySQL 中所有加密函数的列表。

我建议使用 AES。
所有其他加密选项不再安全。
AES 支持 128 位密钥长度(以及重新编译 MYSQL 源代码的 256 位密钥长度)
不要忘记to salt 使用 AES 加密的所有内容,以防止彩虹表攻击。

如果您使用相同的密钥来加密解密攻击者需要做的所有事情就是获取该密钥,使用散列函数(和盐)您不必担心丢失密钥,使用此选项您可以运行丢失密钥和所有密码的巨大风险。

改用哈希函数:SHA256 加盐。

【讨论】:

  • 对 AES 的彩虹表攻击?请引用。
  • sumcbean,你说得对,情况更糟。如果您使用相同的密钥来加密解密攻击者需要做的所有事情就是获取该密钥,使用散列函数(和盐)您不必担心丢失密钥,使用此选项您将面临巨大的风险丢失密钥和所有密码。
  • 好的,但是为了获得密钥和盐,他们将获得对脚本和数据的访问权限。如果他们有脚本和数据,那么游戏就真的结束了。我真的看不出可以采取什么措施来防止黑客访问用户帐户,一旦他们拥有该级别的访问权限。如果我错了,请纠正我? :)
  • @carpii,如果您使用带盐的单向散列,即使您的所有数据和脚本都被获取,您的数据也将更难解密,并且其中大部分是安全的。这就是好的加密货币的特点,即使攻击者知道一切它仍然是安全的。如果您对电子邮件地址和密码进行哈希处理,您的攻击者将不得不搜索 8 个字符 + 8 个字符 = 16 个字符的键空间。更难获得可用数据,他不能使用彩虹表。对于每条记录,这项工作都已重做。比一次性解密整个数据库的丢失密钥要困难得多。
  • 谢谢。我确实理解您所说的散列对于您只需要查找给定比较的场景更安全的说法。出于这个原因,我已经在某些地方使用了 MD5,但是我对新功能的特殊要求是我确实需要能够自己解密它。出于这个原因,我必须使用双向加密而不是简单地散列算法。
【解决方案3】:

我也推荐 AES,它的设计速度很快,而且因为它是行业标准,所以它足够强大。但是,在数据库中加密数据的原因是什么?如果您的加密密钥将存储在 PHP 脚本中,它不会比使用明文记录更安全。只有当许多脚本访问同一个数据库时,它才有好处。

【讨论】:

  • 我明白你关于在脚本中存储加密密钥的观点。但我不同意你的评论,即它“不会比使用纯文本记录更安全”。明文上的 SQL 注入将允许免费访问,而在加密记录上仍需要破解。我并不是说它会 100% 安全,但安全级别各不相同,而且 AES 绝对比明文更好。
猜你喜欢
  • 2013-04-14
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-02-24
  • 2011-08-09
相关资源
最近更新 更多