Welcome to the first post in our series on PushAuth™, Prove’s push authentication service. This series, outlined below, will help you leverage push authentication to increase the security of your authorization flow.
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.
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!
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.
Before jumping into push authentication, let’s explain MFA. The three basic authentication mechanisms are:
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. In addition, 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 users to download an app on their phone and register it with their account. Then, 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 into 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.
In a nutshell, push authentication increases security in a cost-effective manner without affecting the usability. This section lists some of the aspects specific to push authentication that makes it superior to other methods of MFA.
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 (the provider needs to have an application). Without an 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. The same assertion applies even if the device is in their possession but out of battery, waterlogged, or otherwise not functional. 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. First, 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. Second, you can’t ensure that users have their devices protected via a locking mechanism. If they don’t have access to their phone locked, then it’s pretty easy for an attacker to accept a notification on the user’s behalf. Finally, it’s entirely possible that a user accidentally approves a fraudulent request on their device without realizing it or realizing it 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, the user will likely 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. Regarding users accepting fraudulent requests on their devices, 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!
To learn more about Prove’s identity solutions and how to accelerate revenue while mitigating fraud, schedule a demo today.
Join over 1,000 businesses that rely on Prove across multiple industries, including banking, FinTech, healthcare, insurance, and e-commerce. Contact us today.
Contact us to learn how leading companies are using Prove Pre-Fill to modernize the account creation process by shaving off clicks and keystrokes that kill conversion.
Get in touch to find out how we can help you identify your customers at every stage of their journey and offer them seamless and secure experiences.
Let our expert team guide you through our identity verification and authentication solutions. Select a date and time that works for you.
Find out how we can help you deliver seamless and secure customer experiences that comply with PSD2/SCA. Select a date and time that works for you.