How to create a secure website which doesn't compromise your users 20 Mar 2022

Securing websites for users is a huge topic to consider the context of this article is to try to give a perspective on how we have sought to avoid the conflict between deciding to outsource/delegate authentication to a third party or run the risk of hosting this information ourselves on our own database or website. This article presents an introduction into the complexity of authentication. We are not Information Security experts and have written this more from a conceptual approach to minimising risk for users of websites. We introduce our approach at Info Rhino and our idea of protocol-based authentication. This approach is within our Web Data Platform and we consider this to be more of a principles based approach. We happen to have written the code that sits inside our website but could equally sit inside an API or application.

The backdrop to securing websites in the context of being a software developer

This may come across as quite limited in terms of how we are to think about securing a website. There is a huge amount of information online to do with protecting data integrity, data breaches, Strong Customer Authentication, PCI compliance, Data Protection and GDPR. We have Open Web Application Security Project (OWASP) with its set of guiding principles. We have oAuth which is provided by popular social media platforms such as Facebook, Twitter, Google, Hotmail. Finally, an area we are interested in is the use of blockchain based authentication to authenticate yourself on different applications and websites.

Delegation

The challenges we find in trying to provide a mechanism for users to access websites and applications confidently and securely is the decision as to whether to use third parties to handle the password and or two factor authentication type approaches.

The benefit to delegation is we have no need to handle passwords ourselves. When working with larger cloud-based hosting providers, their strong commitment to stronger security protocols is will make it harder for our website to get hacked. They will often have software running which can detect potential vulnerabilities.

There are some negatives to delegation, which really should be considered. The most obvious one is cost. Cost alone can make many applications and websites unaffordable for smaller businesses. Larger hosting providers have been known to de-platform websites, that doesn't meet their requirements. User content could breach policies of the hosting provider. A massive risk to using third parties is that they changed their interfaces and methodologies frequently and with little forewarning. We have experienced this with some of our own websites in the past and a particular example was with Twitter API authentication. As the saying goes, "once bitten, twice shy".

Self-hosted authentication

Is this the correct term for this approach? Probably not. What we are discussing here is managing the passwords, maintenance emails, redirects ourselves. Passwords will be saved in a database or some other location repository. The biggest data breaches are always on these types of websites because it is simply a matter of somebody hacking into the back end of the website, potentially get into the database and then downloading all of the passwords and user accounts. This disaster can be made even worse once we consider many companies store credit card details such as card payments.

The benefits for self-hosted authentication are many. The most important one is you are in control of the repository - you can't suffer poor performance by your hosting provider. You cannot be at risk from your cloud provider suddenly going down. With a reasonable Disaster Recovery strategy in place, you should be protected from this. Another benefit is that you keep the security within your organisation. Of course, this can be a double edged sword, but your employees are contractually obliged to you as opposed to individuals whom you don't know in far and distant lands having access to your most dearest secrets.

Perhaps one of them the biggest risks to self-hosting in addition to the problems of somebody just stealing and hacking into your password database. Must be the higher risk of your database getting wiped. Companies such as Microsoft are going to have a far better set of capabilities to protect the integrity of your password store than you would find on a typical web hosting platform.

Thinking about website security as a website application user

What do I want to see when accessing information and storing it securely online?

It is almost certain that most users won't think about the things to be discussed here and so in many ways, we are creating a persona, an idealised version of a security conscious user who wants to be secure when online. Moreover, this user doesn't want to be hassled with complicated password management and logging in.

Things a user is likely to want to have;

• Not having to remember passwords.
• Not having to spend time creating complicated passwords to fit specific requirements for individual websites.
• Not having their entire online history made available to potential hackers.
• A degree of anonymity in certain circumstances.
• Not using common social media accounts when registering on websites.

Wait a minute - this goes against all of the guidance that government have recently been discussing about online anonymity?

We aren't discussing the idea of a secretive user wanting to do online harm. Instead we are considering basic steps any sensible user would do to try to reduce their online digital footprint.

The reasonable way to fragment your online presence

Fragmenting your online presence simply involves using different accounts and ensuring that you don't use the same passwords for these different accounts. When accessing different websites. There are several approaches to this.

