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

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:

1. It was limited in its capabilities
2. 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.

minPHP Framework Released

           _       _____  _    _ _____
          (_)     |  __ \| |  | |  __ \
 _ __ ___  _ _ __ | |__) | |__| | |__) |
| '_ ` _ \| | '_ \|  ___/|  __  |  ___/
| | | | | | | | | | |    | |  | | |
|_| |_| |_|_|_| |_|_|    |_|  |_|_|
framework

minPHP is an extremely lightweight, object oriented MVC PHP framework brought to you by the same people who developed Blesta. minPHP is free, open source software released under the MIT license.

Download it at minphp.org.

One of the most awesome things about minPHP, aside from the fact that it’s awesome in itself, is that it’s being used as the framework for Blesta 3.0. Blesta 3.0 is in active development, with a release expected in the early part of next year.

We’re excited to be able to offer something to the open source community, and if you’re a developer we hope you give minPHP a try. As an added benefit, if you’re familiar with minPHP you’ll be a Blesta 3.0 development rockstar right out of the box.

Ooh, my spider-sense is tingling.

Suhosin

Suhosin is a (somewhat) commonly installed PHP module used by shared hosting providers to prevent (to some degree) malicious PHP code from compromising a shared environment.  Sounds great, but the problem is it spreads its tentacles into areas where, if unaware of its presence, can cause some very unexpected results.

This was the case in Blesta, until recently.

The issue experienced in Blesta was related to session handling.  Blesta uses a database to maintain session information, for added security and to permit load balancing.  Normally, a session ends when the user closes their browser, however it can be revive if a cookie is stored on the user’s machine and is then read when they revist the site.  But because Suhosin encrypts session data by default, our revival code had access to only encrypted data.  Essentially, the session couldn’t be revived.  The only way to decrypt the data is to have Suhosin do it.  So what we did was rename the session prior to starting it, which tricks PHP into thinking the session never ended, and so Suhosin takes over and decrypts the Session just in time.

The psuedo code looks something like this:

$session_id = $_COOKIE[‘session_id’];

session_name($session_id);

session_start();

PHP & C

For those familiar with C, PHP seems strikingly similar. From the syntax to the function calls. It’s almost as if you could replace a couple asterisks (*) with dollar signs ($) and add a PHP-tag or two, and you could run your C source raw.

#include <stdio.h>
 
main() {
	char *phrase = “hello world!n”;
	printf(“%s”, phrase);
}

<?php
function main() {
	$phrase = “hello world!n”;
	printf(“%s”, $phrase);
}
?>

The Big Blue C In recent time PHP has diverged from C’s familiar convention, in an attempt to offer a higher level experience. Much of this relates to IO. For example, PHP 4 required you to call fopen, then fwrite, and finally fclose in order to write content to a file, just as you would do in C. In PHP 5 file_put_contents was added in, which operates more of how you would expect from a scripting language. Although much has changed, some things likely never will. For example, command line parameters are handled in just about the same way. And while I haven’t viewed the source, I suspect fgetc directly invokes the C library. In fact, just about every function in the standard IO library (stdio.h) in ANSI C is represented in PHP. Static, Extern and Global PHP and C handle static variables within functions in exactly the same way. However, since PHP refuses to search the call stack outside of a function’s scope, a global keyword is required to pull these variables into scope so they can be used within a function. While this works similar to C’s extern declaration, unlike in C, you can’t ever use a variable defined outside a function, even if declared before the function, unless it is declared global or is one of the special “super global” types. C You Later PHP never had pointers, though they do offer references similar to Java. The difference being that a reference can’t be moved or reassigned as a pointer can using pointer arithmetic. PHP 5 raises errors when attempting to pass references to functions. While it’s still possible to pass by reference, the function or method signature must define it and the call must not include the ampersand (&). This is because, as of PHP 5, non-primitive types are implicitly passed by reference. While in some respects PHP has moved away from its C influence, in other aspects it’s become more similar. PHP 4, for example, added capabilities for variable length parameters, although in a much different way than C. Nevertheless, the C influence appears to be dwindling, in favor of higher level capabilities, such as XML parsing, and simpler IO. So it’s unlikely we’ll see new primitive C constructs, such as goto’s any time soon… or will we?