Integrating Trusted Registration for PushAuth™

Welcome to the final post of the Power of PushAuth™ blog series. In this post, we will enhance the basic website we created in the Building a Web Application with PushAuth™ post by integrating trusted registration to provide a way for the mobile SDK to only register authorized users.

For a detailed explanation on trusted registration, please refer to the following:

In this tutorial, we will integrate trusted registration into a web application so that a user, upon signup, is given a 4 digit “pairing code” they can enter in the mobile app. After this, the mobile client added will be the only one who is able to receive login request push notifications.

The end result of this blog post will be almost identical to the publicly available sample web application used in the previous blog post that introduced trusted registration.


To follow this tutorial, you will need:

This tutorial assumes a basic familiarity with the Rails framework. Also, the starting point of this guide is the Rails app we built in the Building a Web Application with PushAuth™ post. If you have not followed this previous post to build the web application from scratch, you can clone the pushauth-sample-server in our GitHub repository as the starting point. If you choose to use the GitHub project as a starting point, make sure to initialize the project by following the steps in README of the project.

Step 1 – Provide a pairing code for users

Database Setup

First, we need to add new data to the User table in the database to keep track of an integer pairing code and a boolean which tracks whether or not the code has been used.

Let’s generate a migration to add these columns:

$ rails generate migration add_verification_code_to_users verification_code:integer

The newly generated migration should look like this:

# db/migrate/{some_date}_add_verification_code_to_users.rb

class AddVerificationCodeToUsers < ActiveRecord::Migration[6.0]
  def change
    add_column :users, :verification_code, :integer

We also want to add a column to keep track of whether each pairing code has been used. This column should default to false so that we don’t have to set it when we create a user. Add this line under the other add_column line from the migration file:

add_column :users, :verification_used, :boolean, default: false

Run bundle exec rails db:migrate, and we should have the appropriate database setup.

User Model

Let’s add some business logic to our User model so that we can ensure the consistency of our table.

We want to add validation to the username such that it must be unique, and we want to add a before_create hook that generates a random verification code for a new User. While we’re at it, we may as well make a function that tries to use up a validation code, and returns whether or not it was a success.

# app/models/user.rb

class User < ApplicationRecord

 validates :username, presence: true, uniqueness: { case_sensitive: false }

 before_create :generate_verification_code

 def consume_verification_code(provided_code)
   if provided_code == self.verification_code && !self.verification_used
     self.update_attributes(verification_used: true)


 def generate_verification_code
   self.verification_code = SecureRandom.rand(1000...9999)

A quick note about consume_verification_code: in absence of any statements following the if, Ruby will return a boolean corresponding to the evaluated condition, so this will return true if and only if the code was correct and had not been used before.

Users Controller and View

Now, let’s make a UsersController so that we can implement user registration:

$ rails generate controller Users

In UsersController, we will add three actions

  • new : a signup form
  • create : the endpoint to which the signup data is sent
  • post_signup : the page displaying the verification code to the user
# app/controllers/users_controller.rb

class UsersController < ApplicationController
  skip_before_action :authorized

  def new
    @user =

  def create
    @user =, :password))

      session[:signup_username] = @user.username
      session[:signup_verification_code] = @user.verification_code
      redirect_to post_signup_users_path
      render :new

  def post_signup
    @username = session[:signup_username]
    @pairing_code = session[:signup_verification_code]

Now, let’s add some new views.

app/views/users/new.html.erb for the signup page:

# app/views/users/new.html.erb

<%= form_for @user, class: "form-signin" do |f| %>
<% if @user.errors.any? %>
    <div class="error_messages">
      <h2>Form is invalid</h2>
        <% @user.errors.full_messages.each do |message| %>
          <li><%= message %></li>
        <% end %>
  <% end %>
  <%= f.label :username, class: "sr-only" %>
  <%= f.text_field :username, class: "form-control", placeholder: "Username", autofocus: true %>

  <%= f.label :password, class: "sr-only" %>
  <%= f.password_field :password, class: "form-control", placeholder: "Password" %>

  <%= f.submit "Sign up!", {class: ["btn", "btn-lg", "btn-primary", "btn-block"]} %>
<% end %>

app/views/users/post_signup.html.erb displays the pairing code.

# app/views/users/post_signup.html.erb

Thanks for registering! Please enter the following in our app:

  Username: <%= @username %>
  Pairing code: <%= @pairing_code %>

And finally, we add our routes:

# config/routes.rb
# somewhere within the main do...end block

  resource :users, only: [:new, :create] do
    get "post_signup"

We now want to add signup links from a couple different pages:

Replace the Welcome! Please <%= link_to "log in", "login" %>. line in app/views/application/home.html.erb with the following:

Welcome! Please <%= link_to "log in", "login" %> or <%= link_to "sign up", new_users_path %>.

And add this to the bottom of app/views/sessions/new.html.erb:

Don't have an account yet? Sign up <%= link_to "here", new_users_path %>!

At this point, you should be able to test the new signup flow by running bundle exec rails server.

Step 2 – Implement Trusted Registration Webhook Endpoint

When the user enters their name and pairing code in the app, the UnifyID PushAuth™ service will send a POST request to the Rails app for permission to add a device. On the Developer Dashboard, you can set up the endpoint URL. A detailed explanation on how the trusted registration webhook endpoint works can be found in the previous blog post.

We will make an endpoint for user verification at /users/trust, which checks if a given user and a challenge token (i.e., the pairing code for this sample website) match with our database records.

# app/controllers/users_controller.rb
# add these lines right under "class UsersController < ApplicationController"

  skip_before_action :authorized
  skip_before_action :verify_authenticity_token, only: :trust
  http_basic_authenticate_with name: Rails.application.credentials.unifyid[:basic_username],
    password: Rails.application.credentials.unifyid[:basic_password],
    only: :trust
  def trust
    @user = User.find_by(username: params[:user])
    if @user && @user.consume_verification_code(params[:challenge].to_i)
      head :ok
      head :unauthorized

Let’s take a look at these in a bit more detail:

  skip_before_action :verify_authenticity_token, only: :trust

By default, Rails has cross-site request forgery protection for forms, which means that a form that submits data via POST will have an authenticity token that makes it difficult for attackers to manipulate your browser into performing unauthorized requests. You can read more about this before_action here.
For our use case, however, the UnifyID service will not know the proper authenticity token, so we relax that requirement on the trust action.

  http_basic_authenticate_with name: Rails.application.credentials.unifyid[:basic_username],
    password: Rails.application.credentials.unifyid[:basic_password],
    only: :trust

This adds HTTP Basic Authentication to the /user/trust endpoint in order to make sure the request is from the UnifyID PushAuth™ service. Note that you will have to add basic_username and basic_password entries to the Rails application credentials (bundle exec rails credentials:edit).

Finally, we can add our route:

# config/routes.rb

  resource :users, only: [:new, :create] do
    post "trust"

    get "post_signup"

And there you have it! We’ve added user signup, and we have secured mobile client registration to to UnifyID PushAuth™ service. The end result should look like our pushauth-sample-server-reg project in GitHub, which was introduced in the Power of Trusted Registration blog post.

This concludes the Power of PushAuth™ blog series. Thanks for following along, and feel free to reach out to us if you have any questions, comments, or suggestions!

Interview With John Whaley – UnifyID by Safety Detectives

John Whaley: Founder and CEO of UnifyID

Aviva Zacks of Safety Detectives sat down with John Whaley, Founder and CEO of UnifyID. She asked him about his company’s challenges and solutions.

Safety Detectives: What was your journey to cybersecurity and what do you love about it?

John Whaley: I went to MIT for undergrad where I majored in computer science and learned about how security is implemented in the real world. During my Ph.D. at Stanford, my thesis was on the static analysis of source code to automatically find bugs, security flaws, and security holes within the software.