• Using a password safe with password generator.

• Having multiple email accounts.

• Setting up an email account specifically for certain websites.

• Not tying your mobile number to online registration.

• Not being on large social media platforms.

• One being on large social media platforms, not publishing significant amounts of personally identifiable information to them.

This is all well and good, but what's the significance of fragmenting your online presence with regards to creating secure applications when managing passwords? We are trying to establish a set of principles in terms of how an idealised user would want to remain secure online without being too easily connected up. Again, we are not discussing users wishing to enact unwelcome online behavior, but simply those wishing to not be as easily identified for any number of reasons.

Why do we wish to understand and identify a user?

• Regulatory requirements. This could include protecting minors from online harm, fraud prevention, Anti-money laundering regulations, and other legislation.

• Customer insights. By understanding our customer and what they are interested in, we can tale about products and services to them.

• Customer convenience/User experience. Like going through the exact same multi-step process just to access some online functionality.

• Getting in touch with the user.

Does a website really need to know me?

It should be a relatively easy one to answer for most businesses interacting with users. We should be fully aware that data has been described as the new gold. Many social networks business models are predicated upon more users, more data, more information, re-selling information to help businesses understand target audience is better. As the adage goes - "If it's free, then you are the product".

The principle of minimal knowledge

When we were thinking about the types of websites we were creating and the typical limitations to most methodologies for authenticating, validating and recognising users, we observed that in many instances, we did not need to know the users. The only thing we wanted to be able to do was to communicate with users at certain points to keep our users updated, to let them perform basic actions, and have a reasonable record of their presence on our platform.

Taking this minimal knowledge principle further, whenever we do need to know a user, it is for a minimal amount of time. For example, if we do have an email address, we only need to have this email address for the purpose of emailing them. When we emailed them where you would use as many posts as possible to avoid sending sensitive information. If our website accepted payment details, we would look to avoid storing personally identifiable information. Aside from legal requirements to satisfy a payment handler's requirements. In many situations, the payment handler themselves handles the address details and other information required for the user. If we take this further - do we need to know the address of the intended customer who ordered delivery of a physical product? Is it not the case that the company performing the delivery would be only company needing to know this information? In a similar fashion, the payment handler would need to understand where the billing address was, but do we need to have these details? In this scenario, all we need is to store a token of the address, retain a reference from both the payment handler and the delivery company, and avoid having to use or store their address altogether.

Now, of course this may be classed as ridiculous - an extreme case. After all, data is valuable. It may be useful to understand where our customers live, which towns are more likely to order products. We do recognise the importance of machine learning and basket analysis to try to understand customer profiles when orchestrating marketing initiatives.

The reality is it's a balance, isn't it? Most companies can benefit by having a certain amount of information about their customers. Although we must ask the question whether we need to know individually specific information and can't simply aggregate this to get a better perspective on a customer profile. At the same time, do we want to irritate our customers and risk leaking information to third parties just because we want to have this information, that we may not be able to benefit from using anyway?

Some core principles of minimal knowledge and helping to protect the integrity of users

• Consider data in terms of its sensitivity. For example, few would be that concerned if it was leaked that a customer was buying a pair of slippers for themselves. It could be trapped, catastrophic if it was leaked to the family that a pregnancy kit was being ordered for a teenager.
• Wherever possible, always try to encrypt or hash sensitive information, making it harder for it to be interpreted.
• Consider separating data stores and sensitive information. A great example could be to have a push only API whereby a user identity is pushed to an API to return a token which is held in a separate database. For example - storing a name and address in a database separate to orders of sensitive products would be a great way to protect the information about that user.
• Consider breaking up sensitive information when emailing clients into separate emails.
• Determine the level of security needed and separation of data according to the sensitivity of the data. You don't have to separate data if it is not sensitive. A great example is our property platform - findigl. That somebody has an email address associated with being interested in looking at properties is hardly the most sensitive information in the world, but it could be if a married partner was looking for one-bedroom flats. Even there, we still try to encrypt identifiable information where possible.

How has Info Rhino developed its security authentication for our websites?

