我目前正在考虑一个可以离线（在线后）并且仍然能够安全地向用户提供身份验证的网络应用程序。（例如，在多用户环境中，防止其他用户访问是非常必要的。）
现在，我正在考虑使用一些盐进行密码哈希身份验证，并且刚刚看到这个 SO 问题：https : //stackoverflow.com/questions/7879641/user-authentication-in-offline-web-apps
但是由于这是一个网络环境，我不得不假设其他人可以访问应用程序的源代码，因此盐本身就被泄露了。（此外，攻击者可能会使用哈希本身来暴力破解密码本身。）
所以......总之，我的两个问题是：
我将在下面回答您的“2”个问题：
至于盐：盐应该是公开的。有时会使用额外的秘密值（例如，通过预先设置密码）。这通常被称为“胡椒”。
尝试使用客户端身份验证的 TLS。使用客户端证书中的凭据（在成功的身份验证和会话建立之后）提供访问控制。
是的，可以“以一种好的方式”派生 DES 密钥；使用具有高迭代次数和大随机盐的 PBKDF2。然而，由于暴力攻击，DES 密钥一旦用于加密就不再安全。
通用答案：如果可以离线执行基于密码的身份验证，那么应用程序必然包含确定给定密码是否正确所需的所有内容。这不可避免地意味着，通过转储完整的应用程序代码和内容，攻击者可以在自己的机器上“模拟”离线服务器，并在闲暇时尝试密码，仅受他可以召集的计算能力（他将购买多少台 PC或租金）以及验证每个密码的固有计算成本。这称为离线字典攻击情形。
充其量，在这种情况下，您可以通过使用慢散列（底层散列函数的多次迭代，或类似的东西）和盐（以防止并行攻击、成本共享、预计算表......）来提高成本。请参阅此答案以获得完整的治疗。
离线字典攻击令人担忧。处于这样的境地是不舒服的。如果用户在其智能手机上接受 1 秒等待验证，则智能手机 CPU 必须能够在一秒内验证密码。拥有几台好 PC 的攻击者将能够每秒“尝试”至少几十个密码；如果散列算法能很好地映射到现成的 GPU 可以做的事情，那么几百，攻击者很勤奋，直接去一些FPGA实现。此外，攻击者通常很有耐心，可以等待一到两周才能获得用户密码。这总共为攻击者提供了10 亿次密码尝试。
训练普通用户选择能够抵抗十亿个潜在密码的暴力攻击的密码是很困难的。有关该主题的一些讨论，请参阅此问题。另一方面，如果您要选择密码（不是用户），则选择 15 个随机字母的序列：即 70 位熵，这将抵抗足够长的时间来阻止攻击者（密码空间大小为 2 70是巨大的）。
请注意，盐并不意味着是秘密的，即使攻击者知道也是有效的。秘密盐不是盐，而是密钥。您不能在您的情况下遇到这种情况：必须假设攻击者转储并反向工程了完整的应用程序代码。在很大程度上，您的上下文类似于基于密码的加密：保护一段数据的机密性，关于秘密密码，无需特定硬件。