I founded my first company out of Stanford which was in the security space, and now I’ve started a second company in the space as well.

SD: What motivated you to start UnifyID?

JW: What I found was that every time you type a key on the keyboard, it sends a network packet, the content of which was encrypted, but you could look at the timing between the packets and then, based on that, you could determine the timing of a user’s keystroke as they typed. So we built a demo of this solution for a security conference.

It turns out that if you know the timing of somebody’s keystrokes, then you can figure out with fair reliably what it is that they are typing because, as you move your fingers around a keyboard, the spacing between them and the duration of the time between keystrokes can leak the information about what you are typing.

We used Wireshark in the demo to capture a packet trace between the client and the server for some of these major products. Then we dumped that packet trace into a tool that would look at the timing between each of the packets, and then based on that, try to make a prediction about what the user was typing.

SD: What have been some challenges?

One of the challenges we had in building the demo was the fact that everyone has their own unique way of typing. And so, you could train a model that would work well for one person, but it wouldn’t necessarily work well for other people. That’s where we first got interested in noticing habits and idiosyncrasies that we could use for identity authentication. I noticed that passwords were a real challenge. Moving forward, we knew that the password alone was not going to be the way that people would be authenticated. While the password is not completely going away yet, we are starting to see its limitations and the need for additional authentication factors to provide secure digital experiences.

SD: Which industries use UnifyID and why?

JW: We have a lot of interest from the financial services industry because fraud is very costly in that area; they have a need for high security but there’s also a need for seamless user experience. The other areas are cryptocurrencies and crypto exchanges. Any type of case where there is a sharing economy where you need to authenticate not only the user, but also the worker, because the worker may not be a full-time employee of the company, and they want to make sure that the correct person is the one making a delivery or walking your dogs.

In many cases, people use our technology for streamlining physical access: for unlocking doors and cars for example, where you want security and you also want a seamless user experience.

SD: What do you feel is the worst cyberthreat today? 

JW: The biggest cyber threat continues to be the attacks that go after the end-user. We’ve reached a point now where firewalls are no longer easy targets. It is now much easier and much more lucrative to go after individuals and try to steal their identity during the authentication process by tricking them into authenticating. This way the attacker hijacks the individual’s session to take over their account and then either transfer money out or use the hijacked account as a launch point for new attacks.

When I was young, hackers were hobbyists who were hacking for fun to prove something. There was not a lot of money in it, and it was not particularly malicious. Fraud is now a cybercrime and cyberattacking is now a large industry. There is a lot of money in it. The attacks have gotten very sophisticated. Attackers will steal someone’s identity, wreck their credit, and use that to launch different types of attacks to try to extract money out of even more people.

Until now, humans have always been the weak link in security—getting tricked into either clicking through a phishing site, entering their password in the wrong place, or getting socially engineered over a phone call. WIth UnifyID’s behavioral biometrics technology based on motion and the way each one of us behaves, humans become a strong link in security just by behaving the way they usually do.

“Suddenly there is a much greater need to remotely authenticate people…”

John Whaley

SD: How important is multifactor authentication in the light of COVID-19 and the increase of employees working from home?

JW: The number of attacks has increased by almost 800% since the start of COVID-19. In the recent past, you were able to implicitly be authenticated due to the fact you were physically at the office, which takes security measures to let you into the building itself. Now, with everyone working remotely, suddenly there is a much greater need to remotely authenticate people as now a larger number of us works remotely.

One of the additional drivers for hacking is the current economic situation. In the current world environment, more and more people are out of work and lacking positive economic prospects. These conditions could drive more people to engage in hacking.

Interview originally published on Safety Detectives.

The Power of Trusted Device Registration

Welcome once again to the Power of PushAuth™ blog series! This post builds on the previous posts by providing an extension of our sample project with feature and security enhancements.

The Problem of Unchecked Device Registration

In the “Is push authentication perfect?” section of the first post in the series, we pointed out some shortcomings of relying on push authentication as a means to authenticate users. Recall the following from that section:

“There’s also the issue of trusting a device to be associated with its true user during registration, as well as not allowing attackers to register devices under the true user’s account.”

The first iteration of the open source sample project did not provide a solution to this problem. With that initial, simple implementation of PushAuth, there was virtually no confidence in the devices registered under a given username. If an attacker were able to obtain the SDK key and one or more usernames registered on the server, they could configure the app on their phone and fraudulently accept or reject push notification login attempts. This security hole allows attackers to impersonate true users and access their resources in the website, or to lock a true user out of accessing their own resources. Not great, considering this is supposed to be a method of increasing the security of the authentication flow.

Trusted Device Registration

The extension presented in this post, however, does include trusted device registration! It also provides the added feature of user registration in the website. Remember that the initial project required users to be created in the console. Only users whose username and password were inserted to the database in that manner were able to log in to the website and receive push notifications. Now users register in the website directly. Once a user signs up in the website, they configure the sample app on their phone in order to authorize future login attempts. This is where trusted device registration comes into play.

What’s different for the user?

After dictating what username and password to associate with a new user, the website displays a four-digit pairing code. The user is instructed to enter that pairing code in the sample app with their chosen username. If the values match, then the user will receive push notifications during login attempts and be able to respond accordingly. If the username and pairing code do not match, then registration of that mobile device fails. This means they will not be able to receive push notifications to confirm or deny login attempts. An attacker will not know that unique pairing code, so they are unable to impersonate a user in the app.

How does this work?

The PushAuth sample server now has a verification endpoint, /users/trust, which accepts webhook requests from UnifyID’s PushAuth service. UnifyID’s server makes an HTTP POST request to a configured target URL, which is set in the project’s dashboard. The request body contains the username and the pairing code. The /users/trust endpoint looks up the given username and determines if the provided pairing code matches the server-generated code displayed during that user’s registration. If the request returns 200, then the user is considered verified and the device trusted. However, if the request returns anything else, the user is not considered verified and device registration fails.

The webhook target URL must use the https scheme and requests use the ‘Basic’ HTTP Authentication scheme, which can be used to validate requests. Further, the four-digit alphanumeric code generated by the server is single-use. These details collectively make it harder for an attacker to impersonate users. An attacker does not have access to the pairing code during initial sign up and they also cannot reuse the pairing code, thus ensuring that devices registered with users are trusted to belong to the true user.

Note: The way we chose to implement trusted device registration with a pairing code is by no means the only method of implementing trusted registration via webhook.

What are the limitations?

If you remember from our first post in the series, there will seemingly always be security holes in a login flow. This enhancement is no exception. For one, the pairing code is only displayed during user registration. What if the user accidentally closes out the tab and then has no way to pair their device? Or what if something happens with the device or app on their device and they have no way to reconfigure an app to be tied to their user? There’s also the concern of in-person over-the-shoulder access to the pairing code, where an attacker could see the four digits and enter the code on their phone before the true user is able to do so. However, just like before, there are solutions to those problems as well; they just aren’t included here. The extension we provide is certainly a big security improvement and patches one of the larger holes that existed in the initial sample project.

Developer Changes

Now that we’ve gone over the concept of trusted device registration and the value it adds to the PushAuth sample project, we’ll walk you through the actual changes from a developer’s perspective. The new repositories can be found here:

We have videos on the UnifyID YouTube channel to walk you through the full end-to-end flow of adding PushAuth to a website login flow with trusted registration.

Trusted Registration Webhook

First and foremost, you’ll need to enable trusted registration for your project in the dashboard. Reference the Setting up Trusted Registration section of our documentation to do so.

The server needs to be publicly available for the target URL to be used. If you want to follow along the tutorial without hosting the web server, we suggest using ngrok to expose the sample rails server running locally on your machine to the internet. The steps shown in this post will do that.

$ ngrok http 3000

Session Status                online
Account                       morganfrisby (Plan: Free)
Version                       2.3.35
Region                        United States (us)
Web Interface       
Forwarding           -> http://localhost:3000
Forwarding           -> http://localhost:3000

