如何加密MySQL表中的特定列?
我正在尝试创建一个简单的消息系统 (PHP) 页面,该页面使用 MySQL 表来存储条目。我将在表中使用的列的粗略轮廓是:
msg_id(主键,自动增量)
user_id(指向创建消息的用户的外键)
< strong>time(提供消息时间戳的 DATETIME 条目)
msg(包含消息的 VARCHAR)
可访问(只是一个 int(1),0 表示没有除了用户自己可以读取消息外,1 表示其他人可以读取它)
我想知道的是,加密 msg 字段的最佳方法是什么,这样窥探的眼睛就无法读取它(比方说,通过打开 mysql CLI 或 phpMyAdmin 并读取连续存储的值)?
如果“accessable”设置为 0,那么只有用户他/她自己应该能够读取它(通过访问某些 PHP 页面),但如果设置为 1,其他人也应该能够读取它。我不知道如何解决这个问题,所以非常感谢任何帮助!
I am experimenting with creating a simple message system (PHP) page that uses a MySQL table to store the entries. The rough outline of the columns I'll use in the table are:
msg_id (primary key, auto_increment)
user_id (foreign key pointing to the user who created the message)
time (a DATETIME entry to provide msg timestamps)
msg (a VARCHAR containing the msg)
accessable (just an int(1), 0 means no one except the user himself can read the msg, and 1 means others can read it)
What I'm wondering is, what's the best way to encrypt the msg field so prying eyes can't read it (let's say, by opening the mysql CLI or phpMyAdmin and just read the value stored in a row)?
If "accessable" is set to 0, then only the user him/herself should be able to read it (by accessing some PHP page), but if set to 1, everyone else should be able to read it as well. I don't know how to tackle this, so any help is very appreciated!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
在此处查找可能的加密函数列表:
http://dev.mysql.com/doc/refman/5.1/en/cryption-functions.html" mysql.com/doc/refman/5.1/en/encryption-functions.html
您可以创建更新触发器并检查该字段
accessable
。类似的事情:您还可以使用此查询更新表中的所有现有记录:
因此您可以为您的 PHP 代码选择记录:
UPD。这里还有类似的问题:
MySQL 加密列
Look here for list of possible encryption functions:
http://dev.mysql.com/doc/refman/5.1/en/encryption-functions.html
You can create trigger for update and check there field
accessable
. Something like that:You also can update all existing records in you table with this query:
So you can select records for you PHP code:
UPD. Also here was similar question:
MySQL encrypted columns
您还可以在查询插入数据之前对数据进行加密,这样 MySQL 甚至不知道它已加密,并在应用程序中检索时对其进行解密。为此,您应该将其存储在 varbinary 或 blob 列中。
You can also encrypt the data prior to the query to insert it, so that MySQL doesn't even know it's encrypted, and decrypt it on retrieval in the application. For that, you should store it in a varbinary or blob column though.
所以我有一个想法可以实现这一点,但这都是概念性的。
假设您的值是“Lorem ipsum dolor sat amet”,并且您想要搜索“lorem”。一种方法是您可以将原始数据分解成块(小写),然后将它们放入第二个表中。整个(原始)值位于 row_id 123 的原始表列中,但名为“chunks”的新表可能具有:
将其视为子字符串索引,其中每个子字符串都是 2 个字符长。
现在,当用户想要执行搜索时,您同样可以将其分块,然后进行查找。如果他们输入“
lo
”,那么您会看到哪些外部行 ID 匹配。但是,如果他们输入“lore
”,那么您将搜索具有“lo
”、“or”,以及“
re
”。到目前为止,还不太实用。但是,如果原始值“Lorem ipsum dolor sat amet”已加密或散列,那么您还可以对 2 个字符的子字符串进行分块,对其进行加密/散列,然后对这些块进行查找或完整的字符串。无需解密或取消散列。
逻辑如下:
然后可以从原始表中获取任何匹配项。这将保护静态数据,因为如果块表受到损害,它们将无法对一堆加密/散列的 2 字符值执行任何操作。您无法获取 2 个加密/散列的子字符串并重新组合它们或从中获取任何有意义的内容。
如果我是发明者并必须命名它,因为它与制作彩虹桌相似但不完全相同,我会将其称为“水果卵石桌”。因为大块的缘故。
So I had an idea that might accomplish this, but it's all conceptual.
Suppose that you had the value "Lorem ipsum dolor sit amet", and you wanted to do a search for "lorem". One way is that you could take the original and break it up into chunks (lowercased), and put them in a second table. The whole (original) value is in the original table column with row_id 123, but a new table called "chunks" might have:
Think of it like a substring index, where every substring is 2 characters long.
Now, when a user wanted to perform a search, you would similarly chunk that up, then do a lookup. If they typed "
lo
", then you see which foreign row IDs matched. But if they enter "lore
", then you do a search for all foreign row IDs that had a matching chunk for "lo
", "or
", AND "re
".So far, not too practical. However, if the original value "Lorem ipsum dolor sit amet" is encrypted or hashed, then you could ALSO chunk up the 2-char substrings, encrypt/hash them, then do a lookup on the chunks instead or the full string. No decryption or unhashing necessary.
The logic would be:
Any match can then be fetched from the original table. This would protect the data at rest, because if the chunk table was compromised, they can't do anything with a bunch of encrypted/hashed 2-char values. You can't take 2 encrypted/hashed substrings and recombine them or get anything meaningful from them.
If I am the inventor and got to name this, since it's similar but not quite the same as making a Rainbow Table, I would called this "Fruity Pebbles Tables". Because of the chunks.