Software licensing offers software developers a means of ensuring their product is not installed without prior authorization (generally by purchasing the product). Some competing products offer licensing modules to facilitate the deployment of such software, but their designs are critically flawed in a number of ways. Today I’ll describe the software licensing scheme we use in Blesta 3.0, and why it works. But first, let’s take a look at the problem.
To ensure an installation is allowed to run it needs to established its authenticity. This is generally done by “calling home.” That is, by contacting the licensing server. Information returned from the licensing server varies, but generally contains data about how, when, and where the software can run.
The naive approach
It goes without saying that if the license data can be tampered with one can easily bypass the license check. To resolve this, others have devised a scheme whereby the data is hashed using a shared secret salt know by the licensing server and by the product. When the product receives the license data it creates a hash from the data using the shared secret salt and compares that hash with the one that accompanied the data. If the two hashes match the data is trusted, otherwise the data is rejected.
Some systems don’t even bother sending the original hash of the data and instead compute and store the hash upon arrival for future reference. These systems are even less secure.
There are a number of exploits with these systems:
Some may argue the dangers of revealing how insecure systems can be compromised, just as a magician might jeer at the sight of someone exposing their trickery. Those that argue from that position fail to realize that security does not arise out of obfuscation. Shannon’s maxim teaches that one must always assume that an attacker understands exactly how a system operates.
A digital signature allows us to verify the authenticity of a message through the use of an asymmetric key cipher, which uses one key (the private key) to encrypt data and an entirely different key (the public key) to decrypt data. Meaning that an attacker can not reproduce signature data since they do not have the private key.
How it works
In the event that the signature can not be verified the license data is rejected and the license becomes invalid. Attempting to spoof the license server does nothing because only the license server can sign messages and the installation will only be able to verify signatures from the license server.
Additionally, at any time the license server may choose to generate a new key pair. This is especially useful because as attacks on asymmetric key ciphers becomes computationally cheaper it becomes increasingly important to cycle keys and/or increase key lengths.
Why are we telling you all this?
It would be great if there were no need for software license validation, but there is and there’s a market for it. Our philosophy is if you’re going to do something you ought to do it right. At the moment, thousands of developers put their software in the hands of licensing systems that provide illusory protection at best, and that’s unfortunate.
So, why are we telling you all this? Because we’re building a licensing plugin for v3 that does it right. We don’t mind sharing with everyone how it works because even licensing systems should be transparent. And, if our competitors decide to rework their licensing systems and do things right — then everyone is better off. And that’s what it’s all about.
Tags: blesta 3 | encryption | licensing | plugin | plugins | v3
So, let’s keep it real. I didn’t have the time to make a video this week. I’ve been doing a lot of graphic design work on Blesta, some awesome stuff you’ll get to see soon. But that doesn’t mean I can’t share something, right?
Plugins. Are. Amazing. Plugins can do a lot, we’ve talked about them before in passing while describing other features. Plugins can register widgets on the Dashboard, on the Billing Overview, on the Client Profile. Plugins can create entirely new pages, with new functionality, with their own nav links. Plugins can register themselves into the ACL. Plugins can create their own email templates. Plugins are mini-applications. Plugins are POWERFUL.
I know people are going to shock us with what they develop for Blesta using the plugin system. I can’t wait to be blown away.
This post is the tip of the tip of the iceburg, we will have a lot more to say about plugins as we get closer to release.
Oh yeah, plugins can be installed, and uninstalled, upgraded and managed. Here’s what the installed plugins window looks like. These are all plugins that will come pre-installed with Blesta (there will be more too, don’t worry). These ones create widgets on the Dashboard.. and since we wrote them, they got slapped with the Blesta logo. Slap your logo on your own plugin!
Maybe a video next week? We’ll see!
Tags: blesta 3.0 | plugin | plugins | version 3
ach ACL api authentication behind the scenes blesta blesta 3 blesta 3.0 blesta v3 cli client area design developer commentary documentation encryption gateways importing invoices licensing minphp payments plugins security sql injection staff support TOTP translator v3 version 3
WP Cumulus Flash tag cloud by Roy Tanck and Luke Morton requires Flash Player 9 or better.
Blesta is a product of Phillips Data, Inc. / Email:
© 2009 Phillips Data, Inc.