A Unique NFT Image Based Authorized User Registration (AuthUR™) and Logon System (Part 1)

Many if not most interactive Internet applications require a user to 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.

A simpler definition is to say that authentication is the process of verifying that some entity, for example our user, is actually who they claim to be. There are three primary means of user authentication in popular use:

Type I, something you know Passwords, PINS, and passphrases are all common examples of Type I authentication. All of these methods have the common weakness that the identification factor, the password for example, may be easily guessed or stolen.

Type II, something you have These are physical items or factors that the user has, for example an ATM card or a smart key or smart card. While it does not have the weakness of being guessible, it does have the weakness that it can be stolen.

Type III, something you are These are factors like biometrics, for example fingerprints or retinal scans or a user’s handwriting are all Type III authentication. Of the three common methods of authentication this is the most secure because it cannot be guessed and is hopefully not easily stolen.

Sometimes combinations of these types may be used together to authenticate a user. An example of this approach which is frequently referred to as “strong authentication” is the common debit card (Type II) along with its associated PIN (Type I) used to access ATM machines.

Another important means of user authentication involves the notion of out-of-band (OOB) factors which are data items likely only known to the user and which the user provides as part of the validation procedure to logon.

These concepts are the foundation for our user logon portal and the various methods it supports. Let’s look at the AuthUR implementation of some of these concepts.

The Logon Portal

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 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.

As we may see, there are four logon option choices listed in our main dialog box, along with the option to modify our user password and of course an option to sign up as a user. There is also 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.

Logon Methods

As an aside, Storybook was originally created and intended as a Facebook application using the Facebook Oauth Logon method. To logon as a user and post content using this method you must be a registered Facebook user and logon to Storybook (which was also a registered FB application) using the FB Oauth authentication scheme. The measure of security provided by this logon method is sufficient to satisfy Facebook requirements. Other social media also provide similar user ID schemes. These schemes notify the authorization provider, for example Facebook, that you have logged into the associated application. They also require your application to become part of their ecosystem. Finally it might be argued that their interest lies in protecting their ecosystem rather than your application. The lack of privacy and security are two of the reasons Storybook does not support social media logons and the method is no longer shown as an option in our logon dialog.

This leaves four methods or options shown in the dialog box that may be used to logon to the Storybook application. To logon as a user on Storybook using any of these methods you must first authenticate yourself as having control over an email address by a token exchange. Let’s now quickly consider the first three listed simple logon methods which should be familiar to most web users.

The first logon method labeled “Email or Username Login” is accomplished by simply entering both the Password and the verified email address (or a user name extracted as the recipient name from the email address, thus the Username will change if the email address is changed). A periodic revalidation of the user email may be appropriate for this method.

The second method listed uses a “Magic Link” logon. Instead of asking a user for a password, this form of no password authentication asks a user to enter their previously registered email address into the logon box (or the username described above). An email is then sent to them, with a link they can click to log in. This process is repeated each time the user logs in because by default the Magic Link cannot be used more than once. Time to live (TTL) is a consideration for this scheme, how long is the link good or valid. The default Storybook TTL is two minutes. Password entries for this logon choice are ignored. The Magic Link has particular use to grant access to online documents for example.

The third method listed is the “One-Time Password” logon. One-time passwords (OTP) or one-time codes (OTC) are similar to magic links but require users to input a code as a single-use or one-time Password instead of simply clicking a link. The OTP is sent to their previously registered email or mobile device. This process is repeated each time a user logs in because by default the OTP cannot be used more than once. TTL is a consideration for this scheme, how long is the OTP good or valid. Our default TTL is two minutes. Password entries are ignored for this choice until after an OTP has been requested and then the emailed OTP Password is used for a one time logon.

The fourth logon method is our AuthUR “NFT Image MFA” scheme. The MFA scheme used by Storybook leverages NFT images and encryption technologies to present a unique Multi Factor Authentication method. Multi Factor Authentication schemes in general rely on a concept using two or more “factors” to identify a user. One factor is something the user knows, for example their password. The second factor is something the user (and hopefully only the user) has in their possession. Frequently the factor that the user possesses is a key fob with a periodically changing displayed code value, or perhaps more commonly a code sent by SMS messaging to their phone. A user is required to input the MFA code as an additional single use Password. This process is repeated each time a user logs in because by default the MFA token cannot be used more than once. TTL is a consideration for this scheme, how long is the MFA good or valid. Our default TTL is two minutes. Password entries are ignored for this choice after an MFA has been requested until it is used to Login one time. Before we consider the particulars of logon using this method let’s look at the Sign Up or user registration procedure for the app.

