Building an MFA User Authentication System (Enrollment Component Code) Using Images

Most interactive Internet applications require a user to first be “registered” in order to use the application and then further require the user to “log on” each time they wish to use the application. This process of first enrolling a user and then later recognizing that user to allow them access may be described as User Authentication. This article focuses on the code and processes used in the registration component of our Authur user authentication system.

Our demo Logon Portal allows users to access a web comic book builder application named Storybook, but the Portal itself can be employed in many situations where authentication is required to use a web application.

The Logon Portal Code Repository

The code base we describe here following is available on GitHub as a public repository at https://github.com/Bob-Wright/Authur-User-Registration-System. Comments, criticisms, and suggestions are always welcome!

The Logon Portal

The builder application is launched from a gallery of comic books that were created by the builder itself, and the first page of the application is the logon portal landing page shown here in these next two screenshots. This page is presented by Portal.php in the Storybook folder.

There are four logon option choices listed in our main dialog box, along with a basic explanation pop-up modal that describes each of the logon options available through the “LOGIN OPTIONS EXPLAINED” button.

Also included in the logon dialog box is an option to “Change Password” which is included here because a frequent reason for a user wanting to change their password is so that they may logon.

The last item in the dialog is a Sign Up button invitation to sign up as a user.

Sign Up

Selecting this Sign Up button will launch the signup.php program and we will be presented with the dialog in the following three screenshots. This dialog requests user data information that will be used to create a user profile database entry

In addition to obtaining the user name and email address information the dialog asks for a password entry, and in keeping with tradition we ask for a combination of alphanumeric characters in upper and lower case along with at least one symbol character. The intent of requiring these character parameters is obviously to make the password harder to guess. How well that works is moot.

Besides the username, email, and password entries the dialog also gathers certain data items about each user. These items do not nominally contain personally identifiable data but are instead contrived as to provide a short list of binary (yes/no) factors that we may later use in the validation process. So for example we might ask a particular user “Can you swim?” as a factor in identifying them.

After these data items are provided we may proceed by clicking the “Sign up” button at the screen bottom. This will result in the following screen display which informs us that a confirmation email has been sent to the user.

The email shown here next is then sent to the new user’s email address for verification.

All of the preceding sign up activity effectively registers a user in a complete functional email/password token-exchange logon system that supports the first three logon methods (Username/password, Magic Link, and One Time Password) shown in our initial Portal dialog.

The GateKeeper Image Selection

But the code gets more interesting from here as we continue generating an image based MFA logon token for our user’s registration. Clicking the “Verify my email” button in the email will result in this next browser screen shown below being opened by the GateKeeper.php program that lives in the Storybook/Portal folder. The GateKeeper program web page first informs the user that their Email has been successfully verified and continues by requesting the user to choose a “gatekeeper” avatar image from a gallery of images.

Included in the code repository on GitHub is a utility developer program named dumpSessionZ.php (or dumpSession.php if you don’t use the Zebra session2DB session database manager included in the repo) which will allow for the periodic display of the PHP $_SESSION variables as the programs execute. These next images are the results of dumpSession run against the GateKeeper.php program page as we see it above, and it profiles the activity of the executing PHP program, allowing us to “follow along”.

The primary aspect of the GateKeeper’s function involves manipulating several arrays of image files that we then use to populate the onscreen selection gallery. The intent of these machinations is to rearrange the gallery images display order randomly on every page load. If you look at the GateKeeper.php code you will note that we have inserted an exception trap in the top section of code that selects the images to display such that we may specify the inclusion of a particular user image in the gallery. This allows us to be sure that this image can be selected as the trap exception user’s gatekeeper avatar. This has two ramifications.

First, it allows me to specifically include my own personal mugshot in the demo walkthrough☺. Secondly though, it provides a convenient place to insert a shim that could be used to make a particular image available to any specified user.

