3 ms·

The entire premise presented here becomes moot if the software connects to the internet for key verification which has been a viable option for decades now as O

The entire premise presented here becomes moot if the software connects to the internet for key verification which has been a viable option for decades now as OP well knows because their entire business is being that server (and the service looks very tempting tbh). A system that requires keys to not only be algorithmically valid but also pre-registered at time of purchase with a central authority (buy online and we'll email you your key) makes key generators implausible, because you don't just need to generate something that matches the algorithm, you need to hit an exact target from a set of keys that happen to currently exist in a presumably secured central database of customer keys. At that point the kind of key you use is completely irrelevant, because algorithmic generation of valid keys is meaningless when faced with pinpointing which of umpty gazillion key possibilities actually exist in a remote database before the server cuts off your access for spamming invalid keys or for providing a key that 10000 other people have also provided. You could concatenate a few calls to rand() for all it matters then. Also, this comparison is flawed: > "It's also worth mentioning that keygens are much more valuable to bad actors than cracks, because a keygen can be used on the real application, vs the bad actor having to distribute a modified, cracked version of the application." You don't have to distribute the cracked application. You can distribute the binary patching tool which also can be used on the real application. (What does "real" mean here anyway?) A keygen is only more valuable if applying the binary patch is harder than discovering the key algorithm across version updates. I guess this is where OS application certificates have to step in. Hurray for our code-signing gatekeeper overlords.

ezekg 5y ago
> Anyway, the entire premise presented here becomes bogus if the software connects to the internet for key verification which has been a viable option for decades now. This would seem true to most people, and I had the same assumption over 5 years ago when I started Keygen. But you would surprised at how many software vendors, and end-users, do not consider an online-only licensing system a viable option. Take Sublime Text -- as far as I know, they do not use a licensing server that "calls home" (I'd bet their user base revolt against such a thing.) There is a sizeable portion of my customer base that rarely even uses the API -- they use Keygen to generate signed offline-first license keys which they distribute to end-users. They only use the API for customer support and reporting purposes. I like having the best of both worlds -- an online-first, offline-capable licensing system. But to be offline-capable, your key algorithm has to be secure, otherwise bad actors will just go offline to avoid the part of your system that works.
- BugsJustFindMe 5y ago
  And I think your service looks very good, but the barrier that fancy keys provides vs unfancy keys is against the subset of pirates in an adamantly-offline-only community who don't want to modify their executables. It's not an entirely trivial difference, but it's also not really mentioned in the blog post.
  - ezekg 5y ago
    Appreciate the kind words. The blog post is on generating cryptographically secure license keys (focused on offline-only), so discussing anything else would have been off-topic. Perhaps I'll cover it in another post. But regardless, the API supports generating more typical, or unfancy, license key formats, e.g. XXXX-XXXX-XXXX-XXXX, but those are online-only.

ezekg 5y ago

> Anyway, the entire premise presented here becomes bogus if the software connects to the internet for key verification which has been a viable option for decades now. This would seem true to most people, and I had the same assumption over 5 years ago when I started Keygen. But you would surprised at how many software vendors, and end-users, do not consider an online-only licensing system a viable option. Take Sublime Text -- as far as I know, they do not use a licensing server that "calls home" (I'd bet their user base revolt against such a thing.) There is a sizeable portion of my customer base that rarely even uses the API -- they use Keygen to generate signed offline-first license keys which they distribute to end-users. They only use the API for customer support and reporting purposes. I like having the best of both worlds -- an online-first, offline-capable licensing system. But to be offline-capable, your key algorithm has to be secure, otherwise bad actors will just go offline to avoid the part of your system that works.

BugsJustFindMe 5y ago
And I think your service looks very good, but the barrier that fancy keys provides vs unfancy keys is against the subset of pirates in an adamantly-offline-only community who don't want to modify their executables. It's not an entirely trivial difference, but it's also not really mentioned in the blog post.
- ezekg 5y ago
  Appreciate the kind words. The blog post is on generating cryptographically secure license keys (focused on offline-only), so discussing anything else would have been off-topic. Perhaps I'll cover it in another post. But regardless, the API supports generating more typical, or unfancy, license key formats, e.g. XXXX-XXXX-XXXX-XXXX, but those are online-only.