Turning the Volume Up on Security

Let’s be real, everyone knows someone that “borrows” logins from friends and family for digital content services like Netflix, HBO, Hulu, and more, but there is one service that I personally pay dearly for (even on my starving student budget) and selfishly want to protect. That is my Spotify Premium Account. So, let me show you how I used the nio Platform to add an additional level of security to my Spotify account. With a blink(1) dongle connected to a Raspberry Pi, in real-time, I can see which of my devices are currently streaming music. If an “unauthorized” device attempts to stream from my account, I can repeatedly pause its playback and receive a notification containing the name of the unauthorized device that dares to use my Spotify account. Now my roommates and any other unwelcome user will stop trying to stream music from my account!

Difficulty

Intermediate

Build time

Expert: 1 hour

Beginner: 3-4 hours

Build list

• Raspberry Pi

• Set up and run nio on the Raspberry Pi

• Blink1 Dongle

• Spotify Web API

• Custom Spotify Authorization Block

• Template for this project

Why would you use nio to create this project?

While this particular project doesn't fall under your classic "IoT" use case, nio is the product of choice for this application because of its ability to combine and create automation using web API data and hardware. In a way, it is always monitoring my account and working in my best interest. I have the ability to quickly assign “authorized” device access and control how this access is enforced.

Monitoring from an edge node protects my credentials by limiting API access to a single device which is physically near me. I am in full control of where my credentials are stored and how they are used. Someone with the ability to steal my email/password login could potentially get my API credentials if they were stored in the cloud but breaking into my Raspberry Pi is more difficult without physical access to it.

This project is made simple using nio because of the ability to collect massive amounts of signals and guide them to the correct pieces of functionality. Changing the logic of this project is as simple as dragging a new connection from one block to another.

I encourage anyone with a Raspberry Pi and a nio binary to pull my nio project:

nio new my_monitor --template 
https://github.com/tlugger/spotify_monitor.git

Configure your credentials as needed, and run it for yourself! For a detailed walkthrough of how to set up this project, check out the README!

Instance and Service Overview

Spotify Monitor Instance

The is how all of the services, that are described below, are connected. This instance is made up of four services in order to make its functionality more modular.

Authorizer Service

The first service, Authorizer subscribes to an auth_request topic which passes a signal through my custom Spotify block to generate a fresh OAuth 2.0 token. This token can be used with the Spotify Web API to get streaming information about my account. The token is then published through a new_auth topic.

DeviceIndicator Service

The DeviceIndicator service combines a stored OAuth 2.0 token with a polling signal by using the AppendState block. Further down, the HTTPRequests block takes the token from each signal passed into it and makes an authorized request to the me/player endpoint of the Spotify Web API. If this block returns an error (meaning an expired OAuth 2.0 token), a new signal is sent through the auth_request topic to generate a fresh token. Otherwise, a response containing device info is returned and is checked against a list of “Authorized” devices. Authorized device signals are assigned an RGB color from the ConditionalModifier and published through a handle_blink topic. Unauthorized device signals are published through a bad_auth topic.

UseWarning Service

The UseWarning service subscribes to signals on the bad_auth topic and does three things. First, the RGB code for Red is assigned to the signal and published through the handle_blink topic. This notifies me through the blink(1) dongle on my desk that something malicious may be happening. Next, signals are sent to pause the playback on that device every 10 seconds. This flow takes advantage of the me/player/pause endpoint of the Spotify Web API. Finally, a notification is composed and sent to me through Slack using the Slack block. This notification will continue to be sent every half hour while the unauthorized device is on my account. The message contains the name of the device (`$device[‘name’]`) attempting to use my account as another form of monitoring and notifying malicious activity.

ShowDevice Service

The last service, ShowDevice, is another three block service which subscribes to the handle_blink topic. These signals are passed through a StateChange, to only pass signals for a change in a device using my account, and finally into the Blink1 block. The Blink1 block will take RGB color codes from signals and light up the dongle with the according color.

Finished Product

Challenges

Installing the blink1 block took some time for me the first time around. This can be attributed to its requirement on the hidapi library. Running sudo pip3 install -v hidapi allowed me to watch each step for the installation of this package (mainly as a sanity check). Another solution would be to download and install the hidapi package from source.

There are limitations introduced by Spotify's API. Getting the live status of the playback for a user account is no small feat. Occasionally authorization and rate limiting issues may arise. The best solution here is to fine-tune the polling interval for your instance to a reasonable rate.

Scaling nio to enterprise-level adoption

While this is a great solution for protecting an individual account and making sure your roommate isn’t trying to steal your music, it can be scaled to protect crucial information. Take a financial company holding massive amounts of sensitive client information. Access to this information should always be limited, but enforcing this access can become difficult. Login credentials from one user can be stolen and used from a device across the country.

For example, when logging into a Google account from a new device, you frequently receive a notification asking if this login was actually done by you. The notification shows you a device type and the IP address of that device, but it doesn’t actually take action for you. Someone with malicious intent could, therefore, login to your account, steal all of your information, and lock you out; all before you receive the notification that a new login occurs.

This project shows nio’s ability to monitor account access and notify a user of suspicious activity. It also takes action to prevent suspicious logins from moving any further. In my use case, I pause the playback of music every 10 seconds. This is a fairly small action but I can guarantee you would stop trying to listen to music if it automatically paused 20 times throughout a song. Bigger actions that nio could take would be to immediately freeze and lockout an account with suspicious activity while simultaneously notifying an administrator to investigate.

Additionally, IT departments and entire organizations depend on strict access controls to maintain the security of applications and data. Many of these controls, which enforce segregation of duties and the provisioning of roles/responsibilities, are dependent on privileged accounts and passwords (root, Domain Admin, DBA, QSECOFR, etc.). If these accounts are compromised or inappropriately shared, there is a large risk for catastrophic data loss. nio could be used to actively monitor and act upon all privileged accounts to make sure that an appropriate user/device is utilizing the account as it is supposed to be used.