In Part 1, we looked at some of the concepts used in our logon schemes, along with some details about the Logon methods offered by our demo Portal, and we looked at how the system signs up or registers a new user.

We then saw how a registered user can log on with their email and password, and finally how they can change their name and email.

In the conclusion to Part 1, we saw this screenshot below described as part of the AuthUR NFT Image logon process, so let’s pause and examine this screen and how it compares to some more common MFA approaches.

Perhaps the most commonly employed MFA scheme is the popular two-factor MFA (2FA) method of sending a code, usually a group of six to eight digits, to a user’s cellphone.

In this method, a user logs on to, say, a website or web application with a username or email address along with a password. The site sends a numeric code as described to the user's cellphone with the expectation that they will next enter the code on the website as part of the logon process.

Today, both the FBI and Microsoft, for example, say that this use of SMS is a dangerous practice. We can find articles advising against the use of this SMS authentication practice.

A quick synopsis of the problems includes the fact that a relatively unsophisticated eavesdropper can “read” or see all of your SMS messages, including the one containing your login token.

That the SMS message content is sent in “plaintext”, i.e. not encrypted, makes it attractive for a thief to obtain a new SIM card to hijack your entire telephone; now their phone becomes your phone with your messages on their screen.

We might suppose that in the criminal enterprise, circumstance may play a large part in the modus one might employ, and a thief might resort to the simple expedient of stealing the victim’s cell phone. (In the comic, Jaqi occasionally “borrows” Henri’s phone while he is at lunch and uses it along with the purloined password to siphon funds from company accounts. Afterward, Jaqi simply deletes the message, the activity is no longer apparent, and places the phone back on Henri’s desk.)

A suggested alternative to the use of SMS texting is an “authenticator app” that provides a second factor generated on a local device instead of being sent as a message.

The authenticator installs on a local device like a cell phone and uses a counting program that provides a new value periodically, usually every thirty seconds.

The new value that is generated is part of a pseudorandom sequence, and somewhere in the great beyond an identical and synchronized generator provides the same code to the website or application that the user is logging on to.

So, the user enters the code from their authenticator app on the website, and a match authenticates the user. Two of these authenticator applications are Google Authenticator and Authy, with the Google app being a sort of standard for this approach.

The most notable feature of these apps is that they are somewhat universally used and supported. They might provide a different code for the various websites or web applications that they support, so it can be supposed that they contain multiple sequence generators.

Their portability may vary, and how lost devices are handled may vary. The use of authenticators entails the notion of backups for the factors or generators. The popularity of these authenticators will hopefully help to maintain a high level of support.

But in any case, both SMS texts and authenticators provide or display a numeric code in a fashion similar to that shown in this next screenshot that directly serves to provide (and hence also to a certain extent expose) the second factor in a 2FA scheme.

Now, let’s assume instead that the screenshot shown to the right of the image above serves the purpose of providing a second factor in an MFA scheme, and that this screen substitutes the token code displays of the SMS text and authenticator methods shown in the example screen immediately to its left.

Even to the casual observer, the overall look or appearance of these two example screens is obviously quite different beyond their mere difference in size.

The most important difference is one of philosophy, in that our AuthUR screen includes the notions of identity and choice instead of simply presenting a numeric code for the user to copy.

The screen displays a gallery of randomly presented “gatekeeper” images, only one of which “belongs to” or that represents our user’s identity, and in order to proceed with their logon from here, the user needs to select the appropriate previously assigned image.

You may recall from Part 1 that our example user’s gatekeeper is shown here in this gallery as the first image in the second row. We’ll return to the specifics of the image a bit later.

The banner at the top of the gallery page admonishes the user to “note the spots on your gatekeeper’s dice”, and we can see that each gatekeeper has an associated triplet of dice displayed.

First, we should note that the dice triplets are not merely random groups of three dice images, but instead, each triplet of dice represents a numeric value of a special import.