However let’s continue and assume that our user clicked the avatar image shown selected in the GateKeeper screen above. This results in the display of the first mugshot info page shown here next. The image for this page is a JPEG image loaded from the Storybook/Portal/ckimages folder by the Storybook/Portal/mugshotChoice.php program.

This also results in appending a few more values to the PHP $_SESSION data array which we can examine by refreshing our dumpSession display. Of special note is information from the user database including the user email address and first and last name along with the factors value shown here next.

If we click the Gatekeeper image to continue our user registration this action results in a form POST request being issued by mugshotChoice.php to our Node PGP API Server. The Node terminal will display this following screen as it generates and saves a PGP key pair for this user and then awaits the next API request.

When the API completes the key generation it then saves the keys in a database and returns the user back to the main app by means of a PGP API completion notice email web page display shown next that includes the direction to load Storybook/Portal/showMugshotChoice.php. The code for the Node API service as installed is included in this article repo in the Authur/openPGP folder and there is more information about the API code itself in this article ( https://medium.com/@itzbobwright/some-openpgp-crypto-functions-on-a-node-api-server ) and its associated GitHub repo.

This setup allows the use of an API that is on a domain separated from the logon application, and it allows for the use of the openPGPjs NodeJS repository you can find as a fork on this GitHub repo at https://github.com/Bob-Wright/openpgpjs.

Let’s consider a few aspects of this separation that we might leverage. We could have our PGP Node Server API running on the same server as our Logon portal. Another consideration would be connecting the PKC Node Server to the Logon App server over a private IP or similar isolation scheme. One could use the server IP address as opposed to the Internet DNS system.

But to continue with the discussion of the present scheme the user will click the image as directed to load showMugshotChoice.php with the following page display as a result.

If we do a dumpSession refresh on this page we can see four more data values appended to the PHP $_SESSION array variables as shown next below. The array now includes a value for a PGP style public key which is stored with the $_SESSION array key value of [plaintext] along with three other values for the [coverImage], [stegoImge], and [secretKey] keys. The [plaintext] value, i.e. the PGP PUBLIC KEY BLOCK, is retrieved from a key database where it was previously written by our Node PGP API.

The showMugshotChoice.php program has used these values to generate the image shown in the screen above and this image is actually now a new saved PNG format image that has been Steganographically encoded to cryptographically embed the PGP PUBLIC KEY BLOCK value.

At this juncture we have used the registration or enrollment portion of our Logon Portal to create and save all the information that we presently use in our Authur-An-Image-Based-MFA-User-Authentication-System. If our user now clicks the image as directed they are returned to a new Login Portal page with a new cleared $_SESSION array as shown on the two screens here below and they may proceed with their login to the Storybook Comic Book Builder.

Before we click our second mugshot info image and while our $_SESSION array is still loaded we can divert our attention to using another program also included in the demo setup. If we browse to the Storybook/Portal/decodeStego.php page we will be presented this screen next below which shows a proof of concept extraction of the Steganographically embedded and crypto encoded PUBLIC KEY BLOCK for this user.

As a wrap up these next images are the complete dumpSession captures for the page above.

Conclusion

That completes our examination of the code used in the Enrollment or Sign Up component of our Authur Image Based MFA User Authentication System. The next and final section of our code that we will consider is the Login component function wherein we verify our newly registered user to access our hosted Storybook application. Stay tuned for the writeup hopefully coming soon.

For the next iteration of our User Authentication System the intention is to add two facilities. The first facility would be to include a method to programmatically use our generated Steganographic image to mint or create an NFT image to use as our MFA token image. An important consideration here is cost and for the demo the minting must have no gas fee. The second facility would allow a user to upload their own gatekeeper avatar image as provided by say an employee database which we can then convert to our Steganographic NFT format.

Let me by offer some well deserved shout outs and PROPS to all the benevolent coders whose work kindly contributed to this effort. Finally thanks be to God and my family for the most excellent support!!

Also published here.