Authentication on websites is changing

I devised a new authentication approach for my websites

Desperate times calls for drastic measures

I had reached the end. As a developer who builds websites when he has to, rather than out of love - I had got tired with the same old .Net Identity Framework approach to authentication. In MVC4/MVC5, it was the case that you would install Identity Framework/Entity Framework and configure a number of external Identity Providers.

This entailed registering your application on sites like Google, Facebook, Twitter, Outlook. The problem was each provider had their own flavour, and set of hoops to jump through. Your application would suddenly stop signing users in.

For my property platform, I decided enough was enough. I had set up Twitter authentication and it worked well. Installing the standard .Net MVC Identity Framework, I was pretty happy with it. At some point - it just stopped working.

.Net Core or .Net?

I reached a critical point. Do I move or not? I wasn't happy with the .Net OAuth/Identity Provider approach. I spent time researching Identity Server and found it completely baffling. It seemed like, they had written extra code on top of Identity Framework, and given a lot of samples which kind of worked/worked but due to how the code was written - was ugly.

So the decision was taken to write my own framework. It was felt, I could create a protocol approach to authentication, meaning it was down to the consumer to write their own protocols/methods.

Email based authentication

For my property platform - the decision was for users to need two email accounts. The users would simply enter two or more email accounts, and all sign-in would be by clicking on links delivered to their email accounts.

It was essential, the email addresses were stored in the database in an encrypted format. Once registered, the users would simply enter their emails, receive the links by email and once all links had been confirmed, they would be signed in.

"Who has two email addresses, isn't it an extra hassle?"

One of the great features is, a user could verify one email address on one device and another email address on another. You get to decide how secure you want it to be.

The development

The full library, took around a month to write, and embed into Piranha CMS. After ironing out a few bugs, maybe five weeks. This is quite a long time to spend on it but it was lot of unknowns to get right.

The result

  • We don't use passwords. This protects the user from our database getting hacked and those details being attempted on other sites.
  • The database doesn't care about email addresses stored in clear text. It makes it harder for people to read about the users.
  • We avoid capturing personal data. One of our beliefs is, the less we know about people, the better.

Is it practical - seems inconvenient?

All security is inconvenient. If it is too easy, it is not worth having. My personal belief is, it is worth the extra step to make your data harder to get to.

Info Rhino can implement this solution for you

Info Rhino is a software solutions provider. We built this approach for the findigl platform. To see it in action - navigate to here - findigl

Other ways of authenticating users

Passwords and usernames

As a technologist - perhaps the most irritating element of system access is usernames and passwords. We end up reusing passwords for different sites until one of those systems gets breached and then any other websites we access are also at risk.

People thinking more securely use multiple passwords. More recently, for many websites, I use a password manager. This involves generating a stronger password, and then using that to log in. There is no need to remember the password, as it is stored within the application in an encrypted format. For my most important websites, I don't store my passwords in the password manager.

Forgotten passwords

Perhaps the most painful issue with websites is when you forget a password. The process becomes something like, entering a password, being told it is incorrect, potentially getting locked out, entering your email, getting a reminder link, resetting the password, logging in. The next time you log into the website, you have forgotten it and the whole process starts all over again.

The right thing to do is to use the password manager to create new passwords per website.

Biometric authentication

Next, we can use fingerprints, eye scans and other biometric mechanisms such as facial recognition - but we have seen the spy films. The idea that somebody might want to cut my finger off just to order a pizza for free isn't where I want to be.

Open authentication and Identity Providers

Another great way to authenticate users is to let an independent relying party to hold the authentication details and pass a confirmation message (token) back to the consumer. Facebook does this, for example. You register for their application, and users log into Facebook and you have no need to store sensitive data like passwords etc.

Many flaws with IP exists

  • Clients can get barred from IP. Facebook or YouTube could decide to bar a company - de-platforming.
  • IPs change their Application Programmable Interface (API) without decent notice.
  • The IP sites could themselves, get hacked. LinkedIn was hacked for example.
  • You don't know if they will charge you in the future - some have.
  • Identity Providers have to share data with governments and other agencies. This is not ideal.
  • Some users don't want to use IP - many people don't want to use Facebook, Google etc.

Chips / RFID

Right now, I am in Sweden. Several thousand people, have, so far let a small RFID chip get implanted in the webbing of their hand. This lets the lucky owner - not need a security card at work, pay for a train ticket without a credit card. Personally, I think it is nuts. Criminals steal a credit card - or cut this chip out of your hand.

Two-factor / Multi-factor authentication

This is pretty good. The idea is, at least two methods of authenticating a user are used. You have a password username but also have a device to receive a notification token. This is closer to the idea of claims based authentication. You own a mobile number - which is unique and an email address/password. Somebody could steal your mobile, but by implication, brute forcing a password is no longer enough on its own.

Blockchain based authentication

This is the future and will be a separate post. Right now, not enough people use blockchain but it is the way of the future. We considered adding blockchain authentication to our protocol list.

Add comment