Two Factor Authentication: SMS vs Security Key

I use two factor authentication (2FA) on a number of platforms, including PayPal. I recently got locked out of PayPal when their 2FA SMS messages stopped arriving at my phone. Thankfully, I found an alternative in the form of the Symantec Validation and ID Protection Service (VIP), an app that generates tokens on the fly on mobile devices and the desktop, and is compatible with PayPal.

Illusion of security

Two Factor Authentication is no guarantee of security, of course. I have been using SMS 2FA, and text messages must pass through a vast, insecure network to get to my phone. Who says they can’t be intercepted? As well, any security system these days is dependent on the fact that my password is actually stored on the server where I’m trying to log in, which means the security of my info is only as strong as the encryption techniques used by the service I’m using. Think Adobe. Combine the insecurity of SMS with potential hacks, and the whole thing seems a bit of a mirage. But, it’s all we’ve got right now. And adding the layer of 2FA on top of a properly encrypted and properly complex password makes me feel a little less naked.

Locked out of PayPal

I would still be using SMS 2FA if I hadn’t been locked out of my PayPal account, a combination of poor SMS service and my own forgetfulness. PayPal’s SMS 2FA tokens were not arriving at my phone. PayPal offers a way to bypass 2FA temporarily by answering a series of security questions, but one of my own practices made that impossible.

I always provide nonsense answers to these security questions, and store the answers in my password manager. This prevents an attacker from digging into my past and guessing answers to those idiotically simple questions like “What was your mother’s maiden name?” In this case, however, I’d obviously changed one of my answers and forgotten to update it in LastPass. So I was effectively locked out of PayPal.

Thankfully, I located my misplaced answer, and managed to log in and deactivate SMS 2FA. But what now? Although 2FA is not perfect, it’s an extra layer of security that makes it more difficult for attackers to gain entry. I needed something.

Alternative to SMS 2FA

Enter Symantec, and their VIP app. It’s essentially a digital version of the Security Keys that PayPal used to distribute, similar to the Google Authenticator app. It provides a unique, temporary (good for 30 seconds) 6-digit key that can serve as a 2FA token. Each installed app has a unique serial number that must be registered with PayPal. So far, it has worked beautifully. And no waiting around for SMS messages!

It would be nice if one of these apps could be used for all the services for which I have 2FA enabled, but that’s just a pipe dream right now. Google Authenticator, for example, won’t work with PayPal. Ah, well. The time will come, I guess. For now, I’ll continue to use SMS if there is no other option, and will use whatever key app is required for various services.

If you’re having trouble with PayPal SMS for 2FA, Symantec’s VIP may be the answer.

Related links:

Symantec Desktop VIP key

Symantec Mobile VIP key

Why am I trying to make Slim into something it’s not?

I love working with Slim Framework. It’s easy to use, and its documentation is clear and concise. Not only that, its support forums are full of great info, and the developers participate regularly. It’s ideal Open Source software.

Because it’s so easy to use, I’ve been using Slim for a number of projects I’ve been working on. The problem is, it’s so easy to bend Slim to your will, it’s easy to bend out of shape. For example, I thought it would be a good idea to extend slim into a standard MVC with the requisite folder structure:

  /public
    /assets
    /index.php

  /app/
    /config
      /routes.php
      /config.php
    /controllers
    /models
    /views

This was fairly easy to accomplish, but maybe not such a good idea.

Well, not completely, anyway. This approach actually works nicely for small projects. The more I worked to use Slim as a standard MVC, however, the more it started to feel inadequate. I began looking for packages to install to extend its functionality, to make it easier to use. Before long, I realized I’d have to build Slim into a full MVC framework in order to achieve the results I was looking for, and that was going to take a lot of work.

It wasn’t Slim’s fault

The thought of a “Full MVC Framework” is what finally snapped me out of it. Slim is a lightweight micro-framework designed for quickly deploying APIs or smaller projects. It seems to do that exceptionally well. However, there are already a number of good full frameworks out there. Why force Slim to be something it’s not? Trying to convert Slim into a full MVC framework defeats the purpose of having a micro-framework to begin with.

So, I finally relented. When Slim feels like the right answer — and there are a number of projects where it is the perfect solution — than I’ll use Slim. When using Slim will require me to bend it out of shape, or do far more work than I really should, then I won’t use Slim.

My takeaway? use the right tool for the job. Sorry, Slim, my fault, not yours.

Using a Composer package in a private Git repository

It’s easy enough to require or install public packages with Composer, particularly if they’re hosted on Packagist.  Recently I had to work with packages stored in private repositories for a project.  It took me a little while to figure out the ins and outs of that, so here are my notes in case it is of use to someone in a similar postion.

Tell Composer where to look

Composer can find public packages at it’s public repositories like Packagist, so you don’t have to do anything special to install them.  Commands like

composer require slim/slim

will work just fine.  With a package in a private repository, however, Composer won’t know where to look. The solution is to add the repository to your composer.json file:

  "repositories":[
    {
      "type": "vcs",
      "url": "git@bitbucket.org:vendorname/mypackage.git"
    }
  ],
  "require": {
    "vendorname/mypackage": "dev-master"
  }

Things to note

The repo URL for a private package uses the ssh protocol, not https.  That means you’ll need a private/public key pair set up for the private repo you want to use. If the repo is a public one, but unreleased on Packagist, you still need to tell Composer where to find it, but you can use the standard https protocol.

The version number for unreleased packages must begin with “dev-“, or the package won’t download.

Finally, note that packages installed in this manner are full Git repositories, which means you can continue working on them, committing, pushing, branching, etc., after they are installed in the vendor folder.

Check out the excellent composer documentation for details on implementing this.

Composer VCS Documentation