We’re excited to announce the release of Blesta 3.1. Thanks to everyone who participated in the beta!

Download 3.1 Now

Then, check out the docs to install or upgrade.

This release is packed with many new features, but perhaps the most prominent is configurable options. For a quick overview of configurable options, please watch the following short video:

What else is new in 3.1?

Modules

• Proxmox
• VPS.NET
• Enom
• GoGetSSL
• TheSSLStore

Gateways

• BitPay
• CCAvenue
• Payza

Plugins

• Shared Login

Core features include configurable options, package sorting, support staff signatures, cancel end of term package option, and many more. Please see the changelog for a full list.

So what’s next?

Development on 3.2 is in full swing. Rumor has it, a responsive bootstrap client interface is on the way.. among other things.

Financial advisory firm, Deloitte, recently published an article detailing the ever expanding need for two-factor authentication. They predict that, “a number of technology and telecommunication companies will likely implement some form of multifactor authentication with their services, software and/or devices in 2013.” I see this less as a prediction and more of an advanced report of the facts, since we had the same notion back in 2010 when we announced two-factor authentication for Blesta.

Deloitte’s predictions go even further, stating that passwords that were previously considered secure (8-characters of mixed case, numbers, letters, and symbols) are now vulnerable to hackers, primarily due to password reuse and the use of graphics cards (GPUs) to perform dictionary attacks. Personally, I’ve never found those types of passwords to be very secure. After all, we know that password security is derived from entropy (randomness) and entropy increases with length. So rather than trying to remember 8 to 10 character passwords with letters, numbers, and symbols that have no meaning, why not simply use a long natural password? Bonus points if your language of choice is not typical of the application’s audience. Extra bonus points if it’s a dead/non-existent language. Anata no o pasuwado wa nan desu ka?

Comic by xkcd / CC BY 2.5

Of course, what’s more secure than a secure password? How about a password that changes every time you use it? “How could I possibly keep track of that,” you might ask? That’s where two-factor authentication takes over.

Time-Based One-Time Passwords (TOTP) are generated using an algorithm that produces a pseudo-random value based on any given moment in time (remember, randomness = good). The benefit of using two-factor authentication is that you need not put all your trust into the security of your password. Random token generators (or apps for your smart phone) can produce a one-time password that’s used in combination with your standard password, and as the name suggests are used only once. That means that even an attacker that knows your password and knows the token you just used to login to your account still can’t use the information to login as you.

This one is from BlestaLabs.. that dark little corner of the office where we do R&D.

Watch the video first, and then scroll down for some details.

The video is below, as usual you can make the video full screen, and be sure to turn on your sound! (If you like music, no narration this time)

Let’s face it, we’re nerds, and we like to push the limits. We spend a lot of time making things run properly, you know, in the back-end. Nice and efficient like. So, what a better way to test Blesta v3 than on a credit card sized computer, right? So, we ordered some Raspberry Pi’s and waited 6 months for them to arrive.

I took one of them, and installed Debian Wheezy, Apache 2, PHP 5.4, and MySQL server 5.5 and slapped an alpha copy of Blesta v3 on it.

The Raspberry people were nice enough to ship ones with 512MB of RAM (upgraded from previous 256MB versions) but it’s obvious that the bottle neck with running a web server on a Pi is the ARM processor. As recommended, I installed php-apc, and that improved things noticeably along with some other tweaks. To improve things further I might try lighttpd, or another light weight web server, but overall performance is pretty good!

And there you have it, the next-gen Blesta on a Raspberry Pi. Hey, if it’ll run on a Pi with a tiny processor and an SD card for a hard drive, it’ll run on your web server.

Don’t fall for the lie, PI is better than cake anyway.. and it’s real! Some of you gamer nerds know what I’m talking about.

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:

1. Because the same shared secret is used to generate the hash across all installations it may be possible to obtain the shared secret
2. Because the hashing method generally used is insecure it may be possible to tamper with the data and still produce the same hash (i.e. a hash collision)
3. Because the data passed across the line is unencrypted or poorly encrypted it may be intercepted and the licensing server may be tricked into returning data regarding a separate valid license, or the licensing server may itself be spoofed

Exploiting it

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.

1. Determine where the software calls home to. This can be done by monitoring network traffic or guessing the license server domain.
2. Spoof the licensing server by modifying the server’s DNS or hosts file to resolve to a “license server” you create.
3. Capture the data sent to the licensing server to a log file.
4. Capture the data returned from the licensing server. This can be done by manually passing the data from #3 to the licensing server. Note that if you do not have information to obtain a valid response from the license server, you may be able to obtain that information from another user with a valid license or from a public demo of the application.
5. Return the license data you capture from the license server, or modify it to ensure it continues to function ad infinitum.

The solution

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

1. The license server generates a unique public/private key pair for the installation and delivers the public key securely to the installation
2. The license server then encrypts the license data, generates a hash of the data and encrypts it using the private key to produce the signature
3. The license server then delivers the data and signature to the installation
4. The installation verifies the signature by decrypting the signature with the public key and comparing it with the hash it generates from the data

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.