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 guessable, 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 ATMs.
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 log in.
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 webcomic 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 log on.
Logon Methods
As an aside, Storybook was originally created and intended as a Facebook application using the Facebook OAuth Logon method.
To log on as a user and post content using this method, you must be a registered Facebook user and log on 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 log on to the Storybook application. To log on 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 log-in.
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 the concept of 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 an SMS message 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 to provide a shortlist 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 bottom of the screen. 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 of 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 users 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 amongst a sample of 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, that 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 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 log on 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 log in 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 logs on 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 with an image gallery like the 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
Bob has been designing hardware and coding software for decades. He likes to draw and write. He’s currently a web cadet wannabe living the culture of poverty.