正确的方法来激活和监控通过在线检查软件许可证 [英] The right way to activate and monitor software license through online checking

查看:740
本文介绍了正确的方法来激活和监控通过在线检查软件许可证的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我要提供在C#应用程序,以防止未经授权的复制激活方法。该应用程序依赖于网络上,我知道客户有互联网连接。

I want to provide an activation method for an application in C# to prevent unauthorized copy. The application relies on the Web and I know that the customer has an internet connection.

第一次客户登记他的要求输入电子邮件地址申请这是他购买的软件,那么我这个电子邮件地址和机器ID发送到服务器,如果电子邮件地址存在,我记录的计算机信息并返回成功。

For the first time that customer registers the application he is requested to enter the email address by which he purchased the software, then I send this email address and a machine id to a server, if the email address exists, I record the computer information and return success.

要监视它,我可以定期发送计算机信息到服务器并检查其是否已经注册,或者没有,或者如果它只能运行在计算机上的极少数,如果不锁定软件。我想,那我不需要任何密钥生成和加密(私有公用密钥),对吧?

To monitor it, I can periodically send the computer information to the server and check if it is already registered or not, or if it only runs on few number of computers, and if not lock the software. I think then I don't need any key generation or encryption (private public keys), right?

它是激活软件的标准方法?
什么是它的缺点。和利弊。与其他替代品(公共密钥...)比较

Is it an standard way to activate a software? What is its cons. and pros. compared with other alternatives (public private key...)

什么是做这种做法的正确方法?

推荐答案

根据的前提是,应用程序依赖于网络上,我知道客户有互联网连接,你有优势。您可以使用类似于如何散列密码存储的典范。这将是相当简单,准系统,但应该工作。

Based on the premise that The application relies on the Web and I know that the customer has an internet connection, you have an advantage. You could use a model similar to how hashed passwords are stored. It would be fairly simple and barebones, but should work.

而不是利弊游戏,这是不适合的话,我会勾勒出一个过程。此外,由于OP询问许可,我不打算解决版权保护问题无数。

Rather than the pros and cons game which is ill suited for SO, I'll sketch out a process. Also, since the OP asks about licensing, I am not going to address the myriad of copy protection issues.

在输入密码将是东西的集合,唯一标识用户,机器和软件项目的立场。

The stand in for the password would be a collection of stuff that uniquely identifies the user, machine and software item.

您可以使用一个以上的事情,有些事情是比别人做得更好。窗户串口,激活密钥,CPU ID,BIOS等等系列都是不错的人选。硬盘序列是没有的。

You can use more than one thing, some things are better than others. Windows Serial, Activation Key, CPU Id, BIOS Serial among others are all good candidates. The Hard Disk Serial is not.

自然地,如果用户的升级或替换可以锁定到的东西,许可证不会验证。考虑出现在您的书面授权(例如,一个故障更换主板)。

Naturally, if the user upgrades or replaces something you lock to, the license will not validate. Account for that in your written license (eg a faulty motherboard replacement).

我会绝对包含代表产品版本的东西,一个GUID或简单的东西如ZiggyWare 1.x的。只要每个版本使用相同的文字,许可证将验证。当你想要求他们升级,更改文本。例如,2.0版本可以使用ZiggyWare 2.x的

I would definitely include something representing the product-version, a Guid or something as simple as "ZiggyWare 1.x". As long as each version uses that same text, licenses will validate. When you want to require them to upgrade, change the text. For example, version 2.0 might use "ZiggyWare 2.x".

在同一台机器现在将产生一个新的哈希值。为版本1 x哈希不会验证为版本2.x,这是点

The same machine will now produce a new hash. The hash for version 1.x wont validate for Version 2.x, which is the point.

胶从数据与用户的电子邮件及软件版本串锁和散列它。这是用户令牌(密码)。该客户端应用程序产生这个提交给服务器或支付包括(后来核实)。

Glue the data from the locks together with the user email and software version string and hash it. This is the user token ("password"). The client app produces this to submit to the server or to include with payment (and later for verifying).

样品的Json

{
    "Series": "ZiggyWare 1.x",
    "User": "ziggy@ziggysplace.net",
    "DisplayName": "Mr Ziggy",
    "Data": "JTj6qds75Ebvd9ORjyyDszHSg2ylX4cdHVfWCaa9CLs="
}

这不一定是JSON,您可以使用序列化的文件或一个Base64字符串。这是一个实现细节。

It need not be json, you can use a serialized file or a Base64 string. That is an implementation detail.

散列

散列具有多种用途:它混淆你正在收集什么,它缩短了将要发送的数据,并因为你没有收集自动法定权利和商店的那些连续它绕开某些隐私问题。在这里,他们只是用来创建一个签名。

Hashing serves several purposes: it obfuscates what you are collecting, it shortens the data to be sent and it steers clear of certain privacy issues since you don't have an automatic legal right to collect and store those serials. Here, they are just used to create a signature.

基本上,对待该数据的散列作为密码。如果服务器遭到攻击,你不想在野外所有这些许可密钥。有人可能会用它们来欺骗发送的验证邮件。

