Hashing security token

[dfaulken]

In order to not be sending security tokens over the air, which would enable anyone who intercepts them to impersonate the service they belong to, instead the security tokens will live locally with the router and with each service. When the service sends the checkin request, it will hash that request using the security token as a salt, and send the resulting hash along with the request.

The router will then do the same: use the security token to hash the request (minus the hash that came from the service), and compare the two hashes. They should match.

Thanks to @werebus for the suggestion.

[dfaulken]

Along with this, we should roll an application controller before_action which will identify the current service based on its token. (#27)

This means that the process of adding a 'new' service will involve manually adding it and its token, hopefully in some kind of UI rather than the Rails console, and then starting it up so that it can declare its models. (#28)