Show HN: Keygen – A dead-simple product licensing API built for developers | Hacker News Reader

Show HN: Keygen – A dead-simple product licensing API built for developers

keygen.sh

132 pointsezekg88 comments

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?

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.

Did you reply to the right person? Your reply does not seem to address anything that was said.

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.

Spoiler alert: nothing can stop cracking (but that's not the point of licensing): https://wyday.com/limelm/features/why/

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).

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.

Then again, the servers were so poor that, for a long time, the game basically wouldn't function with a connection either.

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.

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.

Doesn't sound very useful.

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.

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?

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.

He means that if it's easy to patch the if(licence_valid) then the rest doesn't really matter.

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.

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.

But the point is that with a centralized protection scheme, cracking will potentially become very simple for the end-user.

It's already very simple for the end user. Google, $prouctname $version crack, download.

Doesn't work for niche products though.

It does for some.

Yes, perhaps if they use a standard protection scheme :)

And thus, botnets were borne.

You can still crack Adobe products with a simple /etc/hosts entry. There will always be ways to circumvent licensing.

Firefox’s tracking protection is preventing the “Get Early Access” button from working, just putting this warning into the console:

> The resource at “https://mc.us14.list-manage.com/subscribe/form-settings?u=0d... was blocked because tracking protection is enabled.[Learn More]

You can't have DRM without tracking :)

Hey, thanks. I'll check out what the deal is. There have been a few other issues in Firefox.

Do people not test their sites in Firefox anymore?

I did extensive testing in FF. This seems to be an issue related to privacy settings: https://github.com/rydama/mailchimp-ajax-signup/issues/6. I will look into additional ways to allow sign ups that don't have this issue.

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.

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.

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!

I love the glitch aesthetic and hope to see it become a trend.

I love the design of the site; looks great!

Thanks! Years ago I was a graphic designer, so I like to do a little design every now and then. Being able to code lets the creativity really flow!

First of all, this looks a good idea to me.

"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?

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, 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.

Really nice idea, congrats on launching!

The website design is REALLY refreshing and feels professional.

Question: I guess this is software as a service, what happens if the service would shut down - for whatever reason?

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.

Good idea. I'll create an issue for that to come back to in the future.

What if customer computers are not connected to the internet? Is there a way for off-line licensing?

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.

Does anyboday have any recommendation for a self hosted licencing system?

I would also like to get some recommendations for self hosted systems. Anyone?

I am also interested in a self-hosted licensing server (for Linux).

There is this:

http://dev.nauck-it.de/projects/license-manager

I found Portable.Licensing by Nauck too, but have you any experience with it?

I'm just kinda confused that there are not more self hosted libraries for this.

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.

Hey, I'm going to offer on-prem licenses for the API for companies that would rather host in-house. Would you be interested in that?

Yes, I would. Any timeframe on this?

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.

What happens if the company that hosts a licensing server goes out of business?

I will have a contingency plan in place that will likely involve open sourcing the API so that it can be self-hosted.

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?

Do any services exist that fill the niche of "I have built an API, and I now want to charge for it"? API tokens, billing, metrics, etc

Actually Amazon offers this as part of its API Gateway service.

I know Azure has API Management https://azure.microsoft.com/en-us/services/api-management/

It doesn't look like it has the built in monetization, but it should be fairly easy to smash a payment provider and API management together.

3scale, Apigee, there are many of these services

Mashape?

Somebody should get on that. Metered billing definitely hasn't been easy to build using Stripe.

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?

Make it a super pain to mess with. Lace the code with license checks (different ones, not the same repeated) and run an obfuscator.

Works best with an external license server. If you have to be offline make the checks more involved.

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?

> 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.

In the end, it all depends on the product.

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.

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.

If the API is publicly documented, how will you stop people from just spoofing the licensing server?

I assume you've addressed this issue, but I'd love to know how.

Edit: From reading a bit more, I understand that this service is mainly aimed at web/online apps, so piracy is a non-issue.

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.

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.

Just a quick note yet: not sure "evilcorp" is the best of names for an example, though.

EDIT: Definitely enjoying the slightly creepy visual haxor effects, though.

I think it's a reference to Mr. Robot

Ah, okay thanks. Checking it out

Without wanting to give away the plot to Mr Robot, Evilcorp is still a pretty bad choice given what they do regarding security, or lack of such.

It's a ref to Mr. Robot. So far it's been quite a hit. WIll look into alternatives though. :)

How do libraries for PHP work?

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?

How is your question any different for Perl, Python, Ruby, or Node.js?

It's different for Go.

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.

OK. Just to clarify, there's no protection against a malicious user with the ability to remove these API calls from their copy of the app?

Correct. There's really no way around that being a possibility, especially if you're using web technologies.

Reply on news.ycombinator.com