Remote User Authentication
Information security is essential for understanding the world, communicating with others, and protecting ourselves from deception: its principles enable us to decide which messages & information to believe or ignore. Every transaction relies on trusting relationships with identified counterparties: common interests coordinated privately, securely, and with verifiable accuracy.
The industrial revolution augmented the power of human muscle: the information revolution is augmenting the power of the human mind. In everyday life, these principles are usually applied implicitly. For our communications capabilities to be safely augmented by networked computer technology, we need a more explicit understanding of information security principles.
For privacy, availability, integrity, or confidentiality; access to information must often be restricted to specific personnel, organisations, or job-roles (or their machinery & legal agents) with a legitimate need or right to use such data: machinery & services must be designed for reliability & robustness, and protected from interference or tampering.
To obtain privacy, availability, integrity, or confidentiality:
- Server & client computers (network end-points) must be secure. It is the service provider's responsibility to secure the server. Operating systems and application software installations must be maintained (configured for security, monitored, and kept up-to-date), to prevent 3rd parties from eavesdropping via a compromised communications end-point.
- Network communication protocols must establish a secure link to the intended user, to prevent unauthorised 3rd parties from eavesdropping or modifying messages via a man-in-the-middle attack, or via shoulder-surfing/ bugging/ surveillance. End-users must be assured of the service-provider's identity, and may need assurance of transaction details.
- To decide whether to grant or deny access, computer systems must be able to identify system users and compare their privileges to the privileges required to access requested resources. Access will be granted or denied, based on models of privileges or restrictions. End-users & terminals must uniquely identify themselves to the service-provider.
- Unauthorised third parties must be prevented from impersonating privileged users: self-asserted identification must be coupled with reliable assurance, via cryptographic tokens, passwords, or biometric authentication — or a combination most appropriate for the application. Mutual authentication may be required e.g. for financial transaction details.
Potential designs for optimal security architecture may vary, depending on:
- Availability of appropriate technology for communications & data processing,
- Specific data/application security requirements (data value, disclosure contingency costs, etc.),
- Threat environment: profiles of potential attackers, and their resources & tooling.
We will now discuss some aspects of our security architecture for Web based services.
0. Securing Communications End-points/ Terminals
To ensure the security our services; we use an internet hosting supplier with a good reputation for customer service, physical security, and proactive network security administration. We monitor supplier service levels and engineer our systems to the highest possible security standards — with multiple layers of defence. In the unlikely event that our user-account database is compromised, the attackers will find that it only contains strong random passwords, salted and hashed with an appropriate password hash function: even if the attackers can guess some of the passwords, this will not help them gain access to any other systems because the passwords would be dissimilar.
To secure your communication terminal, please keep software up-to-date, use a modern device for accessing sensitive data, and only use this device with software from official repositories, to access information via reputable services.
1. Securing Communications Channels
All of our Web services use the HTTPS scheme with Transport Layer Security (TLS). The security of the communications channel is assured by secret keys used in public key cryptography protocols. We use a variety of 3rd-party services to verify that we are implementing security protocols correctly, and that our systems are engineered according to most up-to-date information on the strongest possible security engineering standards.
2. Identifying System Users + 3. Authentication
Most systems perform identification & authentication in a single step: the authenticated identity is then used to determine access to protected resources or sensitive data. Many system requirements apply to both, or the combination of these component processes. An identification+authentication system should be:
- Cheap to implement & to operate securely with unique identifiers for each end-user: good value-for-money. Substantially cheaper to defend than to attack. Authentication mechanisms must be effective against real-world threat profiles.
- Easy to use & simple to understand in its basic principles of operation—so that users might instinctively resist any attempted persuasions to diverge from secure operational procedures, because the risks would be obvious.
- Resistant to loss of identifiers by end-users. System should implement convenient mechanisms for securely retrieving lost or forgotten identifiers or authentication keys: however, these mechanisms must also be protected from abuse.
It should be inconvenient or impossible for highly privileged end-users to subvert their own security, but convenient for them to follow correct procedures: this way, when an attacker tries to persuade an end-user to help compromise their account, they will be more inclined to suspect nefarious motives and thwart the attack. Authentication & account management systems must be convenient enough for all end-users including those with minimal or nascent interest in using our services; to reduce barriers to business, improve fulfilment rates, and ensure that secure solutions succeed in a free market. Wherever we must compromise between cost, convenience, and security; it should be possible to make the system cheaper & more convenient for normal users, yet more secure for highly privileged users without compromising convenience with psychologically burdensome procedures that might distract our service users, leaving them more vulnerable to manipulation. Attackers must understand that they are wasting their time here, whereas legitimate service users must understand that doing business here is easy and beneficial — even indispensable.
Authentication Context of Remote Online Data Systems
Examples of everyday authentication include children recognising their mother's voice (biometrics), or acquaintances remotely identifying themselves to each other by communicating in ways or with details that others would not know (passwords); however, the whole point of online systems is to make it more convenient to do business across long distances without necessarily having prior contact with a counterparty: online services must usually operate in a remote authentication context without prior introduction or initialisation. Since we are authenticating the identity of a real-world principal (person or computer terminal, or combination of both), the fundamental basis of online authentication is in the real-world: a real person has a legal name, which is often documented on their passport, birth certificate, or identity card: otherwise, they are known to their friends by name, or by one or more aliases they may have been using for some time as a proxy for their real name in the social domain. Legal documents, social media accounts, witness testimony, or biometrics (or better, a corresponding combination, shared in person for the most critical access protocols), might potentially provide a strong foundation for authenticating a new user's identity henceforth across a long-distance communications network, with either a cryptographic token (something you have), or a password (something you know), or a fresh biometric signature (something you are); or a multi-factor authentication system.
Authentication Technology: Compromise between Convenience, Cost, and Security
Online banking systems typically use passwords — often, a static password combined with one that is used sparsely: random components are requested before each successful authentication, so that if an attacker intercepts the authentication form, they will only obtain a small component of the authentication credentials — whereas a different component combination will be requested next time. Using passwords alone, we must compromise between the convenience of a legimitate end-user entering a password correctly, and the probability that an attacker will be able to correctly guess a password: this compromise is best made in the context of the contingency cost or potential damage of a security breach. To simultaneously deliver convenience & security, e.g. for commercial banking customers, stronger authentication may be provided by augmenting the password with a cryptographic security token: these usually provide one-way authentication (verifying the identity of the customer or their agent to the bank), but the best systems provide mutual authentication so that transaction details (counterparties or payment recipients, and values or amounts of money) can be verified and cryptographically approved by the end-user (account principal or legal agent).
Biometric Authentication: Inappropriate for Online Security Context
Some banks are experimenting with biometric authentication, which may provide additional security assurance in multi-factor authentication based on secure hardware end-points: however, biometric authentication is particularly prone to attack by imitation, biometric credentials cannot easily be changed, and in the remote online context the service-provider lacks effective control over the security of end-user cryptographic communications terminals: in this security environment, attack/defence economics are fundamentally favourable to the attacker: therefore, this arms-race is likely to continue inconclusively for a long time to come, with many more biometric authentication systems yet to be devised, marketed, and compromised in the future. It is difficult and expensive to implement biometric technology correctly: there are many potential failure modes, whereas success requires a broad spectrum of integrated hardware, software, & communications engineering skills. The best hope for biometrics may be found in the biometric authentication features integrated into mass-market mobile devices restricted to managed software markets (malware-free app stores): with a personal mobile device that stores passwords for you, convenience is no longer a barrier: it becomes feasible for remote online end-users to secure their accounts with strong passwords, because their mobile device becomes a personal digital assistant — an extension of the trusted zone of information in their brain.
Our User Identification System
For convenience, we identify our internet service users by their email address: we assume that each end-user can & will identify themselves with a unique personal address. Where required for security, we can prevent multiple simultaneous sessions from being opened under a single user-account: we might also deliver one-time-passwords to users' mobile devices by SMS to enhance account security (user-identification assurance) by making it less convenient for end-users to inappropriately share accounts. This method of identification is economical, provides adequate security for most users & resources, and does not introduce any new barriers to initial engagement with our services: anyone capable of using our services should also be capable of acquiring & maintaining their own email account, and should be familiar with email-based management of their online user accounts. Most users are unlikely to frequently forget their email addresses because they will use and share them frequently. Other identification methods may be possible, such as mobile telephone numbers; but email is just as secure, more convenient, and less intrusive for end-users compared to SMS. Using a two-way communications channel account as a user identifier helps to make identifiers personally unique, memorable, and accurate (as validation mechanisms are provided by the communications channel, which potentially supports convenient mechanisms for account renewal or retrieval). Neither email routing protocols, nor SMS routing protocols, are completely secure: it is possible to hijack communications in transit; so some caution must be applied in designing our password retrieval protocols. Alternative & more secure channels might be considered.
Our User Authentication System
We use passwords for authentication. Normal system users are given comparatively short, convenient passwords. Privileged users are given stronger passwords. We might in future integrate Google Authenticator, U2F cryptographic tokens, PassWindow, or SMS one-time passwords for multi-factor authentication — and might use multi-channel communication.
Why can't I choose my own password? How can I remember it?
Remembering many long, random, unique passwords is difficult: so when end-users are allowed to choose their own passwords, they often choose guessable passwords, or choose similar passwords for multiple online service accounts including systems outside of our control which frequently store passwords insecurely. Online service systems are often compromised, enabling attackers to break in to any other systems where similar user authentication credentials (identifiers+passwords) have been used. To protect our user accounts from being compromised in this way, we give strong random passwords to our users so that attackers cannot easily break in by using authentication credentials stolen from elsewhere or by guessing passwords. Therefore it is not possible for our users to choose their own passwords. We encourage our service users to store passwords in their Web browser: let the built-in password-manager in Google Chrome, Apple Safari, or Mozilla Firefox remember your password for future visits, next time you log in to our Web site.
What are we authenticating, and Why?
Our objectives vary depending on how you interact with our services.
- For normal end-users who simply need to get work done here without interacting with others in any way that requires the use of their legal name (e.g. to access information belonging to other data-subjects); technically speaking: we only need to know that the data-subject or data-source can access their own data on subsequent visits, whereas other users or unauthenticated visitors cannot — unless they have a legitimate reason to access those data, in order to service the data subject's needs. To support this policy, we only need to authenticate continuity of end-user identity across internet browsing sessions: provided the end-user is keeping all of our other rules, we wouldn't actually need to know this person's legal identity. To avoid confusion, to engender trust & transparency, and to support account recovery procedures; we encourage people to use their real legal official identity — but for mutual convenience, we will trust the new user's declaration of identity but exercise caution in relation to potential for namesakes and deception.
- For privileged users who need to access information about other data subjects who are interacting with our services (or with third-party services we are hosting & supporting); we require a higher standard of authentication. User accounts are created during face-to-face meetings in which the identity of the user-account holders is known: further face-to-face meetings establish a chain/hierarchy of trust w.r.t. the identity of the people using our systems. Future authenticated sessions are identifiable as theirs, and interactions with data (e.g. reading, modifying or deleting information) will create an auditable trail of evidence (metadata) that we can use to ensure/certify that we are fulfilling our data protection obligations, or to support enforcement actions where policies are being breached.
Normal end-users whose privileges are elevated may need to upgrade their authentication credentials: elevated privileges may only be granted during a face-to-face or telephone meeting to verify account control, and a stronger password may be issued before the user logs in again. Ideally, there should be (as on certain social media Web sites), a visible difference between an account controlled by a person with a Verified legal identity, and an account controlled by an unknown person — with identity bootstrapped only by email account control.
What will we know when a visitor has successfully authenticated?
- Normal end-users: The remote person knew, or was able to obtain or guess, the identification+authentication credentials (passwords etc.) of the person/machine with whom we previously negotiated these credentials. If identification+authentication credentials have not been compromised, then we can state with a high degree of probability (according to authentication strength) that the counterparty principal (person/machine) communicating with us is the same as before.
- Privileged end-users: Same as Point 1. We also still know that the person with whom we originally negotiated these credentials is the legal person (identity) previously certified.