Blesta 3.0: How secure is secure?
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.
Related Tags:
Liquid Web Hero
We thought we’d follow @liquidweb on Twitter so we could stay in the know. Since then, they’ve managed to plant a Liquid Web Hero inside our HQ. Who’s watching who?
It’s all good though, we don’t mind.. we’ve been blinded by his sheer awesomeness, captivated by his strong work ethic, and amazed by his dedication to all that is right and good.
We snapped a few shots lest you make us out to be liars.
Pictured here is the LW Hero (foreground) and Cody, our Lead Developer (background). Such level of awesomeness has arguably never been captured in a single photograph before now.
The LW Hero, warming up to a brainstorming session. This guy is tough, at first he underestimated the mass of the marker, and I had to fetch it out of the ceiling.. from the 2nd floor of the building.
What photo shoot is complete without a little Super Mario Bros 1-up action?
Anyway, a big thanks to Liquid Web! They were kind enough to send us one of their highly sought after Heroes and for that, we are eternally grateful. You can visit Liquid Web at [www.liquidweb.com][2]
Related Tags:
Blesta 3.0: Two-Factor Authentication
Last week I discussed the new API design in Blesta 3.0. This week I wanted to touch on the topic of two-factor authentication.
Two-factor authentication requires that a user wishing to sign into an account enter both something they know (a username and password) and something they have (a physical token). There are many different methods of proving a user is who they say they are, but one of the best and easiest to use is one-time passwords.
Since most users reuse and tend to never update their passwords, if one system is compromised an attacker may have access to all systems the user has access to. To solve this issue, OATH published the HMAC One-Time Password Algorithm (RFC 4226), and the TOTP addendum (a time based OTP algorithm).
TOTP requires that a user enter a 6 or 8 digit code that changes every 30 seconds, and once a code is used it can’t be used again. All a user needs to do is share the secret key on their TOTP device with the server they want to authenticate with and they’re ready to go.
We were so excited to include TOTP, as well as Mobile-OTP, with Blesta 3.0, we had to port it over to 2.5. And here at the office, we can’t imagine how we ever lived without it.
For the iPhone we recommend the following apps:
OATH Token – TOTP token
iOTP – Mobile OTP token
Related Tags:
Vending Machine Humor
The vending machine in our lunch room is notorious for taking your money and teasing you with a bag of chips dangling from the slot where it should drop. I suspect there’s a pretty high, 20%-ish “you aint gonna get what you want” rate on this clearly aging food dispensing unit. (Vending machine in lay terms) Sometimes shaking works, but we’ve heard that humans don’t always win in these situations.
A few times a week there’s usually a typical post-it note venting displeasure to the vending machine guy over the loss of money. Yesterday there were a lot of these, and I found this one in particular to be really funny.. largely because the evidence is overwhelming.
Well, Danielle.. I don’t know who you are but I hope you are one day reunited with your ABBA-ZABA, we feel your pain.
Related Tags:
Blesta 3.0: API Design
This is the first article, in what will be a series for Blesta 3.0, our next major release. When we sat down to discuss the primary goals of Blesta 3.0, one of the first topics to come up was API design. The two major issues we discovered with the original API design (of 1.0) were that:
- It was limited in its capabilities
- It was difficult and cumbersome to update
By implementing Blesta on top of an MVC framework (minPHP) we were able to create an automatic API, which eliminated both of these issues entirely. Within an MVC application the model contains all of the business logic, so the only thing required to complete the API is a controller to handle access to the various models. Since models are objects, the API controller can instantiate and access all of the public methods within a requested model. This facilitates requests on logical objects that may perform specific actions.
In addition, the API controller could now fulfill requests in any number of various formats (e.g. json, xml, etc.). The syntax was simple: /api/model/method.format.
The only thing necessary to complete the RESTful design were HTTP status codes, and the API controller easily handled those. The result is an automatic RESTful API system, that not only grants access to the Blesta core, but to the back end of any plugins installed within that copy of Blesta as well.
In case you missed it, this means that ALL public model methods will be accessible through the API. We’re really excited about the new API and how much support it lends to developers.
Blesta 3.0 is currently in active development. A release date has not yet been determined.