Question

我们想要创建一个Web API，用户在购买我们的软件许可证时通过电子邮件接收哈希令牌（196位），然后可以使用此令牌激活他们的试用软件版本到＆＃34;全＆＃34;软件。 Web API负责接收哈希令牌并确认或拒绝用户升级到完整。

留下关于此的大量细节，似乎以这种方式接收散列令牌，然后仅使用SQL SELECT检查此令牌是否在数据库中暴露了定时攻击。攻击者可以通过测量响应时间来尝试从数据库中的标记中猜出单个字节。

如何防范这个？一般而言，特别是在Ruby on Rails中。

到目前为止的想法：

实现查询的恒定时间（如何？）
添加随机噪音（多少？）
在关键部分（32位）和余数中拆分令牌。仅在密钥上执行查找，并在其余部分进行安全比较

Answer 1

我的工作解决方案使用第二个索引的token_key字段，该字段是token_hash的前8个字节：

def valid_token(given_token_hash)

  # don't look for hash, because of SQL timing attacks
  token_key = given_token_hash[0,8]
  token = ActivationToken.find_by_token_key(token_key)

  # Even if not found in database, we should pretend to take some time
  token_hash = token.nil? ? "123e4567-e89b-12d3-a456-426655440000" : token.token_hash

  if (!secure_compare(token_hash, given_token_hash))
    return nil
  end

  return token
end

Answer 2

出于这个原因设计删除了token_authentication时出现的一个解决方案是根据公共条件（例如电子邮件）执行查找，然后对查询找到的哈希令牌和发送的哈希令牌使用常量时间比较在params。检查“安全”版本的要点。

https://gist.github.com/josevalim/fb706b1e933ef01e4fb6#file-2_safe_token_authentication-rb

我认为从统计学角度来看，添加随机噪声是徒劳的，有足够的数据，随机性应该变平。我很乐意听到有关SQL包含内部比较机制的更多细节。

针对散列令牌SQL SELECT的定时攻击的对策

2 个答案: