• products
    • nio Platform
    • nio System Designer
    • Pubkeeper
    • nio Blocks
  • licensing
  • case studies
    • agriculture
    • industrial
    • database migration
    • Raspberry Pi
    • operations and intelligence
  • enterprise
    • enterprise overview
    • platform security
    • partner
    • IoT wheel
  • resources
    • nio Platform technical white paper
    • security compliance white paper
    • use case: precision agriculture
    • use case: supply chain
    • use case: business operations

« Turning the volume up on security

January 24, 2018 3:55 pm build ideas 23 min Matt Dodge Updated: January 24, 2018 at 4:53 pm

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!


https://niolabs.com/app/uploads/2018/01/Tyler_SecurityBlog_4_optimized.mp4

Difficulty


Medium

Build time


Expert: 1 hour
Beginner: 3-4 hours

Build list


  • Raspberry Pi
    • set up and run nio
  • 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! If needed, our support team and our forum are just a click away!

Instance and Service Overview


Spotify Monitor Instance 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.

Authorizer Service Image

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 hidapilibrary. 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 an 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 applications and data. These controls ensure that roles and responsibilities within an organization are defined, policies are followed, and critical data is protected. Many of these controls, which enforce segregation of duties, provisioning of roles/responsibilities, etc., are dependent on privileged accounts and passwords (root, Domain Admin, DBA, QSECOFR, etc.). If these accounts are compromised or inappropriately shared, the risk of data loss is huge. 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.

  • Click to share on Twitter (Opens in new window)
  • Click to share on Facebook (Opens in new window)
  • Click to share on LinkedIn (Opens in new window)
  • Click to share on Google+ (Opens in new window)


295 Interlocken Blvd. Suite 500
Broomfield, CO 80021
phone: 1.877.231.0353
  • Company
    • enterprise
    • security
    • partner
    • licensing
    • blog
    • press and news
    • contact us
  • Products
    • nio Platform
    • nio System Designer
    • Pubkeeper
    • nio Blocks
  • Case studies
    • agriculture
    • industrial
    • database migration
    • Raspberry Pi
    • operations and intelligence
  • Build & learn
    • go to Designer
    • docs
    • workshops
    • nio Block Library
    • forum
privacy policy | terms and conditions | legal
© n.io innovation, LLC. All Rights Reserved.
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.Ok