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.

It’s been a while since I posted a video, I missed you. So, today — a new video, about the Staff Calendar. Staff Calendars feature the following:

1. Mini dashboard calendar with badges that indicate the number of events for each day.
2. Full size monthly, weekly, and daily calendar.
3. Shared events, staff members can share events with everyone on their team, or keep them private.
4. Multi-day, whole day, and time based events are supported.
5. Intuitive drag-n-drop interface to create and edit events.

We hope you like the calendar, I know our team will be using it! Developer tidbit: Yes, you’ll be able to add events to the calendar from your custom plugin. I know people are going to ask so I’ll tell you.. recurring events are planned for a future release.

The video is below, as usual you can make the video full screen, and be sure to turn on your sound.

A lot of effort has gone into designing and interfacing with the database in version 3, so I thought I’d share a little insight into some of the improvements we’ve made over version 2.

We’ve beefed up the database by making use of transactions, which allow us to add, edit, or remove items from the database with the ability to undo those changes should something go wrong. Because of this we’ve made the switch from a MyISAM storage engine to InnoDB (the default for MySQL as of version 5.5), making Blesta ACID-ic.

Another major improvement is the use of UTF8 collation, which will now allow users to more easily search the database in their native tongue as well as input and output data without conversion. This is a huge improvement for developers, and we are all about developers with version 3.

Speaking of developers, another great improvement is the introduction of the Record component. The record component is a database access object that creates queries using a series of method calls. Never again will you have to worry about which comes first, GROUP BY or ORDER BY.

In addition, the Record component uses the PDO library, making queries safe and secure. But that’s not the only benefit of PDO. Can we say “multi-database support”, as in MSSQL, PostgreSQL, and others? Well, no, not at the moment, but that’s definitely a possibility.

From the Developer Documentation:

One thing we haven’t really talked about much is the client area. We have a good excuse: The vast majority of functionality is built into the staff/admin interface. But, the client experience is important too, arguably much more-so. In v2.x the client interface is identical in overall design to the admin interface with a slight color change.

In v3 we went a different direction. While there are similarities between the client interface and the admin interface they are completely different designs and you log into them independently.

Important notes to make about the client area in v3..

1. The client interface has a new, clean & unique design.
2. The client interface can be easily themed & integrated into an existing site.
3. The client interface now consists of a Portal, Account Management, and Order System.
4. The client interface is more intuitive and user friendly, and takes advantage of a lot of new features introduced in v3.
5. Developers will be happy, Plugins can affect the client areas too.
6. Mystery feature — yes I just did that, more details in a future post.

Portal, Account Management, and Order System. All tied together, all themed the same, all easily integrated into an existing site design.

I can’t not leak some eye candy in a post, so above is a cropped segment of the default order template. I hope you agree, it’s a nice and clean design, yet fairly neutral in terms of color. Though the header is not shown here, it does have color and the color is easily changed.

There’s a lot more I could show you, but we’ll cover more in a future post. And to all a good weekend!

We’ve shown you a fair amount of the staff interface, but I want to show you the staff login page today. Overall this video touches on three things..

1. Staff Login Page: This is a first, no one outside our team has seen this login page before now.
2. Two-Factor Authentication: This was originally developed for v3, then back-ported to 2.5.
3. Resource Preservation: Session expire? Blesta remembers where you were headed.

The staff login page has previously never been shown, although I designed it before much of the interface. Two-Factor Authentication was originally developed early on for v3, and then back-ported to 2.5. As far as we know, no one else supports two-factor authentication, making Blesta uniquely secure. We don’t blame them though, it took plenty of R&D and most solutions are proprietary. Resource preservation is just a fancy term we coined to say that Blesta remembers where you were going, and takes you back there if your session expires and you get logged out and login again.

The video is below, as usual you can make the video full screen, and be sure to turn on your sound.

Note: Cody tells me, and I realized after that OATH is pronounced “oath”, not “oh-auth”, which is something completely different.