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
Security is a constantly evolving field in computing. Following Moore’s law, computational power essentially doubles every 18 months. Even brute forcing strong encryption algorithms can become, at least theoretically, feasible over the span of a decade.
With Blesta 3.0, we’re looking into the future. — way into the future. We’re designing security measures today that will easily keep data secure beyond 2030. Why? Because even if you never update your software, your data should continue to be secure long into the future.
So how do we do it? By using trusted, non-proprietary ciphers such as AES and RSA, with large keys, we’re able to protect data from brute force attacks. To encryption algorithms, the larger the key the more secure the encrypted data.
Why would you need to encrypt a credit card in such a way that it’s safe from attacks for 20+ years? The answer: You wouldn’t. Credit cards generally expire less than 10 years after issuance. But nevertheless, why take the chance?
Here’s how it works in Blesta 3.0:
Credit cards are encrypted using RSA, a public key cipher. This allows cards to be encrypted using one key (the public key), and only decrypted using a separate private key. This facilitates adding card numbers to the database without requiring admin approval or storing a private key on the system. Depending on your specific security requirements, you can choose to store the private key on your system (encrypted of course), to allow automatic payment processing, or you can choose to set a passphrase that must be entered whenever you wish a card to be decrypted.
Setting a passphrase for your private key is optional, but adds an additional layer of security. A passphrase can be added or removed at any time, without having to decrypt and re-encrypt credit cards. So your passphrase can be changed on a regular basis, which is always a good idea — especially for larger organizations.
Some merchant gateways are now allowing credit card numbers to be stored within their own secure systems. Invoking a charge is as simple as passing in a unique identifier, and the amount to be charged. We’re building support for this into version 3.0 as well..
In addition to credit cards, module data can also be encrypted
Blesta handles security in other areas well too, including XSS (Cross Site Scripting) and SQL Injection attacks and we’ll touch on these in a future article.
Blesta 3.0 is currently in active development.
Tags: AES | blesta 3.0 | encryption | RSA | security
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.