Forem: Migwi Ndung'u

Authentication: Trust Vs Identity.

Migwi Ndung'u — Fri, 28 Feb 2025 23:50:02 +0000

🚀 Authentication

Authentication is the mechanism of associating an incoming request with a set of identifying credentials. The credentials provided are compared to those in a database of the authorised users’ information.

🚀 Identity Vs Trust

Identity can be defined as existential attribute associated with a given object or entity. This attribute is independent, absolute, and constant throughout the object's life. Trust on the other hand can be defined as an object/entity's acquired attribute that is relative and dependent on others. Trust is a derived attribute.

🚀 Traditional Authentication Protocols

I refer to all authentication protocols that depend on a user's Identity as traditional because of the following serious flaws that are in-built in all of them:

Most platforms discourage authentication in an insecure environment. Secure environments are rare to find especially in restricted and/or public places like airports. Majority of the authentication platforms also cannot differentiate secure and insecure environments used by users.
Validation of an identity simply means, "If you have the correct keys combination, then you must be the valid owner". How the user gets the correct key combination is irrelevant to the protocol.
They have no comprehensive ways to detect keys duplication. Valid keys are often used to grant unauthorised access. Most platforms can only detect duplication if a different device is used.
Once unauthorised access is detected, most entities initiate their nuclear options which not only cut-off the affected user(s) but also subject them to extremely tedious proof of identity methods.
Since identification credentials do not change that often, tracking someone's activities becomes very easy.
Users' identity information is scattered among thousands of platforms which make it very hard and expensive to enforce data protection rules within a given jurisdiction i.e. GDPR for platforms within European Economic Area.
Authentication keys are supposed to either be memorised or managed by a third-party software which could be the source of a leak if not properly vetted before installation. Memorised keys often get lost if the user's memory becomes impaired.
Most AI and Large Language Models have become so advanced that they can be said to have passed the Turing test. Deep fakes with near perfect abilities to replicate most biometric security features make it extremely hard for an identity-based authentication protocol to differentiate a human from a bot.

🚀 Data-Age Authentication protocol

This describes a data intensive authentication protocol that is based on trust where a cryptographically-signed key with a one-time-password feature in used. This trust key is issued and mutated by the trust organisation. For each successful authentication operation a new trust key with no user identifying data is used.

To successfully implement this protocol, the following entities must mutually authenticate each other:

Trust Organisation - A 3rd party that holds users' personal identification information on behalf of the target system(s).
Target Authentication System - Requires the trust organization approval to successfully validate a user's trust key.
User - Carries a trust key that is only backward traceable to the parent trust organisation and is mutated after every successful authentication.

This authentication protocol makes it nearly impossible to identify a specific user during the authentication process and ensures all the authentication operations are unique for the specific trust organisation.

🚀 Strengths of Data-Age authentication over the Traditional Authentication Protocols.

Advancements of the modern technologies in NFC, powerful GPU's and Ready AI models make it very easy to rollout the protocol in a large-scale. The NFC can used to store an OTP trust key while the AI models and powerful GPU's can be used scale up the efficiency of a trust organisation.
The OTP nature of the trust key after every successful authentication means that duplicate valid trust keys cannot exist simultaneously.
Validation using trust key simply means, "The trust key you have and how you use it, determines how much of the valid owner you are". By default, the protocol assumes that every user is malicious/a bot and only grants the necessary permissions depending on the kind of trust held.
Since personal information is only managed by a few trust organisations on behalf of very many target systems; more user-friendly disaster recovery and business continuity policies can be implemented cheaply.
The trust key is exclusively stored in an NFC tag, allowing characters longer than an average human being can memorise, to be mutated after every successful authentication.
GDPR can be best enforced on the few trust organisations that meet the strict requirements needed to safely and securely handle sensitive personal data. This allows a user to be 100% aware of how their personal information is being used.
Since target systems can no longer identify an individual user, they can monetise the data acquired from the authentication operations with zero risk to the users.
Mutual authentication for all the three entities involved, implies that any entity that misbehaves it can be punished by the rest. Trust Organisation with malicious users will not be accepted by the Target System, Trust organisation can reject all authentication requests from a malicious target system. Users can also be rejected for being associated with malicious Trust Organisations or Target Systems.

🚀 Conclusion

Identity-based protocols consider the security of the authentication Keys as the individual responsibility of a specific user. The Target Authentication System has minimal to no consequences of mishandling users' sensitive data.
Trust-based protocol considers the security of the authentication keys belonging to a specific user as a collective responsibility of all the entities involved. All the entities involves must be responsible in how they handle the sensitive users' data otherwise grave consequences with follow them.

Blockchain Technology: The future is here

Migwi Ndung'u — Thu, 08 Mar 2018 01:43:17 +0000

