Suggeston: Better wincmd.key protection
Moderators: Hacker, petermad, Stefan2, white
-
- Member
- Posts: 122
- Joined: 2011-10-10, 23:25 UTC
- ghisler(Author)
- Site Admin
- Posts: 50550
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Currently not, but we can certainly arrange something if it should be necessary.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
:mrgreen:
I have an idea that can solve this security problem, permanently.
An option for the user to bind the key to the local system used and to delete the original one or to move-it in a safe place. Such remaining key can not be stolen and administrators can access the original key for reuse and assume responsibility for its protection without having to worry about remaining key on the system.
Furthermore, if the generation of new keys is done online, the binding can be counted so that Christian can know if a user license is used on too many systems.
The idea would be a generated program code that combines the original key and the hash of the current system and would be placed on a site to download a personalized key or a direct generation to eliminate the use of a server; but then control is lost and no longer under surveillance if you understand me.
But, mandatory, it must be only optionally to keep the portability and so both sides are reconciled.

An option for the user to bind the key to the local system used and to delete the original one or to move-it in a safe place. Such remaining key can not be stolen and administrators can access the original key for reuse and assume responsibility for its protection without having to worry about remaining key on the system.
Furthermore, if the generation of new keys is done online, the binding can be counted so that Christian can know if a user license is used on too many systems.
The idea would be a generated program code that combines the original key and the hash of the current system and would be placed on a site to download a personalized key or a direct generation to eliminate the use of a server; but then control is lost and no longer under surveillance if you understand me.

But, mandatory, it must be only optionally to keep the portability and so both sides are reconciled.

And by the way, in my opinion, the "registry key" is a disaster in case of errors or reinstallation, but "bonded key" can be restored from a backup for use only in the original system. And in this situation is safe in case of fraud or theft/hacking.
Thanks for a wonderful program you have made. Keep up the good work and let him become a real shell in the near future
Thanks for a wonderful program you have made. Keep up the good work and let him become a real shell in the near future
Re: :mrgreen:
What is "using on too many systems"l3x0r wrote:Furthermore, if the generation of new keys is done online, the binding can be counted so that Christian can know if a user license is used on too many systems.

Im using TC portable on countless systems....
Still your system is overkill - the way its now is easy enough for a 2man company

Hoecker sie sind raus!
last idea and the desire final view
Here is how i wish to make selection of how the program behave.

- Installed Unprotected - Default
Installed Protected - Binded
Portable Unprotected - All files, settings and temps on the program folder.

8823
My ex:Sir_SiLvA wrote:What is "using on too many systems"![]()
I have a #***** 3 User licence for my pc/laptop/portable and i want to bind two of them for the safety but if the program detects that i binded my licente to another 2 -3 or 10 computers is ok because i can have that number or so, but if is detects over 100 computers is hard to think they all are mine.
Perhaps there are keys over #***** 100, but then you wonder if there is over 2000 uses, this is normal. if not then there is a problem
And this is way i stated to allow the portable licence active with all its implications.Im using TC portable on countless systems....
My "system", at least, local part of it, can be done very easy and offer a minimum security for the investment. It is about the local generation of encrypted keys with original key as source and use it instead of the original. This can be done with a simple algorithm, Personally, I use this method in some programs, and because the original key is removed from the disk, even I can not recreate the original key from an encrypted one, even though I know the encryption algorithm.Still your system is overkill - the way its now is easy enough for a 2man company

-
- Member
- Posts: 122
- Joined: 2011-10-10, 23:25 UTC
Why not attach the key as alternate stream to the executable or a certain (maybe random) dll. This means that the key is harder to find and goes lost if the file is emailed, downloaded or moved to an NON-NTFS filesystem. Also many packers don't respect the alternate stream and 'forget' to pack these as well.
Downside is that you can't use the program on FAT-formatted drives, but in those cases one can always fall back to an ordinary key file, which ofcourse does not have the additional protection. As an additional measure, you could encrypt the file on a way that there are two ways to open it:
- manually using a password
- automatically using a key stored in the users registry
When the program runs from an USB-stick for the first time on a new pc, it finds the keyfile and asks for the password and whether the pc is 'trusted' and should be able to open the key automatically. In other words:
The later option could also be used with a centralized keyfile stored on a TC-server. However, I often work on machines that are not connected to the internet. So I don't like the idea of the TC-server as solitary way to keep the program active.
Downside is that you can't use the program on FAT-formatted drives, but in those cases one can always fall back to an ordinary key file, which ofcourse does not have the additional protection. As an additional measure, you could encrypt the file on a way that there are two ways to open it:
- manually using a password
- automatically using a key stored in the users registry
When the program runs from an USB-stick for the first time on a new pc, it finds the keyfile and asks for the password and whether the pc is 'trusted' and should be able to open the key automatically. In other words:
- the keyfile as it is now (using the async-encrypted key) will be encrypted with a random key (1) using a synchronous method.
- the random key (1) is encrypted using a plaintext password as key (2) and appended to the file.
- On each 'trusted' computer the random key (1) is encrypted again with another random key (2) which is stored in the registry for easy (automatic) decryption of the first random key (1) and in turn the keyfile.
- Another option is similar to the last, except that the random key (2) is then stored in the roaming profile or Active Directory OR the key is generated from information uniquely available to the user. Such as the users private key on his or her EFS-certificate. This ensures the key can be automatically decrypted on every machine in the domain or forest the user has access to.
The later option could also be used with a centralized keyfile stored on a TC-server. However, I often work on machines that are not connected to the internet. So I don't like the idea of the TC-server as solitary way to keep the program active.