Sign Up

If we click the Sign Up button shown in the previous screenshot we will be presented with the dialog in the following three screenshots.

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.

Clicking the “Verify my email” button will result in this next screen requesting the user to choose a “gatekeeper” image from a gallery of images.

Let’s pause in our description of the sign up process to consider what we have presented on this screen and how it functions as part of the AuthUR NFT Image MFA Logon scheme. Obviously there are twelve images presented on the screen with the direction that we should choose one for our use in subsequent logon procedures. Each one of these images is actually an NFT “minted” (has the notion of created in it) on one of the popular blockchains (see the References footer). The single greatest aspect or attribute for an NFT is within their defining characteristics: they are “non-fungible”, which is another way to say they are immutable or unchangeable. Another attribute of an NFT which might prove useful is the notion of ownership. For our immediate purpose of user authentication these two attributes are of importance

For this demo version of our portal scheme we have set up a gallery of twelve already minted NFTs for our user to choose from. For a small number of users twelve different NFT tokens may be sufficient if only one is displayed as a choice from among a sample from a large number of inactive or dummy or “decoy” images. For this demo we have a gallery of 144 decoy images from which we will populate a random gallery of eleven decoys along with our single gatekeeper. Obviously it would be simpler to just have a large gallery of previously minted NFTs for a user to choose from. So why do we use this scheme presented here, a scheme that only uses 12 NFTs? That’s it, precisely! The answer in the question. Each of these NFT images was first created and then minted individually, both of these processes “by hand” in what could be termed a labor intensive process. Certainly the generation of a gallery of NFTs could be automated.

Another even more obvious approach which could be used is to create and mint a new NFT for each user, perhaps even allowing them to provide their own image which we will use to create an individual custom NFT. The logon process would still have 11 decoy images along with the NFT. These ideas are in the process of realization and will be incorporated into our scheme in the next rendition.

So continuing our description of the Sign up process, let’s say that the user chooses this gatekeeper character as shown above and clicks the image to select it. This action will result in the screen below.

If the user now clicks the image of their gatekeeper as directed they will be returned to the Portal Logon page.

All of these machinations have generated some data that is stored in a mySQL database, and for this example user much of the record looks like this.

On the Logon Portal we can now enter our email address or our generated user name along with our password as shown in these two clips. Note that once the user has entered the username/email and password simply hitting ‘Enter’ will perform the logon.

A successful logon will result in the display of the user’s dashboard as shown here below for our example user.

Because of some commonalities between “Sign up” and “Change My Profile Data” we can consider the Change function as an extension or continuation of the Sign up process. Selecting the Change button results in this dialog where the email address is shown changed.

Clicking the Commit Changes button results in this next dialog display. No email is required to change the First Name and Last Name.

Indeed an email has been sent to the requested new email address for verification.

After the user has clicked the link in the verification email they may logon with their new email/username. Their previous username and email will no longer be active. If the user delays in their response or there are other timeout issues the link button will result in this message.

Conclusion

That concludes Part 1 of our exploration of A Unique NFT Image Based Authorized User Registration (AuthUR™) and Logon System (Part 1). We have looked at some of the concepts used in the scheme, and we have seen how the system signs up a new user. Then we saw how a registered user can logon with their email and password, and finally how they can change their name and email. We did not discuss a user changing their password but that is a rather straightforward email exchange.

If a registered user logons using the NFT Image Based MFA method they will be presented with a dialog like this one, an image gallery containing their NFT and tagged with a variable component in the form of three dice.

On another logon occasion this same user might be presented an image gallery like this one shown here next.

The only common factor between these two galleries is the presence of our gatekeeper character in each one. In Part 2 we will look at why the dice and how they roll, and we will look at our gatekeeper NFT, which is more than merely meets the eye.

References

I found this book invaluable and heartily recommend it.

Modern Cryptography: Applied Mathematics for Encryption and Information Security, Tom Easttom, 2016 McGraw-Hill Education