3 ms·
> 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 decad
by 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 agoAnd 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 agoAppreciate 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.