Basically, treat that data hash as a password. If the server comes under attack, you dont want all those license keys in the wild. Someone could use them to spoof the verification messages sent.

您还需要创建一个唯一的用户ID。或许的名称和产品码(QGVBD-DYT5D -...)或确定性GUID的Base26散列。

You also need to create a unique user Id. Perhaps a Base26 hash of the name and product code ("QGVBD-DYT5D-...") or a Deterministic GUID.

取数据令牌,加点盐,即使再次本身就是一个哈希散列它。保存用户ID,盐和在数据库中的新的哈希值。我还保存其他几个东西,如一个 CreatedDate 产品-版本字符串。不要保存JSON数据令牌 - 这是一个明文密码相当于

Take the Data Token, add some salt and even though it is itself a hash, hash it again. Save the user id, the salt and the new hash in the database. I'd also save several other things, like a CreatedDate and that Product-Version string. Don't save that json data token - it is the equivalent of a plaintext password!

发送用户ID /串行回它们粘贴到您的应用程序,它可以节省它某处。它不是秘密,它不是符合他们的利益将其删除或更改。他们可以分享它,但它通常不会做任何好处。它只会与一台机器的软件版本中创建的数据令牌工作。

Send the user Id/serial back to them to paste into your app which saves it somewhere. Its not secret, its not in their interest to delete it or change it. They can share it, but it normally wont do any good. It will only work with a data token created on that one machine-software version.

要验证许可证,客户端应用程序将大大创建相同的消息,但随着用户ID包括在内。例如:

To verify the license, the client app would create much the same message, but with the user ID included. Example:

{
    "Series": "ZiggyWare 1.x",
    "User": "ziggy@ziggysplace.net",
    "DisplayName": "Mr Ziggy",
    "Data": "JTj6qds75Ebvd9ORjyyDszHSg2ylX4cdHVfWCaa9CLs=",
    "UserId": "QGVBD-DYT5D-JKDN7-VYX3J"
}

验证它,就像你会为一个哈希密码:

Validate it just like you would for a hashed password:


  • 获取记录该用户ID

  • 恢复原来使用的盐

  • 哈希JSON数据使用盐令牌

  • 的结果进行比较到存储在数据库中

  • Get the record for that UserId
  • Recover the salt originally used
  • Hash the json data token using the salt
  • Compare the result to that stored in the DB

如果JSON的消息是从同一台计算机 - 并没有什么变化 - 哈希结果应该与存储在数据库中的之一。就像密码。

If the json message is from the same machine - and nothing changed - the hash result should match the one stored in the database. Just like passwords.

如果你担心回被以某种方式欺骗,因此该应用总是能看到,你可能包括一个基于RSA身份验证令牌。

If you are worried about the return being somehow spoofed so the app always sees True, you could include an RSA based authentication token.

您也可以允许临时或暂时返回true。如果该用户名,但软件版本犯规匹配的入口,也许是一个合法的用户尝试一个新的版本。你可以允许它在未来X天正常运行,使他们能够在升级之前尝试新的版本。在宽限期之后,返回将是错误的。

You could also allow for a provisional or temporarily true return. If there is an entry for that UserID but the Software-Version doesnt match, perhaps a legit user is trying a new version. You could allow for it to run normally for the next X days so they can try the new version before upgrading. After the grace period, the return would be false.

任意日期跟踪当然是在服务器上完成的。你根本无法保持客户端PC上的秘密。

Any date tracking is of course done on the server. You simply cannot keep a secret on the Client PC.

对于这个来自这个问题:来监视它,我可以定期对计算机信息发送给服务器。我不知道你通过定期的意思,但因为它不意味着每次运行时,这是一个非常坏主意。

Regarding this from the question: To monitor it, I can periodically send the computer information to the server. I am not sure what you mean by periodically, but since it doesnt mean "every time it runs", that is a very bad idea.

做的定期的唯一的办法是,如果你保存它上次检查和/或最后的结果。这将创建一个简单的方法破解你的计划:用户只需要打开/创建文件并更新最后一次检查日期和/或最后的结果。该软件无需甚至登记!

The only way to do periodically is if you saved the last time it was checked and/or the last result. This creates an easy way to hack your scheme: the user just needs to open/create that file and update the last checked date and/or last result. The software need not even be registered!

即使是加密的,这是小事找到用于加密和写一个小应用程序来创建任意日期的文件和/或导致所需的数据。你根本无法保持客户端PC上的秘密。

Even if it is encrypted, it is trivial to find the data used to encrypt it and write a little app to create that file with any date and/or result desired. You simply cannot keep a secret on the Client PC.

一个简单的方法来阻止任何方案是修补的客户端应用程序。在您的代码最终,你最终是这样的:

An easy way to thwart any scheme is to patch the Client app. In your code ultimately, you end up with something like:

IsRegistered = appLicense.Verify();



这可配接:

Which can be patched to:

IsRegistered = true;

这篇关于正确的方法来激活和监控通过在线检查软件许可证的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