如果我们想寻找现在不使用 scrypt 的合理理由，我们可以找到以下三个：

• 目前尚不清楚是否需要“记忆硬”功能，scrypt 支持的参数配置。Scrypt 最初旨在支持本地加密，尤其是整个系统加密。这意味着在系统启动过程中必须对密码进行哈希处理；那时，计算机无事可做，因此整个 CPU 和 RAM 可用于单个 scrypt；并且由于启动已经花费了不可忽略的时间，因此超过 5 或 10 秒的密码散列并不困难。

  一个典型的服务器将需要一个独特的配置，使用更少的 RAM（如果服务器必须为多个客户端提供服务并且在峰值负载下不会崩溃，那么服务器无法承受每个密码散列的千兆字节）和更少的 CPU（网站身份验证应该在不到 1 秒，因为用户没有耐心；而且，我们必须再次考虑峰值负载）。当配置为“服务器使用”时，scrypt 是否比 bcrypt 更好还有待观察；事实上，如果您需要将 CPU 使用率降低到每个散列大约 1 毫秒，那么 scrypt 使用的 RAM 比 bcrypt少，使后者成为更好的选择。

• 就记忆硬度而言，scrypt 并不是最理想的。一些基于 GPU 的优化仍然可以通过时间-内存权衡来实现。攻击者的收益并不是毁灭性的，但如果我们要改变我们的密码散列函数，那么我们不妨尝试找到一个能够兑现其承诺的函数。

可以在此演示文稿中找到此类问题和其他信息。总结一下：虽然 scrypt 设计中表达的想法很有趣，但密码学家的普遍感觉是应该有更多的研究；事实上，它促成了PHC：一个公开的竞争，本着过去的努力，如 AES、SHA-3 或 eSTREAM，提出和审查新的候选人。

如果您现在在生产中部署 scrypt，那么它应该相当强大，尽管它取决于您选择的参数。这是 5 年研究的主要结论：密码学是可靠的，存在时间-记忆权衡，这并不可怕，但我们没有太多关于如何以可行的方式配置它的指导在典型的服务器中很好。