I think it's odd to offer a service like this with no protection against cracking.
I mean, sure, I licence one of my own products with a RSAPSS signature on an environmental constraint .. but if somebody went to the effort they could just flip a single instruction to bypass it. However, I am pretty sure nobody in my target market will bother.
However, I don't think that would hold with something like this. What stops people releasing a bunch of generic bypass/crack tools against your client SDKs?
No matter what you invent, somebody will anyways crack it. As you increase the complexity, you risk introducing some problems for the paying customers. Even if the system is relatively easy to crack, it can still serve a purpose. People can't just ignore the license restrictions, they actually need to acknowledge the restrictions and then do some active work to circumvent those.
To validate a license key requires an active internet connection. This is for online/web-based apps, with an emphasis on JavaScript apps built on Node, Electron, etc. Licenses are validated by making an authenticated GET request to something like https://evilcorp.keygen.sh/v1/licenses/3qMEarbK/actions/vali.... Keygen isn't meant to be used for offline apps, as license validation requires an authenticated API request.
Yes. What prevents cracking is the fact that license keys can only be created if you are either an authenticated user of the account or authenticated with a product API token. In order to create a license crack, you would have to obtain a valid API key for that specific account. Everything with the API is done over the wire, meaning there are no public/private keys within your app to crack.
I don't think you actually understand cracking if you're claiming your protection is uncrackable. You're certainly not the first licensing company to sell that lie, if that is what you're claiming. I can explain why what you just said is easily crackable if you'd like.
But I'll just give you the benefit of the doubt and say you didn't actually understand the question.
(Also, I'm certain I'll be downvoted for commenting on a competitor's product, but licensing companies that lie to customers is a particular pet peeve of mine).
I didn't mean to claim that the product is uncrackable; I only meant that the API is secure and produces cryptographically sound tokens and license keys. Keygen does nothing to circumvent users from modifying a product's source code. It is only an API, and not a way to obfuscate an app; that's up to the discretion of the company/person developing the app.
There will always be ways to bypass licensing, especially for apps built on web tech, e.g. web apps, Electron apps, NW.js apps, etc. There are ways around it, sure. But that part isn't what Keygen is for. Keygen uses a combination of serial keys for licensing, as well as hardware-locked licensing by tracking machine fingerprints. It's up to the developer to enforce these, however.
Also, Keygen solves a very different problem that Nalpeiron, Lime LM, Agilis, Cryptlex, etc. do not solve: easy licensing for web-based apps. All of the solutions I've seen are cumbersome, unintuitive and are of course primarily designed for compiled apps. All of that has lead me (and others) to developing licensing systems in-house that behave more or less identically.
What Ubisoft did a few years ago with Settlers VII was to put required pieces of code in the DRM; e.g. without an internet connection, the software would not function at all; it took over a year and a lot of hard work before they found a way to write their own server to serve up the required bits, and it was just for that game, not a general solution.
True :) It was also very badly programmed, making your PC die in agony when you'd play it, even if you had the highest end stuff on the market. Still a very fun game though.
a previous company I worked for spent many pound coins on using metafortress to make our softeare exceptionally difficult to crack.
It went from 5 minutes in a hex editor to being a rather involved job. So it stopped it for a while.
Then people realised that instead of cracking licensed program, it was much more simple to crack the license server. (this also made detection much harder.) It also had the advantage of allowing rafts of other software not made by us work as well.
Hey! We've used limelm in our (now defunt product). Everything was a pleasure to use, both the client libs and the web frontend! That said, we obviously had to camouflage calls to the client lib and apply a few other tricks to make mocking out the calls harder. Great product!
Based on reading his posts here (site doesn't work), his product seems to be something you'd run on the server rather than on the customers side. Sounds like it does licensing for web applications, not for software that you download to your computer.
Your explanations are very nice. I have just one thing I am wondering. What if a customer is using something like VMWare to activate the product and then distribute in the company a VMWare image. Can your hardware based licensing scheme work?
Would it integrate with my REST API? I'm already using JWT's in authentication headers... what, if any, changes to my existing login would be required?
Yes, you can integrate Keygen using your own user authentication system. You would do so by associating user-less licenses with your app's user models. Instead of using Keygen to manage your users, you would only use it to manage licenses.
I'm always really worried about this stuff. I have Mixpanel events that get disabled if the Do Not Track flag is sent. I'm always worried a browser will stomp on parts of the site just because tracking code is there, even when the user does not have DNT enabled.
The fact that MailChimp got on to Firefox's privacy block list is not too surprising to me. I deal with many daily spam emails that all originate from MailChimp. No amount of checking off on their unsubscribe form that the senders are using MailChimp as a spam service actually gets some sort of invention to occur. Personally I am glad that they are being flagged since they do not do much to stop spammers.
Hey everyone! I'm the creator of Keygen and would love to answer any questions that you may have about it. I've been developing the API for over 6 months and figured I'd try and gather feedback on the product through a beta before the big launch day. I'd appreciate any feedback at all!
"Traditional" license management servers (like FlexLM) are a scary piece of software for sysadmins: think of it like a black box that will shut down everything if you mess up.
This license-as-a-service makes operations very easy.
I wonder if you have in mind something about concurrent users. I mean, some software is licensed on a _concurrent_ user basis, not just per seat.
If a user logs-in twice, usually the LM revokes the license for the session that was active, and assigns a new one to the user that just logged-in.
Also, license reporting is also a good idea for answering questions like... how much do I have to pay for next year maintainance?
Hey, I realized that I guess I had misread your post, so my previous reply doesn't answer your question. Support for detecting/revoking concurrent users is a great idea and I will be sure to come back to that in the future. As of now, that will have to be done outside of Keygen.
Thanks for the kind works. I'm still working out pricing, and the beta will help iron out any kinks and see how I can best calculate usage. I may end up starting out with fixed-price plans that are based on product, user, and license count. I'll keep the rest in mind, thanks!
Hey, thanks! I'm glad the design is such a hit. I will have a contingency plan in place that will likely involve open sourcing the API so that it can be self-hosted.
How about, at the very point one sets up their app to use your service, they provide a secondary api endpoint of their choice (licserver.customerdomain.com). That way if your server goes belly up, it falls back to their domain for license management without the user have to update their software because the vendor needs to point to a new service.
Nothing planned. Keygen is made for online-based products. You can either validate when an active internet connection is available, disable offline access (which should be avoided) or simply let it be. In the end, it's up to the product developer.
Haven't tried it unfortunately - back in 2005 when we looked at licensing, we came to the conclusion that we might as well do it ourselves. But having a proper open source solution would be better, easier to audit and better collaboration.
I am currently writing documentation and the product needs an admin dashboard so that things can be managed outside of the API, a la Stripe. After that I will run a beta to gather feedback before launching. I'd love to chat if you'd like to reach out to me at hello@keygen.sh to gauge what your needs are in terms of an on-prem license.
Depending on how the company crashes and burns, couldn't that be prevented from getting enacted? For example, I can't imagine that investors would be too happy that the company's "biggest" asset would be given away in that situation. Same goes for (possibly) filing for bankruptcy. Wouldn't creditors have a say?
I wonder how you can avoid users from tampering with the licence check in dynamic languages like javascript and ruby where anyone has access to the node_modules or rubygems directories.
I know this is not the focus of this particular product but since it has come up in multiple comments. How could this be solved?
It is also worth noting - how much do those cases really matter anyway? If they're going to the bother of disabling your licence checks, they probably aren't going to buy it anyway.
It's a fear that many have. When dealing with JavaScript based apps, where all of the source code is readable (more or less), there's really no way around the possibility of that happening. All you can do is require that updates and support require a license key. In the end, that will be a small amount of your users. Every software company deals with this issue a little differently.
Is this validation actually performant or secure? It seems like if you implement this on the client side, you end up using JavaScript and the client can just run code that patches the call to the server to have it always pass. Then if you implement this on the server side, then you pay a latency penalty for every request, as you have to verify the token sent to your server against the keygen.sh server.
It seems like this is either insecure or you pay an RTT latency penalty on every authenticated request. Is this correct? Is there something I'm missing here?
That's assuming that you require license validation with every request though, when in reality you really only need that information periodically. If you're using Keygen alongside your own API, then that information can be cached and requested when needed.
It would be integrated the same way you would integrate something like Stripe; you request information when required, and keep your own records up to date via webhook events.
For example, a desktop app would really only need to validate a users license after they have successfully logged in after booting the app; you likely wouldn't need to validate the license again for at least 24 hours, and that's assuming you wanted to perform periodic license validations for long-running sessions.
This is a good point. I guess it depends on the characteristics of your application, and the level of control you want over verifying user activity within your application. Maybe you could only verify very important actions or something if that is all you need.
> It seems like if you implement this on the client side, you end up using JavaScript and the client can just run code that patches the call to the server to have it always pass.
Not sure there's anything practical you can do about that. You're not going to be able to stop hackers figuring out a bypass. Your goal should be to make the license check bypass inconvenient enough that regular users would rather pay for a license (e.g. requires a new bypass each version upgrade).
Definitely. I've seen implementations that require a login before the app is able to be used, but also others that simply have a flash message that kindly asks the user to login. If your app performs auto-updates, then you can also require a valid license before updating, which would be handled server-side somewhere.
I'm absolutely thrilled by the response so far! I didn't expect to get such a large amount of interest so fast. I already have hundreds of users interested in the early access program. I'm going to be hard at work the next couple weeks writing documentation and developing the rest of the web app (API is ready) so that we can get this ball rolling!
I've been thinking about licensing recently, in the context of package managers.
How can you allow people to install and update commercial packages, without the problem that anyone can use any key?
I'm thinking particularly in terms of software which is licensed to run on 1 domain, 3 domains, 5 domains etc - but as soon as you use a CLI package installer, you don't know the domain being used.
I'll be handling it the same way Stripe handles their libraries: https://github.com/stripe/stripe-node#api-overview. Account tokens are cryptographically sound enough so that it would take ages to 'find' a correct token, much less the correct token AND account. Restricting licenses by domain would need to be handled outside of Keygen; you can track the allowed machines (via fingerprinting) through the Keygen API, and then act accordingly.
Yes, this is for online/web-based apps, with an emphasis on JavaScript apps built on Node, Electron, etc. Licenses are validated by making an authenticated GET request to something like `https://evilcorp.keygen.sh/v1/licenses/3qMEarbK/actions/vali.... Depending on how you manage users, you can require them to login (request an API token) before being able to access your app. Depending on if you're performing the validation server-side or client-side, you can either use a product-specific API key (private) or the license owners API token (a signed in user), respectively.
I assume a combination of public/private keypairs and timestamping.
If you trust the client to say "yes, validate via the keygen.sh API", then without loss of generality you can probably trust it to validate using a public key and a timestamp.
You only need a key management service like this when you go from SaaS to on-prem/equivalent, at which point PHP is in the unenviable position of having readable source files.
It's possible to patch out license checks from any language, but PHP makes it pretty easy - what's your approach to solving this? Ioncube-style binary extensions? If so, PHP7/opcache compatibility?
To validate a license key requires an active internet connection. There is no compilation or obfuscation because your app never contains any license keys directly. All of the logic is handled via the API. Validating a license would require performing a GET request to a users license validation endpoint.
I mean, sure, I licence one of my own products with a RSAPSS signature on an environmental constraint .. but if somebody went to the effort they could just flip a single instruction to bypass it. However, I am pretty sure nobody in my target market will bother.
However, I don't think that would hold with something like this. What stops people releasing a bunch of generic bypass/crack tools against your client SDKs?