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 on the website. Remember that the initial project required users to be created in the console. Only users whose username and password were inserted into the database in that manner were able to log in to the website and receive push notifications. Now users register on the website directly. Once a user signs up on 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 is 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 the 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:
- Web Server with trusted device registration
- iOS Sample App with trusted device registration
- Android Sample App with trusted device registration
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 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.
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, the 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:
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 this:
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 step 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 https://unify.id/contact-us/.
To learn about Prove’s identity solutions and how to accelerate revenue while mitigating fraud, schedule a demo today.
Keep reading
Developers know identity verification is an essential element of effective digital onboarding and the customer lifecycle. Choosing the right one can feel like navigating a maze of features and complexity.
In an age where our smartphones have become almost like extensions of ourselves, the identity assurance achieved through smartphone possession and data is a natural evolution.
Rodger Desai, CEO of Prove, a leading identity verification solution provider, offers a unique perspective on the rising fraud in the gig economy, advocating for robust digital identity verification as a key defense mechanism.
