In any application like Threads which accesses user messages (eg email) on a user’s behalf there is always the issue of security. How can Threads collect a user’s email on a user’s behalf without knowing the user’s authentication credentials – user name and password? And in sharing this information, is there not a potential security risk?
The risk of sharing passwords
Well, as with everything, there is a security risk, but it helps to understand what is going on to minimise that risk. Any service provider that tells you there is never any security risk, is misleading you.
But there is more than one way to skin a cat and we have a web page which explains Threads privacy and security mechanisms in some more technical detail. This blog hopefully provides a less technical description of the issues and how Threads deals with them.
But before discussing the security mechanisms, it helps to get the issues in context.
Why pick on Threads?
First of all, a great many companies make use of cloud-based spam filters. Although these companies are rightly concerned about their data security, they completely forget that every single item of email is read and analysed before it ever gets to their employees. In order to be an effective spam filter, it needs to establish not only the origin of the email but the content too.
However, spam-filtering service providers will rarely, if ever ask for user’s login credentials. The reason for this is they do not need to because they intercept every email before it even goes to the user. To do this they need the privilege, and this must be given to them by an employee of the subscribing company. This is usually a technical person rather than someone in a managerial position and it trumps any other mechanisms that might be in place for protection of email.
So do not think that because you have not given out your login credentials, your emails are read only by you.
No such thing as a free lunch
The second common scenario, applies to companies that use free email servers such as gmail, yahoo, hotmail, etc. There is no such thing as a free lunch, and these service providers have to make money somehow. The way they achieve this is sell information extracted from the content of their users’ emails. This information is mostly “pseudo anonymised” so that, in the form that it is sold, it cannot be traced back to any one individual.
But if ever you have wondered why you are hit with advertisements selling products meeting a need you have mentioned in a recent email, now you know why. You may wonder if this is, if not illegal, somewhat unprofessional, but the fact of the matter is that the customer agrees to this when accepting the terms and conditions of the email service provider.
Unfortunately, many customers either do not read the terms and conditions, or otherwise, think this is a fair price to pay for free email.
This also applies to paid services but the difference is that if you are paying for a service, in most countries you get better protection under law than if the service is free. Furthermore, both free and paid email servers often incorporate spam-filters. These are another potential data leak.
Pushing and pulling
When Threads was first launched, the only way we supported ingestion of the subscriber’s email was by requiring the subscriber to push any emails into an auxiliary email account which was set up purely for the purpose of feeding Threads. In this scheme, the subscriber “copies” only those emails wanted, and Threads needs no access to individual user accounts.
The term copy is used here to denote moving an email from one account to another while leaving the original email in place and not changing the email header in any way. The copy process can be achieved by manually dragging emails, by setting up a “rule’ to do it automatically, or by using a service (for example MigrationWiz) to bulk copy emails.
Unfortunately, not all service providers use the term “copy” consistently in their rules. Google, for example, describes copying as forwarding even though in general nomenclature, forwarding involves changing the message header so that the message sender is no longer the original sender but the user that forwarded the message. Care should be taken when setting up the rule to ensure the desired result is achieved.
Strangely, very few customers wanted to push their messages to Threads, instead preferring to provide Threads with authentication details so that Threads could pull emails directly from user accounts.
We still support both pushing and pulling and indeed, recommend message pushing. So if you want to keep your individual account credentials secret, pushed ingestion is one way to do it.
App-specific passwords
Most of the popular email servers support a feature called app-specific passwords. In this scheme, individual users may obtain passwords in addition to their main password that they may share with trusted applications, such as Threads. Although these app-specific passwords give trusted applications full access to the user’s email, they can be rescinded at any time without the need to change the mail password.
More significantly, the main security benefit of an app-specific password is that its use is limited to the first application that uses it. So once the app-password is used by Threads, no other program can use it. This gives subscribers the peace of mind that, in the event that some malicious person gets hold of the app-specific password after Threads has used it, that person would be unable to use it.
Many of our customers use Threads for the once-off synchronisation of historic email. Once the synchronisation is complete, Threads has done its job and sadly, no longer needed. This is a common use case for app-specific passwords.
Personal authentication
For many customers, the benefits of pulled ingestion outweigh the security risks that come with it. But arguably, it is a greater risk in sharing authentication details with the employee designated as the Threads Administrator, than if they were shared only with Threads.
In the latest implementation of the Threads Administration App, administrators can request Threads to obtain account authentication details directly from the user rather than share them with the Administrator.
Multi-factor authentication
Many Cloud services now support something called Multi-Factor authentication (MFA). In this scheme, the familiar username/password login mechanism requires an extra level of authentication using a channel other than the application UI itself.
When the user attempts to log in, the application sends the user a special code via an email or SMS message. This code must be typed in to complete the authentication. The rationale behind this is that although a hacker may be able to discover a username/password, he/she will not be able to intercept the user’s email or SMS account.
There are other factors that can be used rather than or as well as codes – for example biometric information (eg finger prints, face scans, etc) or “certificates” which are electronic keys, if you will, that can be used as an extra level of security.
These types of authentication are difficult for automatic services like Threads to handle because they generally involve manual intervention by the user. Clearly, this is impractical when ingesting varying numbers of messages at random times of the day. Hence services that are not interactive, allow other forms of authentication.