1

我已经阅读了很多关于密码存储、散列、加盐、“peppering”、MAC 等的内容，因为我即将创建一个新网站，安全性对我来说非常重要，但是我正在考虑有一些原因不使用目前不相关的 Google 身份验证（或 Facebook、OpenID 或任何其他），但这让我想到了这一点。

我是 Google App Engine 的新手，这将是我的第一个项目，我对“实例小时数”以及它如何不再有“CPU 时间”但上述配额有点困惑。更糟糕的是，我无法理解什么是 Instance Hours Free Quota。

这就是为什么我担心配额以及这与我的安全问题有什么关系：我在各处阅读的一个建议是进行多次迭代并对密码进行多次散列，因为这会使攻击者花费很多更多时间（我没有数字，但它们在https://security.stackexchange.com/上随处可见）。

多次迭代对 CPU 时间有直接影响，如果 GAE 有 CPU 时间配额，我认为每次用户登录时进行 1000 次迭代可能是一个问题，但是如果他们计算的是从请求完成到 up 的实例小时数到十五分钟后，在GAE 配额文档中阅读的是：

通常，实例使用根据实例的正常运行时间按小时计费。计费在实例启动时开始，在实例关闭十五分钟后结束。您只需为空闲实例付费，最多为在管理控制台的性能设置选项卡中设置的最大空闲实例数。运行时开销计入实例内存。

那么这意味着如果我的用户登录（哈希 1000 次），然后他们继续使用该网站，Instance Hours 将继续求和，直到他们全部离开页面 + 15 分钟？如果这是真的，那么让它迭代 1000 次不会对我的配额产生重大影响，除了用户登录所需的“额外”时间，但我知道这一点，这是我的代价'愿意付钱。

我将进行的迭代次数将使得登录时间对用户来说可以接受且不易察觉，所以不要担心这一点。

我的问题是：

  1. 进行许多迭代是否会对实例小时数产生直接影响，或者我对如何对实例小时数求和的假设是否正确？
  2. 我以某种方式缺少的 Google App Engine 上是否有 CPU 时间配额？它有免费配额吗？
  3. 什么是实例小时免费配额？

答案：

  1. 看看 Moishe 接受了答案和他提出的另一个问题（尚未回答但有有用的评论） App Engine 调度程序何时使用新线程与新实例？
  2. 根据谷歌没有CPU时间配额：http: //googleappengine.blogspot.com.es/2009/02/skys-almost-limit-high-cpu-is-no-more.html
  3. 在此处找到问题 3 的答案：已达到 Google App Engine 前端实例小时数限制
4

3 回答 3

1

只要服务器正在运行、响应请求等，实例时间就是如此。如果您的服务器没有运行，它就无法在请求或任何事情上唤醒。

将实例时间想象为打开计算机。当它打开时，你会被计费，而不是在它关闭时。

你可以有多个实例，假设你有两个实例，你的实例小时数是原来的两倍。

您的密码散列不会影响这一点，因为它只会在实例打开时产生实例小时数，而当它关闭时，它不会产生任何实例小时数，但它也不会散列。

于 2012-07-17T13:24:33.190 回答
1

如果处理请求需要很长时间，例如。您正在做一些计算量非常大的事情，并且您不希望其他用户等待很长时间，App Engine 调度程序可能会启动您的应用程序的另一个实例来处理传入请求。

想象一下，计算密码的哈希值需要 1 分钟，而在那一分钟内，您的应用程序会收到另一个用户的请求。该用户可以等待一分钟以获得对其请求的响应，或者 App Engine 调度程序可以启动另一个实例来服务该请求并更快地获得响应。您可以使用管理控制台中应用程序设置页面上的性能滑块调整是否会出现另一个实例。

基本上，您需要询问的有关实例时间的问题是：您是否可能会收到重叠的请求（即，在当前请求完成之前收到新请求）。如果这种情况不经常发生，并且您希望为您的用户提供快速响应，您将需要预算更多的实例小时数。

我怀疑您需要进行的大型计算并不常见——例如，仅在初始登录时生成 cookie，而不是针对每个请求。

要明确回答您的问题 #1，进行多次迭代只会在导致重叠请求时对您的实例小时数产生影响。如果您每 30 秒只收到一个请求，则您可以花费 30 秒来处理每个请求（包括计算每个哈希和执行其他操作）并且不超过您的免费实例小时配额。相反，如果您每秒收到 10 个请求并花费超过 100 毫秒来处理请求，那么您将很快开始超过您的实例小时数。

于 2012-07-17T15:08:48.377 回答
0

有多个来源涵盖密码。您显然已经阅读了一些鼓励多遍散列的内容。在最终确定此决定之前，请考虑下面的第一个链接。此页面的摘录：“很容易得意忘形并尝试组合不同的哈希函数，希望结果会更安全。但在实践中，这样做没有任何好处。它所做的只是产生互操作性问题，有时甚至会降低哈希的安全性。”

需要考虑两个有价值的链接（第一个有上面的引用，第二个是好的“如何”来源）：

http://crackstation.net/hashing-security.htm

http://throwingfire.com/storing-passwords-securely/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+throwingfire+%28Throwing+Fire%29#notpasswordhashes

于 2012-07-18T17:19:39.227 回答