So, for example, our user’s gatekeeper has a triplet of dice whose value we may refer to as “six six three” or “663”.

One reason to use dice to represent numeric values is a sense of kawaii, it does after all have a sort of “cuteness” to it. Another reason to consider using images of dice as numeric tokens is that the value they show is not immediately easy to interpret by a machine.

In that sense, we can see the dice as a sort of “Captcha” mechanism. The value represented by the dice becomes the variable part of our MFA token, and to that extent, the spots on the dice nominally correspond in function to the numeric code of the SMS text or the authenticator app. The value shown by the dice changes every minute.

Humans are used to having ten digits to represent numeric values, that is the familiar decimal system. Using dice to represent numeric values is problematic because a die only has six faces or sides, and furthermore, none of the sides nominally represents a zero.

Recall that our dice triplet changes every minute, so we can see that at a minimum we will require at least sixty dice triplets, one to represent each of the minutes from 0 through 59. If nothing else, we could simply use a table-driven lookup substitution with sixty entries.

However, we have developed what seems to be a unique approach for encoding numeric values as dice for use in our AuthUR portal.

Each die has six faces, each face having from one to six spots. If we simply view a side with six spots as actually containing zero spots, then we have a range of digits from zero through five.

Now, that coincidentally corresponds to the digit range we encounter in Radix 6 (or Base 6) math. Thus, we can now easily count or represent sequential numeric values with dice in Radix 6 by use of our six to zero substitution.

So, for our example user’s dice of six six three, the actual Radix 6 value encoded by the dice would be 003.

For our demo portal, the value represented by the dice is the actual minute of the logon time.

In the token code display methods used in SMS and authenticators, what is presented is a pseudorandom value that changes periodically based upon a timer.

In a similar fashion, we could use our timer to periodically present a pseudorandom Radix 6 triplet instead of the actual time, and certainly, that would be a fair addition to a production use case.

But our demo explanation is better served by the display of the actual time. Based on this we can see that the three dice in our example user gatekeeper image represent a logon in minute three of some hour.

Our example user, besides being able to pick the correct gatekeeper, is expected only to be able to note the spots on the dice triplet. Randomizing the dice triplet by some encoding scheme to make it less obvious that the dice reflect the minute of the hour would not impact a user’s ability to note and later report their value and would lend greater security.

When our user chooses to log on to Storybook using the AuthUR NFT Image MFA scheme, we note the time, and after our user ultimately returns from interaction with this pick your gatekeeper gallery screen, we will interrogate them about the value of the spots on their dice. If the times compare suitably, then we have one factor we can consider for our user authentication.

So in the end, the role of the dice is to serve as a time-varying factor in our MFA token. Now, let’s roll along with our exploration of this logon screen and our explanation of the NFT MFA logon.

Once again let us recollect that we have a gallery of twelve images, eleven of which are nominally unknown to us and that serve as decoys, and the twelfth image being that of our user gatekeeper.

We observe that the eleven images are chosen at random from among a gallery of about 144 such images and that the eleven shown will nominally be different every time the user logs on.

The position of our user gatekeeper in the gallery is also chosen at random, so the gatekeeper will have a different placement in each gallery.

In the same fashion as the SMS and authenticator methods, we would like to have at least a symbolic separation of the device that displays our gallery, and of course, we have a method of synchronizing the gatekeeper gallery with our website or application logon.

We could, for example, have the website and our logon MFA provider on the same server as separate domains using the same IP address. Another alternative could be a local network for the application website to reach the logon MFA server.

Regardless, we will employ some method to allow our two servers to communicate through a channel unseen by our user and that does not require cross-domain posts.

Our intent is to expose a method to employ NFT images as a component of a novel logon scheme, and so less to provide information about NFTs and the blockchain per se.

Nonetheless, some attributes of NFTs and blockchains are of major import to our scheme. First, let us consider that the blockchain provides an unmodifiable immutable permanent record or log about the tokens it contains, so once an image is minted or created as a (non-fungible) token (NFT) we can assume, for example, that the image itself is not subject to modification or change.

