Google App Engine 中的哈希密码和实例小时数配额答案

【问题标题】：Hashing Password in Google App Engine and Instance Hours QuotaGoogle App Engine 中的哈希密码和实例小时数配额
【发布时间】：2012-07-16 08:15:01
【问题描述】：

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

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

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

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

一般情况下，实例使用量按小时计费，具体取决于实例的正常运行时间。计费在实例启动和结束时开始实例关闭十五分钟后。您只需支付费用对于空闲实例，最多为设置的最大空闲实例数管理控制台的性能设置选项卡。运行时开销是计入实例内存。

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

我将进行的迭代次数将使登录时间能够被用户接受且不易察觉，因此不必担心。

我的问题是：

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

答案：

看 Moishe 接受了答案和他提出的另一个问题（尚未回答但有有用的 cmets）When does the App Engine scheduler use a new thread vs. a new instance?
根据谷歌没有 CPU 时间配额：http://googleappengine.blogspot.com.es/2009/02/skys-almost-limit-high-cpu-is-no-more.html
在这里找到第 3 个问题的答案：Google App Engine Frontend Instance Hours Limit Reached

【问题讨论】：

您能否提供一个可靠文章的链接，该文章建议调用哈希 1000 次以获得更好的安全性？
这不是关于密码的安全性，而是关于破解经过多次哈希的密码所需的时间。我会提供链接，请给我几分钟时间
但是这个问题也有更多投票的答案（目前31）。为什么不是这个答案？
@IgorArtamonov 因为我的问题是关于 Google App Engine 和 Instance Hours 免费配额，我只是想为我的问题提供背景信息。我不是在问是否要对其进行 1000 次或 1 次散列，而是 GAE 在 Instance Hours 上的免费配额是多少，什么是“Instance Hours”。 Marcus Adams 已经回答了我什么是实例时间，我正在等待免费配额的答案
@IgorArtamonov 我编辑了我的问题以更清楚地说明我在问什么

标签： java security google-app-engine passwords hash

【解决方案1】：

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

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

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

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

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

【讨论】：

谢谢！你说了我没想到的话。每个实例只有一个“处理线程”，对吧？因此，如果我将我的 GAE 帐户限制为仅使用一个实例以确保我不会超过配额，我有用户等待很长时间的风险，因为唯一的实例正忙于处理“大计算”？你说得对，这只是在初始登录时计算，而不是在每个请求时计算
是的，如果您只限制一个实例，您会冒着让用户等待很长时间的风险。我相信每个实例只有一个“处理线程”，但我问了这个问题以澄清：stackoverflow.com/questions/11525717/…
需要考虑的一点：您可以编写一个 App Engine 应用程序，其工作是完成计算量大的部分。然后让您的“主要”应用程序对该应用程序执行 urlfetch，因此您可以在主应用程序中有多个线程等待哈希应用程序，并单独调整您的实例时间。这实际上与将散列“外包”给 OpenID 提供商相同。
谢谢@Moishe，这就解决了。我会检查另一个问题的答案。

【解决方案2】：

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

将实例时间想象为计算机处于开启状态。开启时向您收费，关闭时不计费。

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

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

【讨论】：

实例小时免费配额是多少？我希望我的网站能够 24/7 全天候运行，但是我不希望有太多用户，所以一个实例可能就足够了。 GAE 真的不再计算（或有配额）CPU 时间了吗？
@hectorg87，小时的免费配额，在你的情况下，因为它将运行 24/7，你可以想象它是一个折扣。在他们开始向您收费之前，您可以获得那么多免费时间。我使用亚马逊云服务，也是这样。如果服务器很忙，我会被限制到我支付的 CPU 级别。流程将花费更长的时间，但不会花费更多。
很抱歉，但现在我更加困惑了。 “折扣”是什么意思。据我了解，GAE 的收费方式与亚马逊不同，免费配额每天都会重置，只要我低于该配额，它将“永远”免费运行。这不正确吗？
@hectorg87，嗯，对不起，如果它与亚马逊不同，那我不知道。也许其他人可以回答有关配额的问题。希望我至少解释了实例时间。亚马逊的收费堆栈。有小时配额和带宽配额等。
谢谢@Marcus，然后我将等待有关 GAE 实例时间配额的具体答复。

【解决方案3】：

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

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

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

【讨论】：

嗨@stevep。实际上，我正在做他们推荐的事情，通过键拉伸使散列过程变慢。这就是我担心 Google App Engine 中的实例小时数和 CPU 时间的原因。感谢您的链接