我目前正在确定我的应用程序的安全性。
我向各位专家提出的一个问题是,是否有办法让某人控制我的 unix 平台,从某种 mysql 日志记录中提取密码?
我通常在php和mysql之间传输密码是这样完成的:
$sql = "CALL client_create(?, ...)";
$stmt = $cnx->prepare($sql);
$stmt->execute(array($hashpw, ...));
$cnx->commit();
如果有什么改变的话,我的设置中没有自动提交
。
所以基本上必须有某种重做日志或类似的,对吧?怎么样,应该担心吗?我应该偶尔冲洗一次吗?
感谢您的帮助!
最佳答案
你担心的事情绝对有可能发生。然而,这确实不应该是一个问题。让我解释一下:
MySQL 目前使用多种不同类型的日志:
- Binary Logs - 这些用于复制并获取写入其中的每个写入查询(以可逆的二进制形式)。如果您正在进行复制,则需要这些日志。
- Query Logs - 这些用于调试(通常)。它们通常不会在生产环境中启用(应该禁用它们)。
- InnoDB Transaction Log - 这用于每次写入,以允许事务符合 ACID(详细信息超出了本答案的范围)。
- Other Logs - 这里您无需担心(错误日志、慢速查询日志等)。
因此,数据通常至少写入一个日志文件,但也可能写入 3 个(取决于服务器配置)。
但它也被写入磁盘。它以合理的纯文本格式存储在表空间中。因此,如果我(作为攻击者)可以访问磁盘,我将跳过日志并直接获取表信息本身。
现在,如果您在数据库层中“散列”密码(意味着纯文本密码进入查询,并且数据库发出散列函数),那么您是正确的,日志可能会产生纯文本密码-文本密码。
不值得
不值得尝试通过刷新日志来隐藏此信息。最好从源头解决问题(在应用程序中使用更好的哈希方法)。
问题是 MySQL 使用的任何哈希都是简单的原始哈希(例如 MD5()
或 SHA256()
)。两者都被设计为快速。因此,如果我可以从表中获取哈希值,我就可以像使用原始密码一样轻松地攻击它。为什么?因为快速哈希很容易被暴力破解with GPUs .
TLDR
基本上,你必须做两件事(至少从我的角度来看):
- 阻止人们访问数据库的文件系统。这是首要的。
- 使用正确的密码存储技术(bcrypt 等)。这将减轻日志文件可能造成的任何影响。
关于php - 准备好的语句的安全/服务器系统日志记录,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/15399430/