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?
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.
Tags: authentication | blesta 3 | password | security | TOTP | two-factor | v3 | version 3
When we originally introduced two factor authentication there weren’t a whole lot of options available to produce one-time-passwords. Since that time a number of applications have popped up for Andriod, Blackberry, and iOS devices. Chief among those is the Google Authenticator.
Using your Google Authenticator with Blesta is pretty straight forward, but requires a little manipulation to get the key in the correct format. Blesta expects TOTP keys to be in hexadecimal format (base16), but Google Authenticator uses base32. So we have to convert our Google Authenticator keys into hexadecimal before storing in Blesta.
There are a number of online utilities to perform this operation. Here’s one: http://www.darkfader.net/toolbox/convert/.
As an example, “PEHMPSDNLXIOG65U” (in base32) becomes “790ec7c86d5dd0e37bb4″ in hexadecimal. Simply select Time-based One Time Password as the two factor authentication method in Blesta then enter the converted (hexdecimal) value and you’re good to go.
You can download the Google Authenticator from the iOS app store, or Android Marketplace.
Tags: authentication | google | security | TOTP | two factor authentication
Back in May our largest competitor WHMCS was compromised, and I wrote a blog post titled “Thoughts on Security“. After my post, the hackers released a data dump and the personal information of their customers became public. Names, email addresses, credit card numbers and more. A nightmare scenario for any company, and worse for their customers.
I got a lot of email, and a few phone calls after that post. People are now, more than ever, concerned about security and they should be. It’s something that cannot be taken for granted, and can no longer be ignored. It requires diligence. There is no such thing as security through obscurity.
Most recently LinkedIn, Dropbox, and Blizzard were all compromised. These are big companies with big budgets and they are big targets, but it highlights the fact that nobody is immune.
Today’s post is sort of a follow up on that last post. I wanted to be more specific in terms of security measures we’ve taken within our software — specifically our next major release, version 3. It’s because we believe security doesn’t come from obscurity that we are so open about the steps we take to protect not just our customer data, but in as far as possible, our customers’ customers.
We don’t claim to know everything there is to know about security, but it’s an area we spend a considerable amount of time in discussion, research, and development. It takes priority over new features in our development cycle.
Passwords in v3 are stored using bcrypt, computed from an HMAC-SHA-256 hash of the user password, if supported by the server. The advantage to using bcrypt is that it slows down the time it takes to compute the value. How could slowing it down possibly be good you might ask? Because, if an attacker happens to acquire your users’ hashed passwords, and also the key used to generate the HMAC-SHA-256 hashes, it would be impractical and time consuming to brute force them from a list of common passwords (known as a dictionary attack). Without the HMAC key, it becomes computationally infeasible to brute force (with 2^256 possible combinations of hashed passwords, and a 1/4 second to compute 1 bcrypt password, you would only be able to attempt 126,144,000 bcrypt passwords per year. So, statistically, it would take 4.5897 x10^68 years to crack a single user’s password).
Now, assuming the HMAC key is known, a 60,000 password dictionary file would take statistically 2.083 hours to crack 1 users password assuming the password is in the dictionary to begin with. This is fantastic because it gives you much needed time to reset every users password and notify them, making the leaked hashes virtually useless.
Additionally, a bcrypt password is never the same. If user A and user B both have a password of “hunter2″, the stored values will not be identical.
Blesta supports two-factor authentication (in v2.5 and v3) for both TOTP (Time based One Time Password) and MOTP (Mobile One Time Password) for staff users. Both methods use a token, like OATH Token for the iPhone. Staff members log-in by entering their username and password, and are then prompted for their one time password. Once this token is entered, it can never be used again, so a man in the middle attack is not feasible.
I did a video on Staff Login a while back that shows two-factor authentication in action, if you haven’t seen it.
Shipping with v3 is a plugin called PHPIDS, which is an intrusion detection system. The plugin is excellent at detecting, logging, and blocking various attacks and uses the PHPIDS library.
From the PHPIDS website:
Furthermore the PHPIDS is able to detect yet unknown attack patterns with the PHPIDS Centrifuge component. This component does in depth string analysis and measurement and detects about 85% to 90% of all tested vectors given a minimum length of 25 characters.
The video is below, as usual you can make the video full screen, and be sure to turn on your sound.
ACL (Access Control List)
v3 introduces a fully featured ACL. Access to different areas and tasks is limited to the group a staff member is part of. For example, a support staff member may only need to have access to support features, and be kept far away from private customer details. You have fine-grained control over what they can and can’t access.
I did a video on this one too, appropriately named Full Featured ACL. It’s worth a watch, if you haven’t seen it.
v3 logs a lot of things, including credit card accesses. Anytime a staff member views a credit card number it’s logged. If card numbers are siphoned off, you’ll be able to tell exactly who took them.
Offsite Gateways and Batch Processing
In v3 we are introducing offsite storage of card details for gateways that support it, like Authorize.net’s CIM method. For those using local storage of card numbers they are still encrypted. Now with up to 3072-bit RSA cipher (depending on your system), and you can optionally set a passphrase on them. A passphrase is similar to a password, and is not stored on the server anywhere. Credit card numbers can be encrypted without the passphrase, but the passphrase would be required to decrypt them. When enabled, all payments made from stored card numbers must be batched manually with the passphrase. It’s an added layer of security that can be enabled or disabled anytime. (Just don’t forget the passphrase if you set one!)
minPHP and PDO
The open source PHP framework we wrote, minPHP, provides foundation level security for Blesta v3. minPHP supports, and v3 uses PDO which helps make queries safe and secure through parameter binding. Cody wrote more on this in his article title Eliminating SQL Injection.
Smarty’s not that Smart
Blesta has never used the Smarty template system, and v3 is no different. We rarely trust 3rd party libraries, especially bloated ones with very little benefit. The template system in minPHP is light weight and secure and it has many similarities to the template system we used in previous versions. We feel justified in our approach to keeping things simple and light weight, especially in light of recent security exploits with Smarty that affected at least two of our competitors.
Our strict requirements in terms of integration of 3rd party libraries, and our aversion to bloated code put Blesta on a higher playing field.
I’m not good at marketing, I’m really not. I tend to think of good marketers as a little dishonest and don’t always hold them in the highest esteem. Their job is to portray their product in the best possible light and at times make it seem better than the competition. I think the product should speak for itself and I am passionate about what we’re doing because I know we are building something great.
Part of what sets us apart from our competition is our desire to do things right, along with our expertise to follow through on that desire. No shortcuts. No compromise. After all, that’s what I would want in a billing system for myself, because, if the focus is right, everything else will fall into place. If not, it’s an exhausting game of cat and mouse and I have no interest in that.
Tags: ACL | bcrypt | intrusion detection | PDO | phpids | security | sql injection | two factor authentication | v3 | version 3
Today our largest competitor was compromised. Their website was deleted, service interrupted, and their database was downloaded by the attackers. Many of their customers are left wondering whether their credit card numbers have been acquired, with some already contacting their banks.
We’re sad to hear about the compromise and wouldn’t wish this on anyone, even a competitor. We hope that they will quickly recover from this incident, that their customers’ personal information won’t be released publicly or used maliciously, and that the necessary precautions will be taken to lessen the likelihood of a similar re-occurance.
And while nothing is ever 100% secure, I wanted to reassure our customers that we take security seriously. We’ve never had a breach in either our software or hardware. Here are a few things we do that stand out to me in light of the issues we learned about today.
The server hosting blesta.com is not currently single role, but it has been planned for the past several weeks. In light of the issues with our competitor today, I’m fast tracking the cutover for this. Even so blesta.com’s only interaction with customer data is via a limited access API, not direct database access and it’s on a different physical machine.
We have always taken security seriously, in v2.x, and even more so in v3. It’s a two part issue though — software and hardware.. you’ve got to have a grip on both.
There’s more I could say about the things we do to protect customer data, but I’ll leave that for another post.
Just my thoughts.
Tags: secure | security
SQL injection is a serious concern for developers, and there are a number of ways of dealing with it; however the best, and most proven method, is through parameter binding. What parameter binding does is substitute variable data within a query with parameters, which are then replaced by the database driver during query execution. Since the database driver is intimately aware of which parts of the query are parameters it can parse the query and then execute it with the bound parameters safely set.
The framework that Blesta 3 is built on, minPHP, handles parameter binding through use of the PDO extension. But because writing queries is tedious and prone to typos, minPHP offers a database access object to interface with PDO in the Record class.
A query that would otherwise looks like this…
$this->query("SELECT `users`.`first_name`, `users`.`last_name` FROM `users` WHERE `id`=?", 3);
$this->Record->select(array("users.first_name","users.last_name"))->from("users")->where("id", "=", 3);
No need to worry about syntax, semantics, escaping data, or back-ticks. That’s all handled by the computer, which loves performing tedious operations over and over.
We’ll look at how to overcome cross site scripting (XSS) vulnerabilities next week.
Tags: blesta 3.0 | minphp | security | sql injection
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.