What are the key mechanisms and approaches we have tried to engage?

Identifying the type of user roles our websites will feature

For a property platform findigl, it is for certain we will have professional users and consumers - buyers and sellers. A specific aim for consumers is to keep them engaged and interested in ever changing and informative content on our platform. We aren't trying to sell consumers specific services, but we feature vendors and commercial entities on our platform. We recognise that convenience is often to the demise of security. There are simple things we can do if we felt that users preferred more convenience, we may have to separate our information store from our security store. Alternatively, we may provide links of the vendors and our customers to allow users to click on them without having to divulge personal information. Users are likely to want to have a preferences page. We could store these preferences at an aggregated level to not show the individual preferences of a user to a third party. We could store these preferences in an encrypted format to avoid these preferences being made available to casual browsers.

Our protocol based authentication mechanism

In many ways, we can think of this in terms of this two-factor/three-factor authentication that we see now. It seemed more relevant to have a number of protocols needing to be satisfied to authenticate a user. We decided that a great way to ensure users had a certain degree of protection for findigl, was to enforce them having more than one email address. Not all users are technical, you say. Doesn't this sound like more of a hassle to our users - you say? And in many respects, yes, we can agree. Picking some of the top email providers, Microsoft, Google, Yahoo, iCloud, we can see how we can have more than one email address set up.

Let's talk through how this works in practice.

At no point do we store any email addresses in clear text within our database.

Registration

• User enters 2 email addresses or more into our registration screen.

• Each email account receives an email with an activation link.

• Once all links are activated, the user becomes a member.

Authentication/Sign-in

• User enters 2 email addresses or more into our registration screen.

• Each email account receives an email with a signin link (based upon a hash).

• Once all links are verified, the user is signed in.

Signout

The user clicks on the sign out button and this deactivates the current signing within the database and the authentication cookie.

How is this protocol based?

This is protocol based because we have a common data store which accepts tokens and authentication linked to member protocol group. The idea of the protocol is they can have one or more protocol instances, such as one or more mobile phone numbers or one or more email addresses. To us, we only care that all the political instances are verified and activated.

A really neat example of a powerful token based protocol authentication

Whilst the legalities of this are not fully established, please bear with this principle if we think in terms of GDPR. This may start to become an issue as legislation becomes more expansive around personal data. We could find ourselves as an employee acting as an individual for a company, and yet at the same time we are still an individual in our own right. We could be using corporate email and at the same time, maybe logging into services which are not within the company corporate domain. Even if we are using these services as an individual, we are tying our own personal footprint to these activities. One way to do couple this would be to have both the corporate email and a separate personal email tide to these activities. This would stop the mailbox administrator, within the company, being able to intercept the email to click on the link, sign in and investigate what the staff member was doing. This is because the second email may be installed on the user's personal mobile phone. This would need to be activated to verify signing in. We can see that will benefit here because the company itself could protect its own privacy, because if that user was no longer given access to their corporate email account, them having their own personal email account would not be enough for them to be able to sign in as a combined corporate personal user.

Reiterating the principle of protocol-based authentication

Remember, nothing is stopping us using a password as a protocol. Nothing is forcing us to ensure users only use emails to authenticate themselves. We don't have to rely upon SMS protocols either. The important consideration is the mechanism of storing groups of protocol entities, allowing us to combine different strengths of authorisation when validating and authenticating users.

We can take this further, for example, We could have corporate WhatsApp or Viber accounts whereby activation links could be pasted into message threads.

Finding out more about protocol-based authentication

We have written our own libraries and data store to handle protocol-based authentication within our DotNet core website application. Our expertise is in terms of data management and thinking about the use cases of data in terms of deciding how much to fragment the data. We wrote our framework to be extensible and more to do with writing new wrappers for individual protocols rather than trying to build an all-encompassing approach.

If you if you are interested in this approach for your own website or other authentication architectures, we can't provide consultancy to help you achieve your goals. Nothing is stopping you taking the same approach that we have undertaken for our own development, but it would make sense to work with us because we have thought through a lot of these problems to a higher level than many of the superficial approaches out there.

Written with StackEdit.