It will forever be as it ever was. Two other attributes of these NFTs that are worthy of note for consideration as part of an authentication scheme, for example, is the notion of ownership, whose NFT is it, and the notion of the creator which is who originally minted this NFT.

As an adjunct to the NFT and blockchain technology, we also have the notion of a wallet, which acts as a container for data that allows us specific access to and control over our NFT.

Transactions like, say, the exchange of an NFT, take place between these wallets, so to “own” an NFT you must actually own or at least control the wallet that holds the NFT.

In the grand scheme of things, for example, we could simply query the blockchain for the identity of the owner of a particular NFT.

Certainly, these nuances in how to employ an NFT and the blockchain and wallet infrastructure for user authentication are worth consideration, they look like a great opportunity to explore blockchain technology providers and their APIs.

NFTs are in current vogue as objects of art, some say they are all the rage. The very salvation of art. Others decry them as the digital version of the Beanie Babies, a scam that overhypes mediocre art.

In either point of view, or anyplace in between one commonality, is the consideration of value for something that anyone may easily copy or duplicate and that is freely available to view. Central to all of this is the concept of ownership and what it means to own something.

AuthUR does not employ this approach of interacting with the blockchain through vendor applications or APIs that treat the NFT as an abstraction with the attribute of ownership to verify a user.

Instead, AuthUR focuses on using the NFT itself as a direct object in the verification process, and in fact, for our demo, the ownership of the NFT is not of great consequence. The only thing of import is the NFT itself.

Recall that we referred to our NFT image, the character it portrays, as our gatekeeper. This name is reflective of the fact that the character is not per se, a token or key in the authentication process, but instead, the gatekeeper possesses or holds a necessary key or token.

The gatekeeper is in fact basically a container. That the gatekeeper as an NFT is immutably stored on the blockchain where the application may access the container independent of the user partially serves to demonstrate its validity as representing a user.

Next, let’s look at this idea of an NFT image as a container for a key and how that plays into our scheme.

One method that can be employed to use an image as a container is to include the data either as plaintext or encrypted within what is referred to as the image’s EXIF data.

For photographs, this is frequently used to include information about the camera, perhaps even geolocation data, the time and date, and copyright information, for example.

For the case where we create a custom NFT for each of our users, we might well consider including their name in the EXIF data as the copyright holder.

Some EXIF data, while it is included in the image file like our copyright notice, may be extraneous to the presentation or appearance of the image itself, it may not actually be “a part of” the image.

Since the EXIF data is readily visible, it must be encrypted if plaintext exposure is unacceptable. Nonetheless, the presence of, say, copyright data with a particular name, could be a part of the authentication data that our NFT image “contains”.

Another way that we might embed or encode information into our NFT image for subsequent retrieval is through steganography. Steganography is a manner or method of obfuscating or hiding content by including it within other content.

In the case of our NFT images, we employ a pseudorandom distribution of modified least significant bit (LSB) values to embed or encode our data within the image itself, and further this data that we embed has also been previously encrypted.

If the reverse algorithm to that used to encode and distribute our data bits results in content that we can then decrypt to obtain a valid key or authentication token our user’s logon will be successful.

Perhaps our encrypted content could be a PGP (Pretty Good Privacy) key or another PKI variation key. Or maybe it could be a simple passphrase that we accept for the user’s login.

So here in A Unique NFT Image-Based Authorized User Registration (AuthUR™) and Logon System (Part 2) we have seen how an NFT image can be incorporated into a user authentication scheme.

The next consideration for our exploration of this NFT image-based logon scheme is to look at the code behind the AuthUR implementation along with the creation of our NFT images. Stay tuned!

itzbobwright@gmail.com

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.

Originally published here: https://medium.com/@itzbobwright/a-unique-nft-image-based-authorized-user-registration-authur-and-logon-system-part-2-6fdd8f6d87e2