Floating license server for TC

[misiekt]

But what would prevent anyone from putting it on the public internet

Short: EULA?


Priv/public keys would be individual for customer. Company providing public access to their license server clearly would act against law in most countries.
Besides, if they buy license for like 1000 seats, and server will generate only so much temp licenses, then why should you care who is using those licenses? Anyways, no company at their right mind would do that.

As for hack scenario. You could just ban priv/public pair and keys generated with it, same way now wincmd.key is banned and need an upgrade.

But lets be real, who is going to hack custom license server? Probability of loosing license that way is maybe 0.1% chance of that file just laying around.

cheers

[Sob]

Licence server would be useful for companies with trustworthy admins and too many regular users to fully trust them all, to make sure their keys do not leak. I'm not sure if it would be the same great deal for author. You can't really limit who gets the server software, so it must be assumed that everyone has access to it. They still need the keys, but there will be always some leaked ones. Then there's the limit for number of licences, but I'm sure it wouldn't be too hard to find a way around it (patch the server to ignore it, or make some kind of proxy to either request new key and immediately return it to server, but in fact keep it for client, or simply give one generated key to multiple clients, etc..). Author could try to prevent that by some technical means, but it quickly gets to overcomplicating it. In some sense there's no difference between hypothetical free licence server for everyone and current free leaked keys for everyone. But if there's million of users using leaked keys, there's big chance that some of them will eventually get tired searching for new ones and just buy their own. While with licence server there could be just few of them able to handle all those users. Too big and too public ones would probably not survive for too long, but it still seems it could be easier for users than it is now. So I understand author's concerns.

The funniest thing about this is the fact that TC has essentially zero protection against unauthorized use, so if someone wants to use it without paying, there's nothing stopping them. And they hunt for other's keys anyway and then stare at someone else's name in the title all the time, just to avoid clicking one button. People are strange. :)

[misiekt]

Still i cant see how it trumps current model, when everybody can get license for free forever, for any number of copies.

License server is something that needs some effort in maintaining, while copied keyfile doesn't. Now people put keys on public servers, dunno why would they bother jumping through hoops with license server.

As for returning early and keeping copy - c'mon. Now i can buy 1 licence and use it on 1000 computers in company. There's no limit at all. If some admin gets it with ill intent i dont know why they would bother with 100-seat license and license server?

Its not like by abusing server software they would get legit copies of TC. It would still be considered illegal by any standard. Same you can get Win OS by providing same key to any number of machines. Althou system works it doesnt make it legal, if you havent purchased appropriate number of licenses for that MAK.

Its no real drag, but you can make serwer software available only for multi user customers. It cuts down potential curious cracker who would download it from site for weekend project.

And again, server side would use encrypted private key and TC would use encrypted public key. If they would be both encrypted with TC master key. How does it differ from banning them like normal key is now?
Any temp licence generated with server using that priv/pub pair would be banned, and only older version TC would recognize it. Again how its less secure than current method?


That said, maybe for starters just make simple posibility of reading keyfile from authorized HTTP server, without storing it on local machine. Just keep it in memory, or write info in registry, like someone suggested before. So simple copy of TC directory wont run everywhere registered.

That's hardly any work at all code wise, and please dont tell me that is more abuse prone than simple putting TC key on public HTTP server without password at all, like some people doing now.

If someone wanna use illegal copy, there's really nothing you can do about it, but you can help people who actually care. Especially when theres no real work involved in latter case.

EDIT: One last thing, for "license server for all" concern. If its initially available only for multiseat customers, any leakage/public access to it would lag behind current normal key, which can be aquired by an average Joe.
So by the time someone put effort in making license server public, everyone interested in illegal key would get their copy already, which works forever. So again why bother with server access?

[fenix_productions]

Maybe this is wrong idea but…

Perhaps TC keys should be created in two ways:
- standard keys - for single user licence - no changes to current system,
- subkeys generated using freely available tool - such keys would be created by administrators. They should contain referee info about parent one and - in case of security breach - all of them would be blocked by TC when master key is. The main difference here is that TC would not need to keep HTTP connections alive and it would be completely up to administrators to maintain proper user+subkey security. With proper subkeys information storage (come on: simple TXT file would be enough) -> we have guilty one found right away.