The target URL is the https URL forwarding to your local server, with /users/trust appended. For example:

Once you add the target URL, trusted registration is enabled for your project. The username and password displayed are used in HTTP Basic Authentication. The username value is set to unifyid, and the password is an auto-generated random string. This value can be rotated, should it become compromised.

Now that the trusted registration webhook is set up in the dashboard, you’re ready to move on to setting up the server.

Server Setup

Other than that, server setup more or less follows the instructions from the first tutorial. Since users are now registered on the website, there is no need to create users in the console during server setup. The other change is the addition of basic_username and basic_password to the credentials file, which are the values found in your project dashboard under the Trusted Registration Webhook section, shown above.

The streamlined steps to spin up the server are now:

$ git clone
$ cd pushauth-sample-server-reg
$ bundle install
$ yarn install --check-files
$ bundle exec rails db:migrate

$ EDITOR=vim rails credentials:edit
  server_api_key: <your_key_goes_here>
  basic_username: <basic auth username for /users/trust webhook endpoint>
  basic_password: <basic auth password for /users/trust webhook endpoint>

$ bundle exec rails server

Feel free to reference the detailed tutorial in our previous post for more context around those commands, or the technical details blog post to understand how the server was built. Our next post in the series will provide the technical details of the trusted registration extension of the sample server.

You can see the new website screenshots here (notice the pairing code in the third screenshot):

Sample App Setup

Nothing changes from the developer’s perspective for the iOS and Android sample apps; simply clone the updated repositories and follow the same instructions from earlier in the blog series. Those two posts can be found here:

The iOS sample app screens will look like:

The Android sample app screens now look like:

That’s it! Thanks for following along with the Power of PushAuth™ blog series. The next, and final, post will include the technical details of adding trusted registration to the sample project. Until then, feel free to reach out to us with questions or comments at

Building a Web Application with PushAuth™

Welcome back to the Power of PushAuth™ blog series! This is the fifth post of the Power of PushAuth™ blog series. The first post of the series was a comprehensive guide to push authentication. The subsequent three posts comprised an end-to-end sample implementation of PushAuth™ in a simple user login flow:

  1. Web Server tutorial
  2. iOS Mobile App tutorial
  3. Android Mobile App tutorial

In this post, we will create a sample website from scratch using Rails, and will integrate PushAuth™ APIs into the user login flow. Along the way, we will also provide technical details on how the website interacts with PushAuth™ APIs, which can help readers incorporate PushAuth™ into any existing website. The end result of this tutorial will be similar to the sample web server we deployed in Web Server tutorial.


To follow this tutorial, you will need:

This tutorial assumes a basic familiarity with the Rails framework.

Step 1: Make basic Rails app with simple session-based authentication

First, we will create website with a simple username/password authentication, without incorporating UnifyID PushAuth™. Step 2 will integrate PushAuth™ into the website we create in Step 1.

Project Initialization

$ rails new push_auth_demo
$ cd push_auth_demo

Let’s add the bcrypt gem to our Gemfile by uncommenting this line in Gemfile:

gem 'bcrypt', '~> 3.1.7'

Now, we will run bundle install to update the Gemfile.lock.

Next, we can add the User model to our database; each User will have a username and a password hash.

$ rails generate model user username:uniq password:digest 
$ rails db:migrate

Now, we can generate the controller for handling sessions.

$ rails generate controller sessions new create destroy

Controller Logic

The basic idea of session-based authentication is pretty simple:

  • When a user logs in, session[:user_id] is set to be the unique index of the corresponding User in the database.
  • When no one is logged in, session[:user_id] should be unset.

