Leveraging An Old Security Method in Augmented Reality: A Thought Experiment

Introduction

It is common wisdom that the design of features for software should make the best use of the hardware. In the past few decades, we have seen this exemplified many times. The clearest of these examples is the changes in design that have come about with the popularity of mobile devices and touchscreens.

The shift from keyboard and mouse to touch-screens represents a shift from an indirect interface between user intention and device to a direct one. Whereas previously we manipulated an external tool to incite change on our screens, we can now interact by touching the elements of the user interface with our own hands. This method was so natural and so much more efficient than the traditional alternative that it quickly dominated the market. Despite the natural feeling of touch screens, there is a step further that we have all been watching in sci-fi movies, and which now seems more and more real. Suppose the human-machine interface escaped from the screen entirely, and we could interact with virtual tools as easily as the physical ones in front of us. That is the dream that Augmented Reality (AR) represents.

In this article, I want to discuss an interesting problem I recently faced while developing an AR solution. More specifically, I want to discuss a solution that I conceived of that I, unfortunately, did not have the time or budget to pursue, but which I feel would have been, at the very least, a novel approach to the problem.

The Problem

For a password to be secure, the prevailing wisdom (at the time of writing) is that it must be at least 10 characters long, and contain a variety of special characters, capital and lowercase letters, and numbers. We all encounter these rules on a regular basis, and I think it is fair to say that most people find themselves annoyed at the rules while designing a new password for each account they make. This annoyance is frequently expressed in the form of less than secure passwords as users attempt to game the system.

On the project that brought this post about we were aiming to meet HIPAA compliance, as it was intended for use in a medical space. Therefore, the need for security was high, and our wiggle room was tight. It often felt as if there was a sort of cold war being waged. Our security advisor understandably wanted the application to be as secure as possible. On the other hand, our product manager obviously wanted to make sure that user experience was preserved. Normally, these would not be opposing viewpoints, but the last issue was that they were not talking about an application with a traditional input method. They were trying to design for an AR experience.

Specifically, the AR aspect of this application was intended to be as hands-free as possible and depended on voice commands to initiate a button press. Thus, we arrive at the crux of the conflict. To be secure, a password needs to fit the criteria I outlined above. Unfortunately, due to the input method, entering a ten-character password is time-consuming and annoying. After a week or two of discussion, the team eventually compromised. The application would require an occasional entry of the ten-character password, and an entry of a six-digit numeric pin for regular entry into the application. That was the end of the debate for everyone else, but I could not let the issue go. I was sure that there must have been a better solution that could somehow make use of the unique abilities of the AR platform.

Tackling a New Problem with an Old Solution

While I was mulling the problem over in my head for a few days, I happened to be having a conversation with a coworker and the topic of phone screen lock methods came up. They were explaining that pattern locks are not very secure methods of locking your phone because it is easy for a passing observer to see your pattern from a distance. The combination of the two problems crashed together suddenly for me. Pattern locks are unreliable because others can easily see the pattern on the screen. Long passwords are annoying on our AR platform because keyboards do not lend themselves well to AR. Suppose you could have a pattern lock that exists in virtual space, invisible to anyone but the user of the locked device! You would solve two problems at once.

Imagine a user trying to access their AR tools. They have logged in with their full username and password previously and have set up a pattern lock for their account. When opening the interface, they are presented with a series of nodes floating in virtual space in front of them. In order to unlock the device, they can simply gaze at each node in sequence. To an observer, they simply appear to flick their gaze around in a few directions. The user of the AR headset can now access their services with a quick, memorized series of movements, as with the original pattern lock.

In fact, existence in a virtual space can remove some of the flaws with the original pattern lock. With the nature of augmented reality, there is no need for the nodes to be in that compact three-by-three pattern that fits so well onto rectangular phone and tablet screens. You could have more nodes in more patterns, making the password even more impossible to guess as an outside observer.

Closing Statements

I did not get to develop my virtual pattern lock for the AR project I was working on. Still, I can’t get the idea of it out of my head. Would it be secure? What would the user-experience be like? I will definitely be revisiting this idea when I have a chance, if only to satisfy my curiosity.

I can’t help but wonder if there are any other flawed ideas that might work better in virtual space than they ever did on our physical screens.

‍