BTW Subkeys should not need to be time limited (too much troubles).

Being honest: it is definitely job for an administrator to know who abused company trust and punish that person. I would rather like to know who broke into my house first rather than trying to get better lock. I don't want myself behind bars - "bad people" should be there.

[Balderstrom]

What about a SSL certificate type solution?

A TC Corporate license SSL-Type key is a privately generated key - that resides on the physical machine where the TC instance is located.

Inside the key is TC's actual license key, but it can't be decrypted until TC requests the "SALT" e.g. public key from the primary server.

To get TC's actual license-key one would need both the private and public key, and said user would need access to the (hopefully) secure server where the "public" ssl-type key is located.

Thus nothing could be leaked without the decrypting "public" key. And even if someone could get ALL of that, then only one key would need to be invalidated on TC's next update. And only one key would need to be replaced.


Another version of a similiar solution would place certain TC-Keys in their own "Corporate" group that REQUIRE the SSL-Type validation, and wont work as a human-readable key.
Further the "private key" that's generated could contain the server that needs to be talked to in order to get the "public" key to decrypt.

Thus even with both the public-key and private-key you still can't use the TC license as the stolen ppk's can't be modified to change what server needs to be contacted for authorization.

[Sob]

... or write info in registry, like someone suggested before. So simple copy of TC directory wont run everywhere registered.

Storing the key in registry was not a suggestion, it's already possible. Not that it would prevent any at least a little knowledgeable user to get it from there, but will stop those who simply copy whole program directory, so it's better than nothing I guess.

[misiekt]

Not that it would prevent any at least a little knowledgeable user to get it from there,

Thats true, but add user/pass authorization from HTTP ontop of that, and for common user it becomes more or less mystery.

What more, server can keep track of machines which were given license, with their MAC or whatever. When that is in picture, one could consider that TC would conect from time to time to that server with simple check. If that server should ban that machine TC would delete registration info.

Lets say one connection attempt each time TC is executed. If more than 10 times TC failed to connect for confirmation, then license is deleted.

Yeah it can be cracked and soforth, but again at square one - easier to just get copy of single user key once and forever.

I know nothing fancy, but since users are too lazy to click one button with unregistered version, i cant imagine they would make efforts to keep that licence, which gets removed each time TC fails authorization.

[Sob]

After reading the thread again once more (and more carefully it seems ;), I can see that the perfect solution was suggested already. And there's even no need to worry about public license server.

Simply put, keep it all open and let *anyone* generate the keys. Yeah, I know it might sound stupid, but it actually makes sense. Just do it exactly the same way as it's done with certificates. Let the licence files actually *be* certificates.

There would be Root CA (held by author), which would sign certificates (licence keys) bought by customers. Every customer certificate would be intermediate CA and could sign other certificates. Those would be licence keys for employees. TC would then verify its licence by simply verifying the whole certificate chain. Also the customer certificate could be used directly without issuing sub-certificates.

You don't trust your employees completely? Then just generate their certificates with short expiration date. And if they leak anyway (although they would be useful for only short time), you know exactly who's to blame. And because they will expire before they have any chance to spread, author won't have to block licence for your whole company. Or forget the expiration and just issue personalized certificates. You risk that your company's licence will be blocked if such certificate leaks, but it's still better than now, because at least you know the responsible person.

And some central management and licence servers? No problem, do it any way you want, there are tools for standard certificates available for every system. And if you're able to manage the network with many computers now, you won't have any problem updating the licence (one file or registry key) automatically.

[misiekt]

Yeah, thats great solution to problem. Haven't thought of that since i was hang up on compatibility with old key, and explaining that current registration model is WCS.
But I think it's great idea. I suppose TC is dependant on SSL lib already anyways.

Best to connect that with LDAP auth for automation on TC side. Once you remove user from LDAP they cant access cert anymore past their local expiration date.