We’ll start with writing the Application controller, where we have a couple of simple page actions:

  • GET / (application#home) renders a page that shows links to other pages and actions
  • GET /restricted (application#restricted) renders a page that is only accessible when logged in.

A few helper functions will live here as well:

  • current_user should either return a User object, or nil if there’s no one logged in.
  • logged_in? should return whether someone is logged in
  • authorized is an action that is called before loading pages that require the a user to be logged in.
# app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
  before_action :authorized
  helper_method :current_user
  helper_method :logged_in?

  skip_before_action :authorized, only: [:home]

  def current_user
    User.find_by(id: session[:user_id])

  def logged_in?

  def authorized
    unless logged_in?
      redirect_to login_path, alert: "You must be logged in to perform that action."

Now, we’ll handle users logging in or out through the Sessions controller.

  • GET /login (sessions#new) action displays a login page unless the user is already logged in
  • POST /login (sessions#create) will authenticate the user and set the session.
  • DELETE /logout (sessions#destroy) action will clear the user’s session cookie.
# app/controllers/sessions_controller.rb

class SessionsController < ApplicationController
  skip_before_action :authorized, except: [:destroy]

  def new
    redirect_to root_path if logged_in?

  def create
    @user = User.find_by("lower(username) = ?", params[:username].downcase)
    if @user && @user.authenticate(params[:password])
      session[:user_id] =
      redirect_to root_path, notice: "Successfully logged in!"
      redirect_to login_path, alert: "Sorry, that didn't work."

  def destroy
    session[:user_id] = nil
    redirect_to root_path, notice: "Successfully logged out."

We also need to add routes for these actions.

# config/routes.rb

Rails.application.routes.draw do
  root "application#home"

  get "restricted", to: "application#restricted"

  get "login", to: "sessions#new"

  post "login", to: "sessions#create"

  delete "logout", to: "sessions#destroy"


home page where you can click on the link to log in/out:

<!-- app/views/application/home.html.erb -->

<h1> Welcome! </h1>

<% if logged_in? %>
  Welcome, <%= current_user.username %>. <br />
  <%= link_to "Log out", logout_path, method: :delete %> <br />
  Click <%= link_to "here", restricted_path %> to see a super secret page!
<% else %>
  Please <%= link_to "log in", login_path %>.
<% end %>

restricted page to test access control:

<!-- app/views/application/restricted.html.erb -->

Shhh, this page is a secret!

sessions#new renders simple login form:

<!-- app/views/sessions/new.html.erb -->


<%= form_tag "/login", {class: "form-signin"} do %>
  <%= label_tag :username, nil, class: "sr-only" %>
  <%= text_field_tag :username, nil, class: "form-control", placeholder: "Username", required: true, autofocus: true %>

  <%= label_tag :password, nil, class: "sr-only" %>
  <%= password_field_tag :password, nil, class: "form-control", placeholder: "Password", required: true%>

  <%= submit_tag "Log in", {class: ["btn", "btn-lg", "btn-primary", "btn-block"]} %>
<% end %>

Lastly, we’ll modify the default template to include a navigation bar at the top and flash messages for notice and alert from controllers:

<!-- Replace the contents of the <body> tag in app/views/layouts/application.html.erb with the following -->

    <nav class="navbar navbar-dark bg-dark">
      <a class="navbar-brand" href="/">
        <span class="logo d-inline-block align-top"></span>
        UnifyID PushAuth Sample
    <% if flash[:notice] %>
      <div class="alert alert-primary alert-dismissible fade show" role="alert">
        <%= flash[:notice] %>
        <button type="button" class="close" data-dismiss="alert" aria-label="Close">
          <span aria-hidden="true">×</span>
    <% end %>
    <% if flash[:alert] %>
      <div class="alert alert-danger alert-dismissible fade show" role="alert">
        <%= flash[:alert] %>
        <button type="button" class="close" data-dismiss="alert" aria-label="Close">
          <span aria-hidden="true">×</span>
    <% end %>

    <main role="main" class="container">
      <div class="main-content">
        <%= yield %>


We can add styling to our website by simply adding bootstrap. The views we created above already use class names that are recognized by bootstrap.

First, add bootstrap and some of its dependencies.

$ yarn add bootstrap jquery popper.js

Then, add the following to the end of app/javascript/packs/application.js:

import 'bootstrap'
import 'stylesheets/application.scss'

Next, make a file called app/javascript/stylesheets/application.scss and add this:

@import "~bootstrap/scss/bootstrap";

Optionally, you may add your own custom CSS files as well. See an example in our sample code.

At this point, you should be able to run rails server and navigate to http://localhost:3000 to interact with the basic authentication server! You can create sample users as follows:

$ bundle exec rails console
> User.create(:username => "<your_username>", :password => "<your_password>").save
> exit

Step 2 – Integrate with UnifyID PushAuth™ APIs

Now that we have a website with a simple username/password authentication, let’s incorporate UnifyID PushAuth™ APIs to further enhance security.

Interface to PushAuth™ APIs

First, let’s tell Rails about your UnifyID API key.

Run rails credentials:edit and add the following

  server_api_key: <Your UnifyID API Key created from dashboard>

Next, add the following to config/application.rb, after the config.load_defaults line:

config.x.pushauth.base_uri = ""

Let’s also add the httparty gem to easily make HTTP/S requests. To do this, add the following to your Gemfile and run bundle install:

gem 'httparty', '~> 0.18.0'

Now, we will make a file called app/services/push_auth.rb which contains the interface for our Rails app to interact with the PushAuth™ APIs:

  • create_session method calls POST /v1/push/sessions to initiate PushAuth™ session (API doc).
  • get_session_status method calls GET /v1/push/sessions/{id} to retrieve the status of PushAuth™ session (API doc).
# app/services/push_auth.rb

class PushAuth
  include HTTParty
  base_uri Rails.configuration.x.pushauth.base_uri

  @@options = {
    headers: {
      "Content-Type": "application/json",
      "X-API-Key": Rails.application.credentials.unifyid[:server_api_key]

  def self.create_session(user_id, notification_title, notification_body)
    body = {
      "user" => user_id,
      "notification" => {
        "title" => notification_title,
        "body" => notification_body
    post("/v1/push/sessions", @@options.merge({body: body.to_json}))

  def self.get_session_status(api_id)
    get("/v1/push/sessions/#{api_id}", @@options)

Controller Logic Modification

Now, we will modify the login flow to incorporate PushAuth™ as the second factor authentication. The new login flow will consist of the following:

  1. The client submits the username and password via a POST request to /login (sessions#create)
  2. The controller validates that the user exists and the password matches. If not, it displays an error message.
  3. Upon successful username/password authentication, the controller creates a PushAuth™ session and redirects to GET /mfa (sessions#init_mfa)
  4. The Javascript in /mfa page repeatedly queries GET /mfa/check (sessions#check_mfa), which checks the PushAuth™ session status until the session status is no longer pending.
  5. Upon receiving a non-pending session status, the client submits a request to PATCH /mfa/finalize (sessions#finalize_mfa) that completes the login process.

First, let’s replace the create action in app/controllers/sessions_controller.rb:

  def create
    @user = User.find_by("lower(username) = ?", params[:username].downcase)
    if @user && @user.authenticate(params[:password])
      session[:pre_mfa_user_id] =

      pushauth_title = "Authenticate with #{Rails.application.class.module_parent.to_s}?"
      pushauth_body = "Login request from #{request.remote_ip}"

      response = PushAuth.create_session(@user.username, pushauth_title, pushauth_body)

      session[:pushauth_id] = response["id"]

      redirect_to mfa_path
      redirect_to login_path, alert: "Sorry, that didn't work."

Next, let’s also add check_mfa and finalize_mfa actions in this controller:

  def check_mfa
    status = PushAuth.get_session_status(session[:pushauth_id])["status"]

    render plain: status

  def finalize_mfa
    case PushAuth.get_session_status(session[:pushauth_id])["status"]
    when "accepted"
      session[:user_id] = session[:pre_mfa_user_id]
      session[:pushauth_id] = nil
      session[:pre_mfa_user_id] = nil
      flash.notice = "Successfully logged in!"
    when "rejected"
      session[:pre_mfa_user_id] = nil
      flash.alert = "Your request was denied."

We also want to make sure that only users who completed the password authentication are able to access actions for the PushAuth™ authentication. Thus, within sessions_controller we will add:

# app/controllers/sessions_controller.rb

# Add this just under the skip_before_action line
  before_action :semi_authorized!, only: [:init_mfa, :check_mfa, :finalize_mfa]

# And add this after action methods
  def semi_authorized
    session[:pre_mfa_user_id] && session[:pushauth_id]

  def unauthorized
    redirect_to login_path, alert: "You are not authorized to view this page."

  def semi_authorized!
    unauthorized unless semi_authorized


Now, we need a page that uses AJAX to determine whether the PushAuth™ request has been completed.

First, let’s add a line in our application template that allows us to add content inside the <head> tag.
Add this to app/views/layouts/application.html.erb, right before the </head> tag:

<%= yield :head %>

Next, let’s add the Javascript code we want to run on the init_mfa page:

// app/javascript/packs/init_mfa.js

import Rails from "@rails/ujs";
let check_status = window.setInterval(function() {
    type: "GET",
    url: "/mfa/check",
    success: function(r) {
      if (r !== "sent") {
          type: "PATCH",
          url: "/mfa/finalize",
          success: function() {
            window.location.href = "/";
          error: function() {
            console.log("Promoting PushAuth status failed.");
    error: function() {
      console.log("Checking for PushAuth status failed.");
}, 2000);

This will poll /mfa/check every 2 seconds, until the Rails app reports that the PushAuth™ request has been accepted, rejected, or expired. At this point, the browser will ask the Rails app to complete the login process by submitting a /mfa/finalize request.

Now, let’s add a view file for init_mfa that includes the Javascript above.

<!-- app/views/sessions/init_mfa.html.erb -->

<% content_for :head do %>
  <%= javascript_pack_tag 'init_mfa' %>
<% end %>

<div class="spinner-border" role="status" ></div>

Waiting for a response to the push notification...

Finally, we will add new mfa routes.

# Add these to config/routes.rb

  get "mfa", to: "sessions#init_mfa"

  get "mfa/check", to: "sessions#check_mfa"

  patch "mfa/finalize", to: "sessions#finalize_mfa"

Congratulations! We have now integrated UnifyID’s PushAuth™. The final result should function just like the pushauth-sample-server project, which we introduced in our How to Implement PushAuth™: Web Server post. Please reach out to us if you have any questions, comments or suggestions, and feel free to share this post.

How to Implement PushAuth™: Android Mobile App

This post is part of the Power of PushAuth™ blog series. The first post of the series was a comprehensive guide to push authentication. The next three posts of the series comprise an end-to-end sample implementation of PushAuth in a simple user login flow. The tutorial breakdown is as follows:

  1. Web Server tutorial
  2. iOS Mobile App tutorial
  3. Android Mobile App tutorial (this post)

The tutorial in this post builds on the web server from the first tutorial. With your web server set up and running, you now need a mobile app to receive and respond to notifications. This post will help you build the Android mobile app to do so; then you will be able to leverage the power of PushAuth for login requests!


To follow this tutorial, you will need:

  • An Android device running Android 7.0 or higher
  • A computer with Android Studio 4.0 installed
  • JDK 8 installed (we recommend using jabba)

Step 1 : Cloning the Project

The sample Android mobile app code for this project is provided in the pushauth-sample-app-android GitHub repository. Clone this repo to your local machine:

$ git clone

Open Android Studio, select “Open an existing Android Studio project”, and select the directory of the cloned repository. It should look something like this:

Step 2: Set up Firebase Cloud Messaging (FCM)

Firebase Cloud Messaging (FCM) is the platform used to send notifications to Android devices. You will first need to set up Firebase in your app by following the instructions at After doing this, ensure that a google-services.json file is present under the app/ directory of the project in Android Studio.

Next, navigate to the Firebase project settings of your app in your browser and select the “Cloud Messaging” tab. The token labeled “Server key” is what you will need to provide to UnifyID in the next section, so copy that value.

Step 3: Providing Push Credentials to UnifyID

Now you have the Firebase Cloud Messaging (FCM) server key copied, you will provide it to UnifyID so that PushAuth can send push notifications to the sample app on your phone. You’ll provide this value in your project’s dashboard. Follow the instructions in the Developer Portal docs to do so. After you’ve done this, your project dashboard will indicate they are successfully uploaded:

Step 4: Building the Project

Now, back to Android Studio. Make sure that your Android device is plugged in to your computer, has developer tools and USB debugging enabled, and is available in the top center of Android Studio. Also make sure that the google-services.json file is located under the app/ directory of the project.

With everything set up, click the green triangle or press Control+R to run the app. The following screen should appear on your device:

Step 5: Mobile App Settings

You now have all the values necessary for configuration! Tap the gear icon in the top right corner of the sample app’s Configuration screen. For SDK key, enter your UnifyID project’s SDK key value from the Dashboard. The User string should be the same value that you used when creating a user in the web server tutorial, e.g. “Morgan”. If these values do not match, you will not be able to successfully respond to push notifications in the login flow.

After setting those values and clicking “Confirm”, the app is ready to receive your PushAuth login requests! The app will remain on the “Waiting for PushAuth requests” page until it receives a PushAuth authentication request.

Now you can go through the full login flow by entering your username and password on the login page, respond to the notification received by this app on your phone, and be successfully logged into the website.

That’s it! Now you have a simple login flow that integrates PushAuth. Stay tuned for the rest of the posts in the series, make sure to share this post and reach out to us if you have any questions, comments or suggestions!

How to Implement PushAuth™: iOS Mobile App

This post is part of the Power of PushAuth™ blog series. The first post of the series was a comprehensive guide to push authentication. The next three posts of the series comprise an end-to-end sample implementation of PushAuth in a simple user login flow. The tutorial breakdown is as follows:

  1. Web Server tutorial
  2. iOS Mobile App tutorial (this post)
  3. Android Mobile App tutorial

The tutorial in this post builds on the web server from the first tutorial. With your web server set up and running, you now need a mobile app to receive and respond to push notifications. This post will help you build the iOS mobile app to do so; then you will be able to leverage the power of PushAuth for login requests!


To follow this tutorial, you will need:

Step 1: Cloning the Project

The pushauth-sample-app-ios GitHub repository contains the sample iOS mobile app code for this project. Clone the repository to your local machine and open the PushAuthSample.xcworkspace file in Xcode.

$ git clone

Step 2: Setting Up and Running the Project

  1. In the top left section of your Xcode window, set the active scheme to PushAuthSample.
  2. Plug your phone into your computer. Your phone’s name will appear as the chosen device next to the active scheme.
  3. Navigate to the “Signing & Capabilities” section of the Xcode project settings.
  4. Check the boxes next to “Automatically manage signing” in the “Signing (Debug)” and “Signing (Release)” sections. This will simplify setup and merge the two into a single “Signing” section.
  5. Choose the “Team” value to match your Apple Developer account.
  6. Set the “Bundle Identifier” to something unique; this value will be used in the next step of the tutorial when you create the Identifier through the Apple Developer site.

After following these six steps, your settings should closely resemble the screenshot above from Xcode. Once everything is set up properly and with your phone still connected to your computer, run the project (Product > Run or Command-R). This screen will show up on your phone:

Step 3: Create an Apple Bundle Identifier

This step requires you to an Apple Developer Program Role with adequate permissions. The role-permissions are listed here.

Navigate to the Identifiers tab on the Certificates, Identifiers & Profiles page of the Apple Developer site. You’ll need to add a new identifier that matches the Bundle Identifier value you set in Xcode in step 6 above. Click the plus symbol next to the title at the top of the page; if you don’t see this symbol, you likely don’t have adequate permissions. Follow these instructions for the subsequent pages:

  1. Register a new identifier page: Keep the default selection (App IDs) and click “Continue”.
  2. Select a type page: Keep the default selection (App) and click “Continue”.
  3. Register an App ID page:
    • Description: enter an appropriate description for this project, e.g. “PushAuth Project”. This value will be displayed as the “Name” on the Identifiers page.
    • Bundle ID: Keep the selection on “Explicit” and enter the exact same value you put as the Bundle Identifier in the Xcode Signing & Capabilities page earlier.
    • Enable Push Notification capability by scrolling down on the page and selecting the checkbox next to “Push Notifications”.
    • Click “Continue”, verify everything was entered correctly, and click “Register”.

Now that you have created an identifier for this project, you can create a push notification certificate associated with this identifier.

Step 4: Create a Push Notification Certificate

UnifyID requires the APNs certificate in *.p12 format to send PushAuth requests to the app. This can be done from the same Identifiers page of the Apple Developer site that you were on in Step 3.

  1. Click on the name of the identifier you just created, e.g. “PushAuth Project”.
  2. Scroll down to the “Push Notifications” row and click on the “Configure” box. Next to this box you should see “Certificates (0)” since you haven’t yet created a certificate associated with this identifier.
  1. In the Apple Push Notification service SSL Certificates pop-up window, click on the “Create Certificate” box under “Production SSL Certificate” then click “Done”.
  1. At this point, you need to create a Certificate Signing Request (CSR) file from your Mac. Click “Learn More” and follow those instructions for doing so. Then upload that file and continue.
  1. Now that you have created a certificate, you must download it locally to export it to *.p12. Click “Download”.
  1. This will prompt you to add the certificate to Keychain Access. Choose a Keychain, e.g. “login”, to add the certificate to and click “Add”.
  1. Then find that certificate in Keychain Access. It may be useful to select the “Certificates” category and utilize the search bar to find the certificate you just added.
  1. Once you have located your certificate, right-click on it and click the option to export the certificate:
  1. Specify a name for the *.p12 file and a location to save it. Make sure the file format is set to “Personal Information Exchange (.p12)” then click “Save”.
  1. You will be prompted to password-protect the exported *.p12 file. Choose to export it without a password; simply click “OK”.

Now you have successfully created a APNs certificate in *.p12 format! This will be used by UnifyID and needs to be uploaded to your project settings through the dashboard.

Step 5: Providing Push Credentials to UnifyID

Now you have an Apple Bundle Identifier and an APNs push certificate. It’s time to provide your push credentials to UnifyID so that PushAuth can send push notifications to the sample app on your phone. Check out the Developer Portal docs here, or follow along the instructions below.

  1. Navigate to the “Push Credentials” section of your project on the Developer Dashboard.
  2. Click on “Choose File” and select the *.p12 file you generated in Step 4 of this tutorial.
  3. Choose the “Development/Sandbox APNs server” option for now since we are sending push notifications to an app that runs directly from Xcode. Later on, choose “Production APNs server” when you need to send PushAuth requests to apps distributed through the App Store or through ad-hoc means.
  4. Click “Add” to complete the upload.

Once the push credentials are successfully uploaded to your project settings, you will see the push credential information displayed:

If you find yourself needing to change the push credentials used for the project, simply click “Edit” and go through the same upload steps with the new credentials.

Step 6: Mobile App Settings

You now have all the values necessary for configuration! Open the sample app on your phone and tap the gear icon in the top right of the Configuration screen. For SDK key, enter your UnifyID project’s SDK key value from the Dashboard. The User string should be the same value that you used when creating a user in the web server tutorial, e.g. “Morgan”. If these values do not match, you will not be able to successfully respond to push notifications in the login flow.

Once you set those two values, you must allow push notifications for the app, then the app is ready to receive your PushAuth login requests!

Now you can go through the full login flow by entering your username and password on the login page, respond to the push notification received by this app on your phone, and be successfully logged in to the website.

That’s it! You now have a simple login flow that integrates PushAuth. The next post provides a tutorial for building the Android sample PushAuth mobile app. Stay tuned for the rests of the posts in the series and, as always, please share this post and reach out to us with questions, comments or suggestions.

How to Implement PushAuth™: Web Server

Welcome back to the Power of PushAuth™ blog series! The first post provided a comprehensive guide to push authentication — check it out here if you missed it. The next three posts are tutorials offering an end-to-end implementation of PushAuth™ in a simple user login flow and will be broken down as follows:

  1. Web Server tutorial (this post)
  2. iOS Mobile App tutorial
  3. Android Mobile App tutorial

The first tutorial (this post) covers a Ruby on Rails backend that provides a basic user login authentication flow with PushAuth integrated. The second and third tutorials will be instructions on how to run sample iOS and Android apps, respectively. These will be the apps that receive and respond to push notifications initiated by the login process.

By the end of these three tutorials, you will have a website where a registered user can log in with their username and password, receive a push notification on their phone, accept the login request via the push notification, and subsequently be logged in on the website. This flow is shown in the video below.

This is a very simplified version of a real-world application and login flow. You might remember some of the security issues that can be present with push authentication from the previous post, such as trusted device registration, fallback resources, or access revocation. This tutorial does not include solutions for those or user sign-up. Future posts in the series will provide extensions of this simple flow to tackle some of those issues.

Alright, let’s get started!


To follow this tutorial, you will need:

Step 1: UnifyID Account, Project, and Keys

A UnifyID project will grant you access to UnifyID’s services. In order to create a project, you’ll need to first create a UnifyID account. Once you have an account and project, go to the Developer Dashboard to create an API key and SDK key. Make sure to copy the API key value somewhere safe – you won’t be able to access it later.

This tutorial is using PushAuth project as the UnifyID project name. You can see the configured API and SDK keys on the dashboard view above.

Step 2: Cloning the Project and Installing Dependencies

The pushauth-sample-server GitHub repository contains the code for this project. Clone the repository, navigate into it, install the project dependencies that are listed in the Gemfile, and ensure your Yarn packages are up-to-date:

$ git clone
$ cd pushauth-sample-server
$ bundle install
$ yarn install --check-files

Feel free to poke around the code if you’d like to get a better understanding of what’s going on under the hood. This tutorial won’t go into those details, but a future post in this series will.

Step 3: DB Setup and Running the Server

Now, initialize the database:

$ bundle exec rails db:migrate

Once the database has been initialized you can create users. To create a user, do the following (replacing <your_username> and <your_password> with the values you intend to use for username and password):

$ rails console
> User.create(:username => "<your_username>", :password => "<your_password>").save
> exit

Step 4: Server API Key Storage

This step requires the server API key value you copied in Step 1.

$ EDITOR=vim rails credentials:edit

The above command will open the credentials file in vim. You can replace vim with the name of whichever executable you are most comfortable (atom, sublime, etc.). This will decrypt and open the credentials file for editing, at which point you should add the following entry:

  server_api_key: <your_key_goes_here>

After saving and closing, the credentials file will be re-encrypted and your server API key value will be stored.

Step 5: Running the Server

Now you are able to run the server:

$ bundle exec rails server

Finally, connect to the server by opening http://localhost:3000/ in your browser. This will bring you to the landing page, where you can then navigate to the login page and enter your username and password from above in Step 3:

This brings you to the end of the web server tutorial. After entering the username and password on the login page, you can see that the server is polling for the push notification response before allowing or denying access to the website. Without a way to receive or respond to push notifications, you cannot successfully log in. Stay tuned for the next couple posts of this tutorial installment to complete the flow:

Thanks for following along! Please reach out to us if you have any questions, comments or suggestions, and feel free to share this post.

The Power of PushAuth™

Welcome to the first post in our series on PushAuth™, UnifyID’s push authentication service. This series, outlined below, will help you leverage push authentication to increase the security of your authorization flow.

PushAuth™ Blog Series Content

  1. Comprehensive guide to push authentication: what it is, how it works, and pros and cons of using it.
  2. An end-to-end tutorial of implementing PushAuth™ in a simple user login flow.
    1. How to Implement PushAuth™: Web Server tutorial
    2. How to Implement PushAuth™: iOS Mobile App tutorial
    3. How to Implement PushAuth™: Android Mobile App tutorial
  3. Building a Web Application with PushAuth™: Technical deep-dive into the details of building a web application with PushAuth™ integrated.
  4. The Power of Trusted Registration: A more secure extension of the simple user sign-up flow that includes user registration and trusted device registration.
  5. Integrating Trusted Registration for PushAuth™: Technical deep-dive into the details of extending the project with trusted device registration.

Push authentication is one of the most seamless and secure methods of multi-factor authentication. We want to help you understand its importance and the power it has to upgrade your security!

Table Stakes

Let’s clear up two terms that are critical to understanding what PushAuth is solving:

Authorization = allowing you access to a system

Authentication = verifying your identity

There is a great Medium article that describes those differences in more depth. You could have an authorization flow that requires no authentication, letting all users in without proving anything (please don’t do this). On the other hand, you could have an authorization flow that makes users jump through countless hoops to try to make 100% sure the true user is accessing their account. The magic is in striking a balance between these extremes, ensuring a secure authorization process without excessive user annoyance.

One more term to define before moving forward:

Multi-factor authentication = an authentication method that requires two or more pieces of proof before granting a user access to resources

Multi-factor authentication (MFA) is sometimes referred to as two-factor authentication (2FA). Here is a page on MFA basics provided by NIST.

Why use multi-factor authentication?

Before jumping into push authentication, let’s explain MFA. The three basic authentication mechanisms are:

  1. Knowledge: something you know (password, security question answers, PIN)
  2. Possession: something you have (access badge, ATM card, smartphone, hard token)
  3. Biometric: something you are (fingerprint, face, gait, voice)

As defined above, MFA uses two or more of these authentication mechanisms. There are many security benefits to using MFA. The primary benefit is increased confidence in an authorization flow. This stronger assertion on the user’s identity increases the application’s security. Using MFA mitigates the dangers of poor security habits many users have with passwords, such as writing them down, making them simple or easily-guessed, and reusing them across platforms.

Push authentication is one method of accomplishing MFA. This method usually requires a user to download an app on their phone and register it with their account. The mobile app receives push notifications during the login flow. In doing so, the user establishes two authentication mechanisms: knowledge of their username/password combination and possession of their registered device. Here is an example of using push authentication in a login flow:

A user logs in to a web application by entering their username and password. Upon clicking the button to log in, the server sends a push notification to the app (which the user has already downloaded and registered). The user unlocks their phone and authorizes the request by clicking “Accept” on the notification. The server receives this approved response and proceeds to log the user in to the web app. If the user instead clicks “Deny,” the authentication step fails and the user would not gain access to the web app.

Other types of MFA include SMS codes, phone calls, email codes or magic links, authenticator app verification codes, and hardware tokens. This PCMag article does a good job of aggregating different ways well-known companies offer MFA. In the next section we discuss the advantages push authentication has over other methods.

Why choose push authentication?

In a nutshell, push authentication increases security in a cost-effective manner without affecting usability. This section lists some of the aspects specific to push authentication that make it superior to other methods of MFA.

MFA methodFree tierCost per million
Mobile Push Notifications1 million$0.50
  • Convenient and easy to use. We can assume that users who have smartphones are comfortable with using apps and interacting with notifications. This makes using push authentication easy for them, since there is nothing else they need to learn to use or get used to the method. Push notifications are much easier to respond to – there is no typing, clicking links, or copying codes while trying to beat the timer. Authentication happens with a simple and speedy tap on their screen.
  • Secure. The push authentication mobile app is installed securely on users’ devices, so there is no reliability on a user’s accounts with external companies. This out-of-band communication can’t be intercepted at the point of password entry, and it is encrypted from end to end between the application and the secured push authentication provider. The many insecurities of the SMS method led to the downfall of its prominence in this space.
  • Fast. Since authentication requests are sent in real time via notifications, a user can become aware of and deny fraudulent requests when they happen and promptly take action. Unlike some methods of MFA, the user must unlock their device before responding to the request. However, this is a level of friction that users are already familiar with on a day-to-day (or, more realistically, minute-to-minute) basis. For devices with TouchID or FaceID, this process is almost frictionless. This even increases the security by preventing unhindered access to authentication by an attacker.
  • No hardware to manage. Unlike with hardware tokens, push authentication utilizes users’ existing phones. Since most people consider their phone an extension of their body, this also means the hardware is unlikely to be easily or frequently misplaced. When phones are lost or broken, the responsibility is on the user, rather than the service provider, to obtain a replacement.
  • No over-the-shoulder copy-ability. Codes and magic links sent via SMS/email and codes generated in an authenticator app can all be intercepted and used to log in as an attacker. Push notifications don’t contain anything that can be copied or reproduced.

Is push authentication perfect?

Unsurprisingly, like most things, no. On a base level, push authentication requires that every user has a fully-functional smartphone. Without a smartphone, they can’t have the mobile app (and the provider needs to have an application). Without internet connection, their device can’t receive push notifications through the mobile app. In the specific cases of a user’s phone being lost, stolen, or otherwise not in their possession, push authentication will fail. Even if the device is in their possession but out of battery, waterlogged, or otherwise not functional, the same assertion applies. For the sake of argument, let’s assume that none of these scenarios are issues. Push authentication is still not “perfect.”

There are some valid security concerns surrounding the use of push authentication as a method for MFA. Smartphones themselves, where the authentication bit happens, are vulnerable to attacks and viruses. There’s also the issue of trusting a device to be associated with its true user during registration, as well as not allowing attackers to register devices under the true user’s account. Even with a trusted device, any pre-registered device is a weak point for attacker entry. You can’t ensure that users have their devices protected via a locking mechanism. If they don’t have access into their phone locked, then it’s pretty easy for an attacker to accept a notification on the user’s behalf. Finally, it’s completely possible that a user accidentally approves a fraudulent request on their device without realizing it, or realizing too late.

However, there are solutions to these problems. In the cases of a temporarily out-of-possession device, you can provide fallback resources (one-time passcodes, email or SMS delivery, security questions, etc.) as a workaround for that authentication attempt. If the device is permanently out of possession, such as a ruined or stolen phone, you can provide a method of revoking access from the old device and allowing users to self-sign up and provision the app on a new mobile device. If an attacker gains physical access to the device before access is revoked, it’s likely that the user will have yet another authentication barrier in the form of a passcode, TouchID, or FaceID. While this can be attacked as well, it still raises the bar for entry before access is revoked. With regards to users accepting fraudulent requests on their device, the push notification prompt could be extended to include a unique identifier that is expected to match a value on the web login page. The existence of this would set the expectation that a user is to confirm the value before accepting the request.

However, there’s only so much you can do as a developer. People will still make mistakes, and hackers will still gain access. The main point here is that these are things you, as a developer, should be aware of and address. All things considered – push authentication sits in a pretty great place security-wise, is incredibly low friction, and (perhaps most importantly) incredibly cost-effective. Keep an eye out for our next post of the series, which will walk you through using our open-source project to implement PushAuth yourself!

New Study Shows Consumers Desire a World Beyond Passwords and Biometrics

With the current password-based user authentication paradigm so loathed and cumbersome, a new study surveyed 1,000 consumers in the United States to better understand their perceptions of convenience, security and privacy around authentication.

Of those surveyed, nearly three-quarters of respondents said it was “difficult” to keep track of their passwords and 82 percent never again wanted to use passwords.

Other security solutions, such as facial identification, also have challenges, according to the survey. For instance, half of Millennials and over two-thirds of both Gen X and Baby Boomers are reluctant to use facial scans due to concerns about privacy. However, over 60 percent of those surveyed would use implicit authentication for personal identification given its perceived convenience. Biometric authentication, such as facial scanning or fingerprints, is also easy to copy and is extremely hard to change once compromised.

Users of iPhones are much more inclined to use biometrics, with 74 percent of those respondents using biometrics to unlock their smartphones. On the other hand, only 55 percent of Android users surveyed use biometrics to unlock their smartphones.

Surprisingly, almost half of all respondents use a handwritten piece of paper to keep track of all their passwords, with one-third of all respondents never changing their passwords unless prompted to.

Other interesting facts include:

  • Nearly half (46 percent) of all respondents use the same password for all of their logins
  • 60 percent of all respondents believe it is the app maker’s responsibility to keep their information safe on their smartphone
  • Just over one-third (34 percent) of all respondents’ accounts had, in the past, been hacked or had their passwords stolen
  • Almost 83 percent of Generation Z use biometric authentication to unlock their smartphone, whereas only 53 percent of Baby Boomers use biometrics
  • Over 91 percent of Generation Z stay logged into their social media accounts, citing convenience as the reason

Vulnerability of deep learning-based gait biometric recognition to adversarial perturbations

PDF of full paper: Vulnerability of deep learning-based gait biometric recognition to adversarial perturbations
Full-size poster image: Vulnerability of deep learning-based gait biometric recognition to adversarial perturbations

[This paper was presented on July 21, 2017 at The First International Workshop on The Bright and Dark Sides of Computer Vision: Challenges and Opportunities for Privacy and Security (CV-COPS 2017), in conjunction with the 2017 IEEE Conference on Computer Vision and Pattern Recognition.]

Vinay Uday Prabhu and John Whaley, UnifyID, San Francisco, CA 94107


In this paper, we would like to draw attention towards the vulnerability of the motion sensor-based gait biometric in deep learning-based implicit authentication solutions, when attacked with adversarial perturbations, obtained via the simple fast-gradient sign method. We also showcase the improvement expected by incorporating these synthetically-generated adversarial samples into the training data.


In recent times, password entry-based user-authentication methods have increasingly drawn the ire of the security community [1], especially when it comes to its prevalence in the world of mobile telephony. Researchers [1] recently showcased that creating passwords on mobile devices not only takes significantly more time, but it is also more error prone, frustrating, and, worst of all, the created passwords were inherently weaker. One of the promising solutions that has emerged entails implicit authentication [2] of users based on behavioral patterns that are sensed without the active participation of the user. In this domain of implicit authentication, measurement of gait-cycle [3] signatures, mined using the on-phone Inertial Measurement Unit – MicroElectroMechanical Systems (IMU-MEMS) sensors, such as accelerometers and gyroscopes, has emerged as an extremely promising passive biometric [4, 5, 6]. As stated in [7, 5], gait patterns can not only be collected passively, at a distance, and unobtrusively (unlike iris, face, fingerprint, or palm veins), they are also extremely difficult to replicate due to their dynamic nature.

Inspired by the immense success that Deep Learning (DL) has enjoyed in recent times across disparate domains, such as speech recognition, visual object recognition, and object detection [8], researchers in the field of gait-based implicit authentication are increasingly embracing DL-based machine-learning solutions [4, 5, 6, 9], thus replacing the more traditional hand-crafted-feature- engineering-driven shallow machine-learning approaches [10]. Besides circumventing the oft-contentious process of hand-engineering the features, these DL-based approaches are also more robust to noise [8], which bodes well for the implicit-authentication solutions that will be deployed on mainstream commercial hardware. As evinced in [4, 5], these classifiers have already attained extremely high accuracy (∼96%), when trained under the k-class supervised classification framework (where k pertains to the number of individuals). While these impressive numbers give the impression that gait-based deep implicit authentication is ripe for immediate commercial implementation, we would like to draw the attention of the community towards a crucial shortcoming. In 2014, Szegedy et al. [11] discovered that, quite like shallow machine-learning models, the state-of- the-art deep neural networks were vulnerable to adversarial examples that can be synthetically generated by strategically introducing small perturbations that make the resultant adversarial input example only slightly different from correctly classified examples drawn from the data distribution, but at the same time resulting in a potentially controlled misclassification. To make things worse, a large plethora of models with disparate architectures, trained on different subsets of the training data, have been found to misclassify the same adversarial example, uncovering the presence of fundamental blind spots in our DL frameworks. After this discovery, several works have emerged ([12, 13]), addressing both means of defence against adversarial examples, as well as novel attacks. Recently, the cleverhans software library [13] was released. It provides standardized reference implementations of adversarial example-construction techniques and adversarial training, thereby facilitating rapid development of machine-learning models, robust to adversarial attacks, as well as providing standardized benchmarks of model performance in the adversarial setting explained above. In this paper, we focus on harnessing the simplest of all adversarial attack methods, i.e. the fast gradient sign method (FGSM) to attack the IDNet deep convolutional neural network (DCNN)-based gait classifier introduced in [4]. Our main contributions are as follows: 1: This is, to the best of our knowledge, the first paper that introduces deep adversarial attacks into this non-computer vision setting, specifically, the gait-driven implicit-authentication domain. In doing so, we hope to draw the attention of the community towards this crucial issue in the hope that further publications will incorporate adversarial training as a default part of their training pipelines. 2: One of the enduring images that is widely circulated in adversarial training literature is that of the panda+nematode = gibbon adversarial-attack example on GoogleNet in [14], which was instrumental in vividly showcasing the potency of the blind spot. In this paper, we do the same with accelerometric data to illustrate how a small and seemingly imperceptible perturbation to the original signal can cause the DCNN to make a completely wrong inference with high probability. 3: We empirically characterize the degradation of classification accuracy, when subjected to an FGSM attack, and also highlight the improvement in the same, upon introducing adversarial training. 4: Lastly, we have open-sourced the code here.

Figure 1. Variation in the probability of correct classification (37 classes) with and without adversarial training for varying ε.

Figure 2. The true accelerometer amplitude signal and its adversarial counterpart for ε = 0.4.

2. Methodology and Results

In this paper, we focus on the DCNN-based IDNet [4] framework, which entails harnessing low-pass-filtered tri-axial accelerometer and gyroscope readings (plus the sensor-specific magnitude signals), to, firstly, extract the gait template, of dimension 8 × 200, which is then used to train a DCNN in a supervised-classification setting. In the original paper, the model identified users in real time by using the DCNN as a deep-feature extractor and further training an outlier detector (one-class support vector machine-SVM), whose individual gait-wise outputs were finally combined into a Wald’s probability-ratio-test-based framework. Here, we focus on the trained IDNet-DCNN and characterize its performance in the adversarial-training regime. To this end, we harness the FGSM introduced in [14], where the adversarial example, x ̃, for a given input sample, x, is generated by: x ̃ = x + ε sign (∇xJ (θ, x)), where θ represents the parameter vector of the DCNN, J (θ, x) is the cost function used to train the DCNN, and ∇x () is the gradient function.

As seen, this method is parametrized by ε, which controls the magnitude of the inflicted perturbations. Fig. 2 showcases the true and adversarial gait-cycle signals for the accelerometer magnitude signal (given by amag(t) = √(a2x (t) + a2y (t) + a2z (t))) for ε = 0.4. Fig. 1 captures the drop in the probability of correct classification (37 classes) with increasing ε. First, we see that in the absence of any adversarial example, we were able to get about 96% ac- curacy on a 37 class classification problem, which is very close to what is claimed in [4]. However, with even mild perturbations (ε = 0.4), we see a sharp decrease of nearly 40% in accuracy. Fig. 1 also captures the effect of including the synthetically generated adversarial examples in this scenario. We see that, for ε = 0.4, we manage to achieve about 82% accuracy, which is a vast improvement of ∼ 25%.

3. Future Work

This brief paper is part of an ongoing research endeavor. We are currently currently extending this work to other adversarial-attack approaches, such as Jacobian-based Saliency-Map Approach (JSMA) and Black-Box-Attack (BBA) approach [15]. We are also investigating the effect of these attacks within the deep-feature-extraction+SVM approach of [4], and we are comparing other architectures, such as [6] and [5].

[1]  W.Melicher, D.Kurilova, S.M.Segreti, P.Kalvani, R.Shay, B. Ur, L. Bauer, N. Christin, L. F. Cranor, and M. L. Mazurek, “Usability and security of text passwords on mobile devices,” in Proceedings of the 2016 CHI Conference on Human Factors in Computing Systems, pp. 527–539, ACM, 2016. 1
[2]  E. Shi, Y. Niu, M. Jakobsson, and R. Chow, “Implicit authentication through learning user behavior,” in International Conference on Information Security, pp. 99–113, Springer, 2010. 1
[3]  J. Perry, J. R. Davids, et al., “Gait analysis: normal and pathological function.,” Journal of Pediatric Orthopaedics, vol. 12, no. 6, p. 815, 1992. 1
[4]  M. Gadaleta and M. Rossi, “Idnet: Smartphone-based gait recognition with convolutional neural networks,” arXiv preprint arXiv:1606.03238, 2016. 1, 2
[5]  Y. Zhao and S. Zhou, “Wearable device-based gait recognition using angle embedded gait dynamic images and a convolutional neural network,” Sensors, vol. 17, no. 3, p. 478, 2017. 1, 2
[6]  S. Yao, S. Hu, Y. Zhao, A. Zhang, and T. Abdelza- her, “Deepsense: A unified deep learning framework for time-series mobile sensing data processing,” arXiv preprint arXiv:1611.01942, 2016. 1, 2
[7]  S. Wang and J. Liu, Biometrics on mobile phone. INTECH Open Access Publisher, 2011. 1
[8]  Y. LeCun, Y. Bengio, and G. Hinton, “Deep learning,” Nature, vol. 521, no. 7553, pp. 436–444, 2015. 1
[9]  N. Neverova, C. Wolf, G. Lacey, L. Fridman, D. Chandra, B. Barbello, and G. Taylor, “Learning human identity from motion patterns,” IEEE Access, vol. 4, pp. 1810–1820, 2016. 1
[10]  C. Nickel, C. Busch, S. Rangarajan, and M. Mo ̈bius, “Using hidden markov models for accelerometer-based biometric gait recognition,” in Signal Processing and its Applications (CSPA), 2011 IEEE 7th International Colloquium on, pp. 58–63, IEEE, 2011. 1
[11]  C. Szegedy, W. Zaremba, I. Sutskever, J. Bruna, D. Erhan, I. Goodfellow, and R. Fergus, “Intriguing properties of neural networks,” arXiv preprint arXiv:1312.6199, 2013. 1
[12]  C. Szegedy, W. Liu, Y. Jia, P. Sermanet, S. Reed, D. Anguelov, D. Erhan, V. Vanhoucke, and A. Rabinovich, “Going deeper with convolutions,” in Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition, pp. 1–9, 2015. 1
[13]  N. Papernot, I. Goodfellow, R. Sheatsley, R. Feinman, and P. McDaniel, “cleverhans v1.0.0: an adversarial machine learning library,” arXiv preprint arXiv:1610.00768, 2016. 1
[14]  I. J. Goodfellow, J. Shlens, and C. Szegedy, “Explain- ing and harnessing adversarial examples,” arXiv preprint arXiv:1412.6572, 2014. 2
[15] N. Papernot, P. McDaniel, I. Goodfellow, S. Jha, Z. B. Celik, and A. Swami, “Practical black-box attacks against deep learning systems using adversarial examples,” arXiv preprint arXiv:1602.02697, 2016.