为了安全起见，要考虑的一件重要事情是对主密码进行详尽的搜索是可行的。示意性地，获得特定站点密码的攻击者（例如，该站点上的邪恶管理员）可以运行您的 Java 应用程序（或他自己的一些应用相同算法的代码）并“尝试”潜在的主密码，看看它是否产生已知的特定于站点的密码。

如果您的主密码是胖且随机的（例如，至少 70 位熵），那么这将不是问题。但是，如果您的主密码更“正常”（例如，“强”密码是 45 位熵），那么这是一个弱点。可以通过使用正确的密码散列来改善这种情况：

• 您需要通过使用多次迭代将主密码转换为特定于站点的密码变慢。
• 你需要盐。在这种情况下，假设有 10000 人使用您的系统并且所有人都有一个帐户，比如说，google.com（一个虚构的例子）。他们都将使用“google.com”作为“密码使用”。相应地，google.com 的邪恶管理员可以并行攻击所有 10000 个主密码，并分摊大量成本。你可以用你自己的名字作为盐；名称不是完全好的盐，但这仍然会显着改善这种情况。

这是“蛮力”，但是对于人类记住的密码，蛮力往往会起作用。

对于可用性，可能存在一些问题：

• 您必须记住在每个站点上使用的密码长度。

• 一些网站有特殊要求，并且没有适用于任何地方的“一刀切”的规则集（例如，一些网站强制使用标点​​符号，而另一些则禁止标点符号）。

• 某些网站可能会要求更改密码。根据定义，您的小程序不能容忍密码更改，除非您使用新的“使用”字符串，然后您必须记住它。

• 除了对密码散列不理想之外，Sun/Oracle 的默认实现SecureRandom没有很好地指定，并且不能保证永远不会更改。如果 Oracle 决定在某个时候修改它，您的所有密码都将丢失。你真的应该依赖一些不受这种变化影响的算法。

• 祝你在 iPhone 或 iPad 上运行 Java 代码好运。为了真正的可移植性（包括让你的代码在你将拥有 5 年的机器上运行），你可能需要用几种语言来实现你的算法，因为没有一种语言可以统治它们。这再次意味着使用定义明确的标准，而不是“Java 目前似乎使用的 PRNG 算法”。

由于上述所有原因，制作一个不需要存储空间的“密码钱包”具有挑战性。这个概念已经被提出甚至实施了很多次，并且可能适用于大多数站点，因此您可以容忍它供您自己使用。取决于您自己的上下文（您使用哪个站点，您拥有什么样的硬件和操作系统......）。

Tom Leek 的回答是对您的密码多样化方案的出色评论，因此我不会试图用我自己的劣质话重复他写的内容。在这个答案中，我将专注于与唯一密码的比较。

安全方面，唯一密码（独立生成）的优点是，违反一个密码不会泄露有关其他密码的任何信息。

在可用性方面，您的方案需要计算设备从主密码生成站点密码。（我假设你无法SecureRandom在脑海中重现计算。）这个计算设备必须是可信的，因为你将在那里输入主密码。

使用唯一密码，您可以拥有一个加密的密码存档，并使用主密码对其进行解密。为了达到相同的安全级别，您需要避免来自主密码的暴力攻击，仅此而已。特别是，如果您的加密密码存档是公开的，则此方案可实现与您相同的安全级别——主密码泄露会泄露一切。因此，您只需要解密阶段的安全性，而不需要加密密码存档的存储。（然而，存储安全性会提高方案的安全性。）

因此，拥有独立密码的唯一要求是不受信任的存储设施，可以由受信任的计算设备访问。在实践中，这个要求很容易满足：要么你用于计算的设备有存储空间，要么你足够信任它来下载你的密码存档。

备份和同步密码存档的要求并不繁琐；鉴于当今无处不在的连接性，它实际上比您的密码生成方案限制更少。在每个通用平台上都有无缝同步文件的服务。您可以将受强密码保护的密码存档与中等信任级别的服务同步。如果您的某些设备比其他设备更受信任，您可以将完整存档保存在最受信任的设备上，并将包含一些不太重要的密码的子集保存在不太受信任的设备上。

虽然您的方法从根本上没有错误，但与更安全的唯一密码方法相比，它没有实际好处，而且灵活性较低。所以使用唯一的密码。