FACTOR TWO is combination of Drupal 7.0 module and Mobile HTML5 application which together provide simple to use and manage 2 factor authentication mechanism.

Once FACTOR TWO has been setup for particular user (via simple PIN exchange between Drupal site and Mobile Application), one time "factor" (10 characters string) will be required for each login. If the Mobile App has internet access to the Drupal site, "factor" could be submitted automatically by pushing single button. Once valid "factor" been submitted, use can login into the site with his/here normal login/password. "factor" remains valid for predefined time interval since it been submitted (30sec). If user fail to login during this time interval, he/she will have to re-submit new "factor".
The Mobile App utilize offline caching mechanism that allows it to run even when there is no internet connection (offline). If used offline, Mobile App will produce valid "factor", which user will have to enter into login form along with user name/password.

FACTOR TWO module provides small set of drush commands that allows to manage FACTOR TOW users (list/reset/setup)

FACTOR TWO Mobile App is build on Sencha Touch framework (http://www.sencha.com/products/touch/) and runs on iPhone/iPad and Android based phones (maybe on latest BlackBerry as well).

FACTOR TWO uses SHA256 JS implementation from crypto-js project (from http://code.google.com/p/crypto-js/)

Comments

atchijov’s picture

I do not see any direct link to my sandbox project anywhere on this page. So, here it is http://drupal.org/sandbox/atchijov/1081640

avpaderno’s picture

Status: Active » Needs review
atchijov’s picture

Top level description of how Factor Two works could be found in the blog : https://www.touchnoc.com/factor_two
"end user" video tutorial is at : http://www.youtube.com/watch?v=5fW_jFXVcr0

meba’s picture

I am not going to move this to RTBC because it would be good to check the licensing. I suggest you ask on IRC. Is the TOuch framework licensed under GPLv3? Is it compatible with drupal.org repository?

I don't like this: print '{ "status" : "error", "msg" : "incorrect factor ' . $newFactor . '" }'; You should use drupal_json imho? Just a nuisance.

Once the licensing is confirmed, it's good to go.

atchijov’s picture

RE: GPLv3 license compatibility
------------------------

According to http://www.sencha.com/products/touch/license/ it is GPLv3

Sencha is an avid supporter of open source software. This is the appropriate option if you are creating an open source application with a license compatible with the GNU GPL license v3. Although the GPLv3 has many terms, the most important is that you must provide the source code of your application to your users so they can be free to modify your application for their own needs.

Also, to consider: The framework itself (Sencha Touch) is NOT checked in into drupal.org repository. It is expected that it will be downloaded by module user and installed into sites/all/libraries/factor_two. I am planing to add ability to "auto-install" the Sencha via FACTOR TWO admin interface and/or Drush command.

attiks’s picture

Status: Needs review » Reviewed & tested by the community

There are still some minor spacing issues, but it looks solid.

rfay’s picture

Status: Reviewed & tested by the community » Needs work

Please remove the LICENSE.txt file, as that's no longer allowed (the packaging system provides its own)

Please remove the $Id$ as we don't use that since the git migration.

Consider using the library API from http://drupal.org/project/libraries instead of hard-coding the 'sites/all/libraries'.

I'd rather see you using Drupal's unmanaged file API than using direct PHP file manipulation, but there's a case for both.

Congratulations on having the drush command. I love to see that.

There are some trailing whitespace issues. Consider using an editor or tool that will clean up whitespace for you.

/*
  Hooks

 hook_permission
 */

Please use the coding standards for docblocks

    '#title' => 'Successes Counts  hot/login',

There are lots of form #title strings not wrapped in t() to make them translatable.

There are lots of undocumented functions.

atchijov’s picture

I will address all these issues ASAP. My only reservation is about

Consider using the library API from http://drupal.org/project/libraries instead of hard-coding the 'sites/all/libraries'.

Though I do appreciate usefulness of libraries module, I am reluctant to introduce dependency on 3rd party module. This kind of functionality really should be in Drupal Core.

rfay’s picture

@atchijov, try the approach in #1137370: Please support libraries API and allow S3 PHP lib to be placed in sites/all/libraries, which doesn't introduce dependencies.

atchijov’s picture

tyvm. I was thinking of going along this lines.

atchijov’s picture

I have fixed all problems indicated in #7 except:
- removing hard-codded 'site/all/libraries'
- adding comments to all functions

I am not really sure what to do about 'site/all/libraries'. There are 2 pieces of 3-rd party code which F2 need to function: Sencha Touch and single file from crypto-js project. I can see that Sencha Touch may be used by other modules (thought to the best of my knowledge at the moment no one using it). I have serious doubts that many modules will ever use crypto-js. In current version of F2, I expect to find both Sencha Touch and crypto-js in F2 specific folder 'site/all/libraries/factor_two'. To make it "compatible" with spirit of libraries module, I will have to move these two folders ( Sencha Touch and crypto-js) one level up 'site/all/libraries'. I will be reluctant to do this until 'libraries' module become de-factor standard (or even better become part of the core). Until this happen, putting anything right into 'site/all/libraries' could become source of troubles. There is no any kind of naming convention in place - hence there is no way for me to guaranty that "my" dependency folders will not collide with some other module dependencies. Probability is quite low, but it is not 0. To be blunt, I am not sure that there is anything to gain here until 'libraries' become the only way to deal with this.

I am going to keep documenting functions, but there are quite a few of those and I am not very fast/good at writing documentation. So I wonder if you can cut me a slack on this?

rfay’s picture

Status: Needs work » Needs review

sites/all/libraries was a suggestion, not a requirement.

Note that there are many benefits of this approach, even without the libraries module. People who use drush to deploy code are in trouble with internally placed libraries, because drush does a clean install of the module on update. People who use git submodules can't do it with an extra piece of software inside their modules unless they deploy an extra repo.

Placed this into needs review.

rfay’s picture

Status: Needs review » Reviewed & tested by the community

RTBC.

I'd like to see the README.txt have line breaks before the 80-column limit, so it can be read in an editor that doesn't wrap lines. And of course it can still use lots and lots of commenting, documenting the functions.

atchijov’s picture

I'd like to see the README.txt have line breaks before the 80-column limit

Done

rfay’s picture

Status: Reviewed & tested by the community » Fixed

OK, Git vetted user role granted. Welcome, and thanks for your contributions (and your patience in this process).

Please review other applications so we can get this queue down.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.