For quite some time I have tried to consciously avoid the blockchain technology topic but I can't afford to ignore it anymore. I have also heard so many people call bitcoin a bubble in the financial markets that will autocorrect with time but now I beg to differ with people in the above school of thought.

Blockchain is a new form of technology used as the underlying technology supporting the Bitcoin ecosystem as listed by Satoshi Nakamoto in the bitcoin whitepaper published in 2008. Therefore blockchain is a decentralized ledger/record of transactions that is accessible to all involved parties and cannot be altered unless genuine transactions are being added.

The next question that we are all asking ourselves is, "How did blockchain gain such a huge adoption in that short time span? ". To answer the above, question we need to revisit the history about trading and financial transactions.

Barter trade was the way of life before money was invented. Someone used to exchange item A with item B if at all there was a consensus that both items A and B held the same value. This was problematic especially if item A and B did not hold an equal value.

Some brilliant people came up with the concept of money that was widely accepted because it held a definite value that could be subdivided without losing its original value. Governments and banks took up the role of managing the money which was converted to the various currencies that we use today. They made the currencies become a medium of exchange, store of value and a unit account.

Using money, governments and banks have misused the trust bestowed to them by the common people concerning the financial transactions. Money is nowadays used to control people which wasn't the original use and intention of the money.

Cryptocurrencies through blockchain were introduced to enable people make financial transactions almost anonymously though a system that was designed to be foul proof. This means that entities making financial transactions need not trust each other as none of them has higher control of the system that the other.

It also becomes easier and safer to make transactions as every successful transaction made, is stored in a database who copies are available to all participants. Its cheaper too as several middlemen in the Banking system are eliminated. The only limitation of the current versions of crypto-currencies is that they are too volatile. Their net value can increase or fluctuate within a split of a second.

I believe that crypto-currencies represent just a tip of the iceberg of what that can be achieved through the blockchain technology. It sort of proves a concept that true decentralization is the future. A lot of services that are currently centralized e.g. land ownership registry can be made easier to administer if they are fully decentralized using the blockchain technology.

I believe that we can make life better with blockchain technology. I believe blockchain technology is the future

Mocking Methods in Go

Migwi Ndung'u — Sun, 17 Dec 2017 05:00:55 +0000

It goes without saying that a battalion of soldiers is as strong as their weakest link. In this context, a piece of code is free of bugs and other issues as its weakest point. Kent Beck from facebook once visited us at Andela to give a talk on TDD and throughout his session, it was clear that unit testing is critical part of the software development.

Languages like Python provide standardised libraries and frameworks that make it easy to mock methods and functions inside an impure function or method. With python unit tests are pretty easy thus achieving a 100% test coverage is the norm.

Go or Golang is a light weight language that is not C based. Its syntax is pretty easy, I like to refer to golang as a "Pythonized version of Java" due to the similarity of concepts imported from both Java and Python. Golang does not have an official package that supports mocking of methods during unit testing.

Mocking in golang is done with the help of interfaces. Mocking in unit testing is important as it ensure that variables, methods and functions modified outside the scope of the function being tested do not affect the test output.

Here is the implementation of mocking.go

/** mocking.go **/

package main

import "fmt"

type (
    // Values defines interface to be used in mocking
    Values interface {
        GetVolume() int
        GetSurfaceArea() int
    }

    // Measurements defines the measurements used to calculate
    // the surface area and volume of a cube or a cuboid.
    Measurements struct {
        Length int
        Width  int
        Height int
    }
)

// GetVolume calculates and returns the volume of a cube or a cuboid
func (config *Measurements) GetVolume() int {
    return config.Height * config.Length * config.Width
}

// GetSurfaceArea calculates and returns the surface area of a cube or cuboid
func (config *Measurements) GetSurfaceArea() int {
    return (config.Length * config.Width * 2) +
        (config.Length * config.Width * 2) +
        (config.Height * config.Width * 2)
}

// GetVolumeAndArea fetches and returns the volume and the area
func GetVolumeAndArea(val Values) (int, int) {
    return val.GetVolume(), val.GetSurfaceArea()
}

// program execution starts here
func main() {
    var (
        area, volume int

        data = &Measurements{
            Length: 1,
            Height: 5,
            Width:  3,
        }
    )

    volume, area = GetVolumeAndArea(data)

    fmt.Printf("Volume : %d , Area : %d \n", volume, area)
}

GetVolumeAndArea function accepts an interface as its input parameter. This means that any receiver (struct used to create a method) that implements GetVolume and GetSurfaceArea also implements the Values interface.

Mocking of GetVolume and GetSurfaceArea is done by passing their customized implementations through the struct that acts as their receiver.

Below is how mocking of GetVolume and GetSurfaceArea should be done using interfaces. No extra libraries or frameworks needed.

