TL;DR

Starting on Friday, March 13th, Octoblu will be requiring all users who signup up with email/password to use the reset password functionality and set a new password. Twitter, Facebook, Github, or Google authentication you will simply need to accept the Octoblu Auth application again.

The Old Way

In the past, we used a very traditional mechanism to verify a user’s identity. We would have users sign up using an email address and a password. Then, our Octoblu backend would then encrypt the password using a one-way hash function and store it on a user record in our database. Each time the user logs in, we rehash their password, and compare it with the hashed one we have stored. If they match, the user entered in the correct password and is allowed to proceed.

The Problem

In our Octoblu application, a user corresponds to a device that is created within Meshblu, which we call the user-device. This allows us to use all our patent pending device security logic to enforce user logic as well. However, it meant that a users record in Octoblu would need to have the user-device’s token in a decryptable form in order to take action on the user’s behalf. This was not acceptable to us, because it meant we would have to have the ability to decrypt a user-device’s token.

The Solution

Therefore, we decided to create a new service. The way we see it, authenticating users is a completely separate concept from managing devices, flows, and security groups. We created an authenticator whose only job is to exchange an email address and a password for a user-device’s uuid and a one-time session token that the user can then take to Octoblu to enable Octoblu to act on their behalf.

Verifying the User

Step one in the authenticator is verifying the user’s identity. The Email/Password authenticator does this by looking up the user-device record in Meshblu by the email address provided. The authenticator will only check devices that it has access to and are of the correct type. Then, verify that the password the user entered matches up with the hashed version we have stored on their user-device.

Subtle Subtleties

This user-device lookup by email address opens up a security problem. If I know a user’s email address, I can create my own user-device directly in Meshblu with the same email address and the permissions set so that it comes up in the authenticator’s search. If my device comes up before the real user’s, then they will be logged in to my device instead of their own. Now they have unwittingly granted me the ability to discover, spy on, or modify any devices they create or claim after that point. To prevent this, the authenticator prepends the device-user’s uuid to the password before hashing it. Then, it signs the section of the user-device record that it uses for authentication using its private key. This way, only records actually created and modified by the authenticator are considered valid, and the user’s account cannot be hijacked.

Obtaining a Session Token

How does the authenticator provide the user with a token to handoff if it isn’t allowed to store them? We used Meshblu’s whitelist permission model to grant the authenticator enough access to create a new one-time use token to provide to the user. The token is then passed as a GET parameter to Octoblu, where it is immediately removed and a longer term token is generated. The token is passed down the user and is immediately forgotten by Octoblu. The user then has their own session token locally on their machine and nowhere else, which means we don’t have to store the token at all on the server.

From there, the user simply passes the token up to Octoblu whenever they want Octoblu to perform some action on their behalf. Each time, Octoblu performs the action and promptly discards the token. In this way, the actual user will be the only person that will actually store tokens of any kind outside of Meshblu, and the only place that a decryptable version of the token will ever be stored.

We used the same general concept to craft four more authenticators, one for each one of the oauth providers we allow for login (Google, Facebook, Twitter, and Github). Any third-party user may also write their own authenticators into Octoblu, all we need is a device’s uuid and one-time token and we will allow the user to manage all their owned devices. For example, you could create a SAML authenticator that will allow you to give Octoblu access to your Active Directory users.

What This Means For You

We originally created user accounts in the standard Old Way. Starting on Friday, March 13th, we will be requiring all users who signup up with email/password to use the reset password functionality and set a new password. Twitter, Facebook, Github, or Google authentication you will simply need to accept the Octoblu Auth application again.