4

我有一个创建序列号的应用程序，如下所示：

Take customername
Sign customername using privatekey and sha/dsa algorithm

然后可以通过使用公钥解码来检查许可证，并检查客户名称匹配

除了生成的序列相当长之外，这可以正常工作。因此，客户输入序列号实际上并不实用，而是必须在文件中提供序列号，这与雾应用程序的工作方式有很大不同，而且令人困惑。

许多其他应用程序只是在用户购买时为他们提供一个 Guid

即5bd1060b-8608-4817-93ca-207f7c828e2f

用户必须输入他们的电子邮件地址和 guid 才能许可他们的应用程序。

对于用户来说，这看起来像是一个更简洁的解决方案，但我不明白这样的应用程序如何从无效的 guid 中验证有效的 guid，除非它通过检查数据库上的电子邮件地址/guid 对在线完成。但我真的希望在不需要在线检查的情况下进行某种验证：

a>如果互联网连接/我的服务器关闭，应用程序将无法运行，或者 b>他们可以通过禁用互联网访问来规避检查

编辑：

我的理解解决方案由以下答案提出：

用户进行购买
Take emailaddress + salt
用 SHA1 加密给出 160 位哈希
转换为十六进制表示法给出 20 个十六进制值，即
最后 8 个字符的 40 个字符 Lop 给出一个 Guid
电子邮件用户 Gui 和他们输入程序的电子邮件地址 程序通过以下方式验证此配对获取电子邮件地址、添加盐、加密 ectera 并检查会生成有效的 guid。

我的主要问题是我需要将盐存储在程序中的某个地方，因此如果黑客找到了盐并弄清楚我在做什么，他们可以为任何电子邮件地址创建一个有效的许可证密钥生成器。

我目前对另一个程序的方法：

我已经生成了一个公钥/私钥对
用户进行购买
我通过签署
电子邮件地址生成许可证 BaseEncode 生成的许可证 将许可证
发送给用户
程序通过使用公钥和解密来验证许可证

我的问题是，当我签署电子邮件地址时太长，所以我最终将它放在一个文件中，而不是用户将它输入到一个字段中，但问题可能是我是 base64 编码而不是转换为十六进制。

签名的输出可以多长时间，它取决于输入的长度还是总是相同的？

因为我用公钥解密了密钥，所以我无法删除许可证密钥的一些字符，但如果生成密钥只有 40 个字符，我想那没关系

我认为这种方法的优点是，即使黑客知道我是如何做事的，他们也无法创建许可证生成器，因为他们没有，也无法获取私钥，因为它只存储在我的服务器上。他们只能在创建新的私钥/公钥配对时生成许可证，然后如果我的应用程序本身具有编码的公钥，则应用程序无论如何都可以拒绝许可证。

当然，他们可以破解应用程序，但如果应用程序定期更新，这将变得很费力。

总而言之： 我是否正确理解了这一点，哪种方法最好，以及为第二种方法生成了多少数据。

4

2 回答 2

1

我认为签名方法是目前的最佳实践。顺便提一句。有许多免费库涵盖了这个主题。

许可证密钥的长度至少由签名密钥长度决定——一个 1024 位的密钥产生一个 128 字节的许可证（如果没有添加其他有效负载）。

许可证文件通常包含有关许可使用本身的更多信息，例如有效期、许可子模块、吞吐量...... - 签名本身嵌入在此结构中。这样您可以获得灵活性，我强烈建议您使用此解决方案，即使许可证变得更大。

要在应用程序中导入许可证，您可以采用混合方式（就像我们所做的那样）。一方面，您可以提供经典的“导入许可证文件”解决方案。另一方面，我们生成一个随机的短 ID（如您的 GUID）并将其与许可证数据相关联。注册后，用户输入短 ID，应用程序通过 HTTP 查找完整的许可证。您必须只在线一次，您仍然可以提供复杂的许可证并且用户只需要一个简短的 ID。

编辑

  1. s签名的长度就是密钥的长度。例如 1024 位（或 128 字节）
  2. 如果您的应用程序知道哪些数据被签名（例如邮件），您可以单独使用此签名
  3. 您可以签署包含更多属性的“许可文件”，而不仅仅是邮件。在这种情况下，许可证包含属性和签名（因此，比仅签名更长）
  4. 您不需要在线连接进行许可证检查。只需使用应用程序导入许可证并随时检查。
  5. 除了许可证文件导入之外，您还可以使用短 ID 作为密钥在线下载许可证文件。许可证已下载并脱机。所以你有两全其美。
于 2012-09-01T09:01:19.690 回答
0

您可能只是散列与“秘密”盐连接的用户信息，然后截断散列。

黑客——只要他们对你的程序感兴趣——就会通过对源代码进行逆向工程来破解它：他们会找到哈希算法和秘密盐。

但这也会发生在您的 sign&verify 解决方案中：他们可以绕过检查使其返回 true。

因此，sign&verify 解决方案更复杂，但并不安全。

于 2012-08-23T17:07:50.397 回答