Althou i recon those changes would require more coding effort than HTTP/old key solution.

cheers for idea

[Sob]

I would be more affraid about the need to maintain both systems (old keys and new keys) at the same time, that would be the real big change (alternatively replacing all existing keys with new ones is even worse).

So keeping the old key would be much better in this regard. Unfortunately this means solving the unsolvable - how to allow TC read the key, but prevent user from doing the same, although he has exactly the same rights as TC.

Currently you can only fool begginners:

Level 1: Put key into different directory and simple copy of whole TC directory won't work. But almost anyone can find the key in different location.
Level 2: Put key in registry, it's little more scary for regular users.

I can imagine even a little more challenging solution:

Level 3: The key (in current format, either on disk or in registry) would be encrypted using custom certificate. That certificate would be chosen by you and would be stored in system certificate store (and TC would need one new ini parameter to identify it). The private key would be marked as unexportable, so TC would be able to call system functions to decrypt the key using this certificate, but user would not be able to simply copy it. Copying just the key would be useless, because it would be encrypted. And copying the needed certificate would be prevented by system. Unfortunately it's not completely true, because even unexportable private keys can be exported, but not so many users know how to do it. But sooner or later someone would write simple user friendly one-click tool to export TC keys protected this way...

[misiekt]

Too much dependancy on OS imo. Some people dont use Windows, yet they still want to use TC., i.e under Wine.

how to allow TC read the key, but prevent user from doing the same, although he has exactly the same rights as TC.

Level 4: read it form TCP/IP and store it only in memory.
Level 5: use hardware protection.

Obviously hardware is too stiff. And TCP/IP can have multiple variations.

But i imagine, let current key stay the same, just add HTTP storing posibility. Sure, one can make one click tool to decrypt password for server.
Maybe key stored on HTTP could be simply encrypted with XOR, and decrypted on the fly. So even with password after downloading it manually it wouldnt work when copied to TC directory.

Doing more for old "forever" key is pointless, because any number of operations leads to fact that TC have read it too. Hence one can always write tool for extracting that key.

Then were back to square one, that TC should only need byproduct of a multiseat license, and never need to read license itself.

[Sob]

I admit that I have no idea how many big companies (who are the main target audience for this "extended protection against naughty employees") want to use TC with some non-Windows OS, i.e. if the dependency on OS would be problem or not.

About HTTP storage, why not. It's just a different kind of obstacle. Harder to get over for someone, easier for someone else.

[misiekt]

But if there will be only one version of TC with both methods, then os dependency can be problem for normal user too.
Anyways, some good points have been made, hopefully it will bear some results.

[ghisler(Author)]

Simply put, keep it all open and let *anyone* generate the keys. Yeah, I know it might sound stupid, but it actually makes sense. Just do it exactly the same way as it's done with certificates. Let the licence files actually *be* certificates.

There would be Root CA (held by author), which would sign certificates (licence keys) bought by customers. Every customer certificate would be intermediate CA and could sign other certificates. Those would be licence keys for employees. TC would then verify its licence by simply verifying the whole certificate chain. Also the customer certificate could be used directly without issuing sub-certificates.

That's exactly how I would implement a key server - TC would request a key from the server, and the server would create one which would be valid for, say, two month, and stored locally. After 1 month, TC would try to get the next key. This way users with notebooks/laptops could use TC for at least 1 month even if the PC isn't connected to the company network. Leaked keys would become invalid after max. 2 months.

The only problem is the key server with its master key, as I wrote above - if someone would steal it, he could put it on the Internet - it would need a new version of TC to block that.

[misiekt]

The only problem is the key server with its master key, as I wrote above - if someone would steal it, he could put it on the Internet - it would need a new version of TC to block that.

i was asking few times already, how is it worse than way it is now?
At least multiseat key would go to some more sec aware people. Besides master key doesnt have to work with TC, it could be special multiseat one good only for generating temp licenses. And max temp license would be say 3 months. With posibility to make it shorter, but not longer.

And second option with CA mechanism, you could CLR leaked master key so chain would fail. But then you have keep CA running, so its a drag.