/** mocking_test.go **/

package main

import (
    "strconv"
    "testing"
)

// MockTest helps implement our customized GetVolume and GetSurfaceArea
// needed to mock the original implementation in mocking.go
type MockTest struct {
    Elem int
}

// GetVolume returns the volume of a cube
func (config *MockTest) GetVolume() int {
    return config.Elem * config.Elem * config.Elem
}

// GetSurfaceArea returns the surface area of a cube
func (config *MockTest) GetSurfaceArea() int {
    return config.Elem * config.Elem * 6
}

// TestGetVolumeAndArea tests the functionality of GetVolumeAndArea
func TestGetVolumeAndArea(t *testing.T) {
    for key, val := range map[MockTest][]int{
        MockTest{Elem: 5}: []int{125, 150},
        MockTest{Elem: 2}: []int{8, 24},
        MockTest{Elem: 1}: []int{1, 6},
    } {
        t.Run("Cube side length "+strconv.Itoa(key.Elem), func(t *testing.T) {
            volume, area := GetVolumeAndArea(&key)

            if volume != val[0] {
                t.Errorf("Expected volume to be equal to %d but was equal to %d ",
                    volume, val[0])
                t.FailNow()
            }

            if area != val[1] {
                t.Errorf("Expected area to be equal to %d but was equal to %d ",
                    area, val[1])
                t.FailNow()
            }
        })
    }
}

Apart from mocking, interfaces also helps in separating of concerns such that pieces of code/functions/methods that communicate with each other can be made to run independent of each other.

They also help hide the underlying implementations that should not be exposed to the outside world especially when building an API.

For any Clarifications, Corrections or Complements reach out to me via Email on mailto:migwindungu0@gmail.com

No Regrets At All

Migwi Ndung'u — Sat, 16 Dec 2017 11:55:04 +0000

Seven years ago(2010) I was preparing to seat for my KCSE (Kenya Certificate for Secondary Examination) exam as from November 21st, which marks the end of the secondary education in Kenya. After the exam, one is then ushered into the real unforgiving world where they can choose to hustle (do Jua Kali/informal jobs) or continue with their education to college and take a course depending on what they scored in the KSCE exam.

While preparing to do my KCSE exam, I knew for sure that I had to go to college whatever the cost and do an engineering course. Earlier on, we had a career fair day and I zeroed in on a Bachelor's degree in Computer and Electronics. In preparations to me joining the degree course, I had kept several chunks of scrap electronic parts and other items that would have made my on boarding as smooth as possible. Once in a while I used to land myself in an argument with my mum as after trying to build something with my scrap electronic parts, I left other electronic parts scattered all over the house.

The KSCE exam was successful, sadly when the results came back I couldn't join my dream course because my grades were below the cut line. I sought advice from a certain lecturer who advised me to take a Bachelor's degree in Computer Science and hopefully one year later into the course I could easily switch into my engineering degree. The lecturer forgot to tell me that his idea could only work if I was admitted into a university that offered both degrees.

The university selection was done by a government parastatal called JAB now called KUCCPS and I was posted to a college pretty far away from where I initially wanted to school. A few weeks after getting admitted, the reality dawned on me. All I could be able to do in the new college was computer science and I took my time before I fully settled and accepted to do it as a course and a career. I even tried to do an inter-university transfer but was rejected.

In the second year, I came to discovered the feeling of commanding a piece of code to do as instructed. My first piece code was a "Hello World" program in C and it felt like God had delegated to me some of his powers that he used to say, let there be light and there was light. I felt in computer science unlike engineering I was only limited by my imagination. My Procedural Programming lecturer explained during one of his lectures that several years might pass by before a change to the qwerty keyboard is made a standard but a software built in a very short time may transform lives. He basically informed us that a hardware change takes time before its effect can be felt but we had in our hands the power to transform the world with a software change.

With time I learnt by myself how to write code in Java through googling overnight when the noise level was lowest and the WIFI speed was fastest at the college WAPs (Wireless Access Points). I built an application that could help in transferring files since I couldn't afford a quality USB flash disk then. For my final year project, I created a hide and seek game inside a maze.

Building softwares has given me the best of memories and fun times. I have taken almost a full day to debug a piece of code only to find that a semicolon fixed the bug. I felt so great after fixing the bug that I can't trade the feeling with anything. If I never did software development, I am sure I would have had one extra regret in the list of the things I never did on my death bed.

It has been five years since I wrote my first hello world program in C. So far I have no regrets about failing to join an engineering course. Software development has given me a greater purpose to live. The climax of my career is going to be when I build a product that has both software and hardware components of a computer. I am currently proficient in Python and Go. I will be taking a C refresh course soon then venture into hardware programming later on. Once done with this, I will have lived my life to the fullest.