Is cybersecurity thwarting automation?
Some years back, the major music and film publishers were resisting attempts to digitise sources of entertainment by adding ever more sophisticated protection mechanisms to the media. DVD producers, for example, added encryption and restricted geographic distribution.
A similar thing is happening today to prevent unauthorised access to our data in the Cloud. The basic method of authentication is the username and password. For a remote application to validate that a password is correct, it must store a copy of the password with which to compare that entered by the person attempting to access the data. However, if the application database gets hacked, then all the users’ accounts are compromised.
One way around this is to encrypt the password before storing it. The user is validated by comparing the encrypted password entered with the stored encrypted password. By using irreversible algorithms, it is impossible to extract the passwords from a hacked password database. However, this does not stop a machine trying random (but easily guessed) passwords on thousands of accounts until one works, or a human using a plain text password they may have seen written down.
What is needed is a method to confirm that a legitimate user is attempting to log in and, arguably, that the user is human.
Increasingly, the weapon of choice is CAPTCHA (or some similar mechanism) where a user identifies features from an image. This is difficult for a machine to do.
Artificial Intelligence is about replicating what a human does and, according to Alan Turing, English mathematician and pioneer of theoretical computer science and AI, the extent to which it can make a human think they are dealing with another human.
Two factor identification can also be used to confirm the identity of the user. In this scheme, a further step is introduced to the login process, involving sending a message to another, separately authenticated account - such as by email or via SMS to a mobile phone - for confirmation.
Both methods have their merits and shortfalls, and can be used on their own or together.
However, all these schemes often disadvantage those who they are intended to help. While sometimes irritating, it is understandable due the massive amounts of computer power available simply to break authentication schemes and the significant fraudulent activity occurring with IT services.
With the advent of remote working, more of the information we use must also be accessed remotely. And the more general a service needs to be to satisfy a large user base, the more steps are required to access the information needed. The opposite extreme is the bespoke service which can be tailored to a specific customer’s needs. So, for example, if a company needs a daily report on, say, a particular stock price over a certain period, in a bespoke application, a “button” may be created to generate the report in one click. Whereas in a generic application, it is necessary to specify a range of dates, a stock symbol, a currency, and so on, inputting any of which is subject to mistakes. Combine that with the process of authenticating the user, and time taken to generate an accurate report can soon mount up.
Remembering a password can be difficult enough, but with the task of locating, say, a CAPTCHA traffic light that appears in a tiny section grid, then the overall delays in accessing that information, are compounded further. And the more frustrated we get, the more likely we become to fail the “is it a human” test - or simply give up.
Two factor authentication may not help either. Perhaps you cannot locate your phone, or access the text message without losing the context of the service you were logging into, or have difficulty in reading and transcribing the key.
Biometric authentication - for example fingerprints or facial scans - can also be problematic. It may be more convenient for the human user, but it does not solve the problem of providing secure proxy access - that is access you legitimately give to another person or machine. Increasingly, it is machine access that is required to deploy intelligent services on users’ data.
And it is not just authenticating generic services that creates an issue. In order to reduce the burden of processing the vast amount of communication – in the business world largely by email and telephone - we look to AI to tell us which messages to focus on including what is spam, or which messages involve money. But in order to process this information, the AI tool must gain access to it. Throw two factor authentication at it and a large number of useful services are immediately ruled out.
The alternative, where available, is to decline the stricter authentication procedures. It then becomes a tradeoff between the benefit of providing AI access to your data, against the risk of your account being hacked.
Service providers need to develop other ways of authenticating access to our data or authorising proxy access to others. App-specific passwords go some way towards this, but not far enough. These are passwords generated by the validated account holder for distribution to other processes or people that need to access their account. They work only for specific applications and can be revoked without affecting the main login credentials.
In the meantime, we need to think carefully about the implications of the authentication systems we choose and how we can restructure our access to IT services to minimise the risk of security breaches without preventing the automation of useful processes.
This can often be achieved by separating the data we might wish to share - for example by setting up auxiliary “less secure” accounts and store only the data we need to share. There are also ways of accessing data programmatically (for example APIs). While this may be mostly beyond the capabilities of the average computer user, a small investment in some specialist help may return a significant savings in time and benefits in security.
By John Yardley, Managing Director of Threads Software
