In this blog we discuss the key security features of Threads and how we are working to keep your data safe.
Background
Threads is a web application we describe as a message hub. Its main task is to collect digital messages on behalf of Threads users and process them. These messages can be emails or digitised telephone calls or indeed any type of digital message.
There are several ways of processing a message. For example:
- You can simply store the message in a database to search and share it among authorised users; or
- You can perform some intelligent operation on the message – such as converting acoustic speech into text.
Threads works by automatically collecting messages on behalf of Threads users. We call this process ingestion.
However the ingestion process can give rise to various security issues which we discuss in this blog.
Storing digital messages
Before a user’s digital messages reach Threads, they will generally be stored in a Cloud database hosted by the service provider – e.g. Apple, Microsoft, Google, etc.
This will be similar for most forms of message (e.g. emails and phone calls). However- the method of access will depend on the type of message. For example, it is not possible to read an email in the same way as a telephone call.
The idea of the Threads is to hide the user from the different access methods and accounts so that all of your messages can be accessed via a single login.
It does not matter whether the message is an email or phone call. Nor which accounts has received the message. You can access all the messages via a single login. Indeed, using the same login, accounts from many different Threads users may be accessed.
Two Factor Authentication (2FA)
This aggregation of messages however gives rise to a potential critical security path. By accessing multiple accounts with one login, the individual credentials have been replaced by one. Losing the credential to a single account is less damaging than losing the credentials to several accounts at once.
This, of course, is a two-edged sword. Users are faced with the problem of remembering many different usernames and passwords. Users are also often lax about securing them either by writing them down or using easily guessed combinations.
This is a standard problem but there are already solutions that allow users to store all their credentials in one place using a single login. For example, Apple uses the “Keychain” application. There are also specific applications such as 1Password and Dashlane. They all have a single password vulnerability.
Two Factor Authentication (or 2FA for short) is the most common method to mitigate the risk of losing a master username/password.
Under this scheme, a user must authenticate the login using a separate “channel” independent of the application. This could be an SMS message or email. When the user attempts to log in, the application sends a unique key to the user which the user types in as part of the login process.
If an illicit user has discovered the real user’s login credentials, he/she would also need access to the user’s email account or mobile phone to complete the login.
Threads adopts the 2FA security method.
Pushed Ingestion, App-specific Passwords and Open Authentication (OAuth)
In order for Threads to act on behalf of each user, it needs the user’s authentication credentials. This means the username and password for each account accessed. Rightly, many users are reluctant to divulge this information to a third-party service provider.
One way to overcome this, in the case of emails, is to have a separate email account for holding ingested emails. We call this pushed ingestion. We discuss this in detail in this blog post.
However, pushed ingestion involves setting up rules for each email account to transfer emails from the user email account to the Threads holding account. Some users will find this inconvenient.
The second way is to use an app-specific password. In this scheme, the user requests from the application to which Threads needs access, password specifically for Threads. The user enters this when setting up the ingestion account. Threads has the same access privileges as the user, and the user can revoke these at any time. Most importantly this does not affect the user’s own credentials.
The third way is to use Open Authentication or OAuth. The large messaging service providers (including Microsoft) support this service. OAuth behaves in much the same way as app-specific passwords except that there is no need for the user to manually transfer the password to Threads. This makes the process much simpler and the password less vulnerable to exposure. A dedicated Authorisation Server performs this operation.
Threads supports all three methods.