Java 在Google应用程序引擎中哈希密码和实例小时配额

我已经读了很多关于密码存储、哈希、盐渍、“胡椒”、MAC等的书，因为我即将建立一个新网站，它的安全性对我来说真的很重要，但是我考虑不使用谷歌身份验证（或Facebook、OpenID或任何其他）的原因目前并不相关，但这让我想到了这一点

我是谷歌应用程序引擎的新手，这将是我在谷歌应用程序引擎上的第一个项目，我对“实例时间”和它如何不再有“CPU时间”，而是前面提到的配额感到有点困惑。更糟糕的是，我还不能理解什么是实例小时免费配额

以下是我担心配额的原因，以及这与我的安全顾虑有什么关系：我在任何地方都读过的一条建议是进行多次迭代并多次散列密码，因为这会让攻击者和攻击者花费更多的时间（我没有数字，但它们无处不在）

多次迭代对CPU时间有直接影响，如果GAE有一个CPU时间配额，我认为每次用户登录时进行1000次迭代可能是一个问题，但是如果它们计算的是从请求完成到15分钟后的实例小时数，则如下所示：

通常情况下，实例使用量是根据时间按小时计费的 实例的正常运行时间。在实例开始和结束时开始计费 实例关闭15分钟后。您将只收取账单 对于空闲实例，不超过中设置的最大空闲实例数 管理控制台的“性能设置”选项卡。运行时开销是 根据实例内存计算

那么这意味着如果我的用户登录（散列1000次），那么他们将继续使用该站点，实例小时数将继续相加，直到他们全部离开页面+15分钟？如果这是真的，那么让它重复1000次不会对我的配额产生重大影响，除了用户登录所需的“额外”时间，但我知道这一点，我愿意为此付出代价

我将进行的迭代次数将使用户能够接受和察觉登录时间，所以不要担心这一点

我的问题是：

进行多次迭代是否会直接影响实例小时数，或者我对实例小时数相加方式的假设是否正确？

谷歌应用程序引擎上是否有我遗漏的CPU时间配额？它有免费配额吗？

实例小时免费配额是多少？

答复:

看，她接受了答案和他问的另一个问题（没有回答，但有有用的评论）

根据谷歌的说法，没有CPU时间配额：

在此处找到问题3的答案：

---

实例时间是服务器运行、应答请求等的时间。如果您的服务器没有运行，它就不能在请求或任何事情发生时唤醒

将实例时间想象为打开计算机。当它打开时，您将收到账单，而不是当它关闭时

您可能有多个实例，所以假设您有两个实例，您燃烧的实例时间是原来的两倍

---

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

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

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

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

我怀疑，您需要进行的大型计算将不太频繁——只在初始登录时生成cookie，比如说，而不是针对每个请求

---

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

密码有多个来源。显然，您已经阅读了一些鼓励多次散列的文章。在完成这个决定之前，考虑下面的第一个环节。本页摘录：“人们很容易忘乎所以，尝试组合不同的散列函数，希望结果会更安全。但在实践中，这样做没有任何好处。它所做的只是造成互操作性问题，有时甚至会使散列更不安全。”

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

---

实例小时的免费配额是多少？我希望我的网站能全天候运行，但是我不需要