Total Commander

Server has to send enough information to authenticate the copy through the net. How can you prevent users from taking the info and using somewhere else?

Simple, just send info valid for that computer: PC sends hardware ID to key server - key server creates hardware-specific key, and sends it to the client -> key is invalid on other computers

So this is basically what I was talking about from the start, but with a _******_ on a server, right?

Correct. How else could it be done?

Trojan or a tool like current FTP Password Ripper, click and get the key.
It's really just a temporary solution.

So what would be a permanent solution? I don't see any so far which doesn't require a special online key server somewhere...

Just an idea: for places like universities and corporations the key could include also a connection to ActiveDirectory. In other words, one must be a member of a group in the AD.

I was also thinking about the registry key. The first time the key is placed in the same folder, TC reads it and creates a unique registry entry that is specific to the machine. Then the key may be deleted. I am probably shooting myself in a foot here . but this way I could have TC registered both at home and at work and not be afraid that someone (especially evil admins at work) would steal my key file. And I would not have to carry the key file on the usb stick.

I have thought about that too, but the problem is that people who upgrade their PCs would then constantly ask for new keys. You can place the key in the registry already, but it's not encrypted. The problem is that when TC can read it, any other program can read it too.

In my work place;

1) I located the key file in a special folder on the server. This special folder is under a protected folder which is not permitted to be viewed by the users (deny is only for the protected folder itself, not for the sub folders). So, since the users can not access to the protected folder, they can not view the contents of the folder.

2) I set the KeyPath value to this special folder in wincmd.ini.

By this way, I protected the key file a little bit for the unexperienced users. When the users try to copy the TC program folder to their own media, they can not get the key file.

But when the experienced users exist in the environment, they can easily obtain the key file by looking the location of the key file in wincmd.ini.

This may be prevented by encrypting the KeyPath value (key file location) like the one for FTP passwords. This encryption tool may be an external program in the total commander program folder.

-------------------------------------------

In my portable disk;

I assigned the key path location (in wincmd.ini) to a drive created by TrueCrypt program. This solves the key protection problem for me in my portable disk.

Regards

We have faced the same problem.

We are going to purchase business licenses therefore we need to protect wincmd.key. What about implementing the following solution (very similar to the already suggested):

1. wincmd.key can contain not only company information but also hardware information.
2. TC reads key, compares hardware information and runs only if it corresponds to hardware.
3. Hardware ID string can be acquired using special utility being run on the target machine.
4. Information in wincmd.key can be signed in two ways:
   • Christian runs server which accepts wincmd.key and hardware ID string and produces wincmd.key tied to the hardware ID.
   • Christian provides private and public key pair tied to company, utility to get hardware ID, utility to add hardware ID to wincmd.key and to sign it. Administrator generates unique wincmd.key for the every machine and put the generated keys to the machines.
5. This protection scheme is optional and user decides whether he will use it.

For me the first way seems to be less secure as it provides the possibility to steal Christian’s private key.
The second way seems to be good solution as it is not enough to steal wincmd.key. If keys are stolen then they are blacklisted and will not work with TC next version.

What do you think about the suggested solution?

ghisler(Author), I appreciate if you could check the suggested solution.

AndrewCreator wrote:ghisler(Author), I appreciate if you could check the suggested solution.

You dont need to bump Chris reads everything.
And your "solution" is overkill - this is not google or apple.

Sir_SiLvA, could you tell what do mean for «overkill»? Could you suggest the better one?

AndrewCreator wrote:Sir_SiLvA, could you tell what do mean for «overkill»? Could you suggest the better one?

I agree with Sir_SiLvA, its an Overkill.
The cost of running a server and all that stuff around has to be added to the licence fee. As normal users and even most companies don't need such a protection it would require a more expensive business licence because we don't want to pay for such special need. Also it is clear that there will be cracks for whatever method Christian implements.

Implementing such a new key scheme would take several weeks - I'm not sure that this is really worth the trouble. If your key gets stolen and blocked, you can buy an update for $15. Compare that to the amount of work you have to put into giving each user an individual key...

I am sorry for misunderstanding.

I have described two ways to solve the problem. And I agree that the method with server is more difficult to implement and may be overkill. But the second one seems to be simple, easy to implement, easy to use, easy to automate.

ghisler(Author),
Do you mean the second way (key pair + signing utility) requires a lot of work?
How much will cost the update for 100 licenses if key is stolen?

Horst.Epp,
We are trying to find the solution to protect wincmd.key, not the TC. The easiest way to use TC without purchasing is to press 1-2-3.

How much will cost the update for 100 licenses if key is stolen?

The update costs $15 for 1 user or 100 users or 1000 user licence, it doesn't matter.

I have described two ways to solve the problem. And I agree that the method with server is more difficult to implement and may be overkill. But the second one seems to be simple, easy to implement, easy to use, easy to automate.

It's not that simple. We can't just write the computer data to the key, we must sign it - otherwise the key could be re-used on other computers. To sign it, we need a new signature scheme where we send private keys to companies, which they can then use to sign the wincmd.key themselves. These private keys must be signed by some master key, whose public key must be in TC. This is completely different from the current situation, where we sign the wincmd.key directly with our private key.

The update costs $15 for 1 user or 100 users or 1000 user licence, it doesn't matter.

Can these $15 be paid throw softkey.ru shop?

It's not that simple. We can't just write the computer data to the key, we must sign it - otherwise the key could be re-used on other computers. To sign it, we need a new signature scheme where we send private keys to companies, which they can then use to sign the wincmd.key themselves. These private keys must be signed by some master key, whose public key must be in TC. This is completely different from the current situation, where we sign the wincmd.key directly with our private key.

Here is the full process:

1. Company orders TC and optionally pays $10 to be able to protect wincmd.key from being stolen.
2. Christian creates wincmd.key signed by his private key, company’s private and public key pair.
3. Company administrator receives wincmd.key, key signing utility, private and public key pair.
4. Administrator signs the wincmd.key with company’s private key and puts new wincmd.key and public key in TC dir.

Could you tell what the drawbacks are in the suggested solution?

The drawback is that writing such a key signing utility would take a few weeks, time which I can't use to improve TC itself...

Let TC retrieve the key from a server in a slightly secure way, like using the server's public key. Document the procedure and add the url to options.

Let those interested in securing their keys write the server and protect its private key on their own.