我一直在阅读很多关于密码存储，散列，腌制，“胡椒”，MAC等的内容，因为我即将创建一个新的网站和安全性对我来说非常重要，但是有一些原因我为什么我考虑过不使用现在不相关的Google身份验证（或Facebook，OpenID或其他任何内容），但这让我想到了这一点。
我是谷歌应用引擎的新手，这将是我的第一个项目，我对“实例时间”以及它不再具有“CPU时间”但上述配额有点困惑。更糟糕的是，我无法理解什么是实例小时免费配额。
这就是为什么我担心配额以及这与我的安全问题有什么关系：我到处读到的一个建议是进行多次迭代并多次散列密码，因为这会造成攻击者花费更多的时间（我没有数字，但它们在https://security.stackexchange.com/）无处不在。
多次迭代会直接影响CPU时间，如果GAE有CPU时间配额，我认为每次用户登录时都会进行1000次迭代可能会出现问题，但是如果他们计算的是从请求到的那一刻起的实例小时数最多十五分钟后完成，并在GAE quota docs上阅读：
通常，实例使用按小时计费 实例的正常运行时间。实例开始和结束时开始计费 实例关闭后十五分钟。您只需支付费用 对于空闲实例，最多设置为最大空闲实例数 管理控制台的“性能设置”选项卡。运行时开销是 计算实例内存。
那么这意味着如果我的用户登录（哈希1000次），然后他们继续使用该网站，实例时间将继续总和，直到所有人离开页面+ 15分钟？如果这是真的，那么让它迭代1000次不会对我的配额产生重大影响，除了用户登录所需的“额外”时间，但我知道这一点，这是一个价格我我愿意付钱。
我将进行的迭代次数将使得用户登录的时间可以接受并且难以察觉，所以不要担心这一点。
我的问题是：
数目：
答案 0 :(得分：1)
服务器正在运行，应答请求等等，实例时间很长。如果您的服务器没有运行，它就无法在请求或任何事情上唤醒。
想象一下打开计算机的实例时间。当它打开时，您需要付费，而不是在它关闭时。
你可能有多个实例，所以假设你有两个实例，你的实例时间是两倍。
您的密码散列不会影响这一点，因为它只会在实例打开时产生实例小时，当它关闭时，它不会产生任何实例小时，但它也不会散列。
答案 1 :(得分：1)
如果处理请求需要很长时间，例如。你正在做一些计算量很大的事情，并且你不希望其他用户等待很长时间，App Engine调度程序可能会启动你的应用程序的另一个实例来提供传入的请求。
想象一下，计算密码的哈希需要1分钟，在那一分钟内，您的应用程序会收到另一个用户的请求。该用户可以等待一分钟来获得对其请求的响应，或者App Engine调度程序可以启动另一个实例来为该请求提供服务并更快地获得响应。您可以使用管理控制台中“应用程序设置”页面上的“性能”滑块来调整是否出现另一个实例。
基本上，您需要询问实例时间的问题是：您是否可能会收到重叠请求（即在当前请求完成之前有新请求）。如果这种情况不经常发生，并且您希望对用户做出快速响应，则需要预算更多的实例时间。
我怀疑你需要做的大计算很少 - 只有在初始登录时生成一个cookie，比如说，而不是每个请求。
要明确回答您的问题＃1，如果导致重叠请求，则进行多次迭代只会对您的实例小时产生影响。如果您每30秒只收到一个请求，则可能需要花费30秒为每个请求提供服务（包括计算每个哈希值，并执行其他操作），并且不会超过您的免费实例小时配额。相反，如果您每秒收到10个请求并且花费超过100毫秒来处理请求，那么您将很快开始超出实例时间。
答案 2 :(得分：0)
有多个来源涵盖密码。你显然已经读过一些鼓励多遍散列的东西。在最终确定此决定之前，请考虑以下第一个链接。摘自本页：＆＃34;它很容易被带走并尝试组合不同的哈希函数，希望结果更安全。但实际上，这样做没有任何好处。它所做的只是创建互操作性问题，有时甚至可能使哈希的安全性降低。＆＃34;
要考虑的两个有价值的链接（首先是上面引用，第二个是好的＆＃34;如何＆＃34;来源）：