GB2582180A

GB2582180A - Distributed authentication

Info

Publication number: GB2582180A
Application number: GB1903561.7A
Authority: GB
Inventors: Urgero Michael; Watts Stephen
Original assignee: Securenvoy Ltd
Current assignee: Securenvoy Ltd
Priority date: 2019-03-15
Filing date: 2019-03-15
Publication date: 2020-09-16
Also published as: GB201903561D0

Abstract

The present disclosure relates to systems and methods for authenticating a user request to access a resource. The system comprises a central server 101 arranged to maintain validation information associated with a plurality of users and send updated validation information to one or more resource servers 109a-d. Upon receipt of an access request, a first resource server 109a authenticates the request. After a successful authentication, the first resource server requests validation of the user from a second resource server 109b-d. The second resource server is arranged to receive a validation request from the first resource server, validate the user and upon positive validation, send confirmation that he user has been validated back to the first resource server 109a. If a user is successfully validated, the access request may be granted. Upon receiving the positive validation of the user, the first resource server may be arranged to send confirmation that the user has been authenticated to the central server. In some embodiments a unique identifier is associated with each user wherein each of user’s access requests may be hashed together to create an immutable ledger.

Description

DISTRIBUTED AUTHENTICATION

FIELD OF THE DISCLOSURE

Embodiments of the present disclosure relate generally to a method of authenticating a user attempting to access a resource. More specifically they relate to a method of providing increased security in the authentication process.

BACKGROUND OF THE DISCLOSURE

The process of authenticating a user largely involves two entities: the user itself; and a service provider from which the user is requesting a service. In this manner, when a user wishes to gain access to a resource (such as a website, or their digital work environment) the user provides a username and password which are authenticated by the service provider or an associated authentication entity. Upon successful authentication of the username and password, the user provides a one-time passcode (OTP) to the service provider, which is also authenticated, to increase the service provider's confidence that the user is who they say they are.

Commonly, service providers do not maintain the authentication programs within the servers used to provide a service or resource. Instead, a third party provides and maintains the authentication program, in order to ensure that security is always kept at a high standard. These third parties generally support multiple service providers across a plurality of sites.

SUMMARY OF THE DISCLOSURE

In order to solve the problems associated with the prior art, the present disclosure provides a first aspect in which a distributed authentication system comprises: a central server, arranged to maintain validation information associated with a plurality of users and send updated validation information to one or more resource servers of a plurality of resource servers; a first resource server of the plurality of resource servers, arranged to authenticate an access request received from a user of the plurality of users and, upon a positive authentication of the user, request validation of the user; and a second resource server of the plurality of resource servers, arranged to receive a validation request from the first resource server, validate the user and, upon a positive validation of the user, send confirmation that the user has been validated to the first resource server.

According to a second aspect, there is provided a method of authentication within a distributed authentication system, the distributed authentication system comprising a plurality of resource servers, each resource server storing replicated validation information associated with a plurality of users, wherein the method comprises: receiving, at a first resource server of the plurality of resource servers and from a first user of the plurality of users, an access request, the access request comprising a first authentication factor; authenticating the first authentication factor; in response to a positive authentication of the first authentication factor, sending, to a second resource server of the plurality of resource servers, a validation request, the validation request comprising at least a portion of the validation information; receiving, from the second validation entity, confirmation that the first user has been validated; and granting the access request.

According to a third aspect, there is provided a distributed authentication system comprising: one or more processors; and at least one computer-readable storage medium, the computer-readable storage medium storing instructions that, when executed, cause the one or more processors to perform a method according to the second aspect, described above.

According to a fourth aspect, there is provided an authentication apparatus for authentication within a distributed authentication system, the distributed authentication system comprising a plurality of resource servers, each resource server storing replicated validation information associated with a plurality of users, the authentication server comprising computer-readable instructions that, when executed, cause the device to: receive, from a first user of a plurality of users, an access request, the access request comprising a first authentication factor; authenticate the first authentication factor; in response to a positive authentication of the first authentication factor, send, to at least one resource server, a validation request, the validation request comprising at least a portion of the validation information; receive, from the at least one resource server, confirmation that the first user has been validated; and grant the access request.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure will now be described, by way of example only, and with reference to the accompanying drawings, in which: FIGURE 1 shows an authentication system in accordance with an embodiment of the present disclosure; FIGURE 2 is a flow diagram detailing a method performed by the authentication system of Figure 1; and FIGURE 3 is a flow diagram detailing a further method performed by an authentication entity in accordance with the present disclosure.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

The present disclosure relates to a method of authenticating a user in a distributed authentication system. A central server maintains a database of validation information relating to a plurality of resource servers which are generally separate from each other, in that they do not interact with each outside of the present disclosure. The validation information is distributed among the resource servers to be used when a user requests access to a resource (e.g., a website, a work computer etc.) at one of those resource servers.

During normal use, a user will request access to a resource held by one of the resource servers. This resource server will perform a local authentication of the credentials provided by the user. If the user's credentials are successfully locally authenticated, the resource server which performed the local authentication will then communicate with other resource servers in order to request that they validate that the user's account is in good standing.

If the user's account is successfully validated, then the user is granted access to the resource.

Once a user access request has terminated (either by granting or denying the access request) information relating to the access request is sent to the central server, which updates the validation information. After the central server has updated the validation information, it redistributes the updated information to each of the resource servers to be used when a further access request is received from the same or another user of the system.

In the above manner, the disclosure provides a means of double checking an authentication instance to ensure security. If a validation request fails, this indicates that the user account and/or the resource server has been compromised. Therefore, a failed validation not only prevents access to a resource for a disingenuous entity, but can alert the owner of a resource server of the existence of a compromised account or server.

With reference to Figure 1, there is shown a distributed authentication system 100. A central server 101, ads as a centralised authority regarding the initiation and maintenance of the distributed authentication system 100. In setting up the system, the central server 101 produces a database of encrypted user information to be distributed, also referred to herein as validation information. For each user of the distributed authentication system 100, the validation information comprises an encrypted user ID and an associated unique identifier. This information will then be used to validate each user whenever that user makes an access request. The validation information may be distributed in a number of different ways. In the present example, the validation information is distributed by means of the Internet, however, other networks, such as Local Area Networks or private networks, may be used to distribute the validation information.

The distributed authentication system 100 also comprises a plurality of resource servers 109a-d arranged to act as an authentication entity 102 or a validation entity 103, depending on the system's needs. The resource servers 109a-d each maintain local authentication information related to the users associated with that resource server 109a-d. For example, the resource server 109a of premises A may maintain username and password information related to a plurality of employees who require access to that resource server's network. Further, the resource server 109b of premises B may maintain username and password information related to a different plurality of users who have accounts stored on the resource server 109b of premises B. The locally stored user information may relate to any number of users and any purpose.

The resource servers 109a-d may maintain the local authentication information in any manner. In the present example, each resource server 109a-d further comprises a Virtual Security Appliance (VSA) 104 which further comprises Microsoft ® Active Directory (MAD) 105. The MAD 105 ensures that the username and password information associated with each user 106 is locally and securely maintained. Of course, alternative methods may be used for storing and accessing authentication information.

A VSA 104 is a digital appliance which runs inside a virtual environment, for example, a server. The VSA 104 is pre-packaged with a hardened (more secure) operating system and a security application which run in the virtual environment to provide a highly secure data store. The MAD 105 is an example of a service which is capable of authenticating and authorising users and computers in a domain-type network which, in the present example, is securely located within the VSA 104.

The distributed authentication system 100 also comprises a number of user devices 107, 108, through which a user 106 is able to request access to a resource maintained by one of the resource servers 109a-d. Typically, each user 106 will only interact with one resource server 109a-d of the plurality of resource servers 109a-d. However, it is also possible that a user 106 will interact with more than one of the plurality of resource servers 109a-d at different times.

With reference to Figure 2, there is now described a method of authenticating a user 106 within the distributed authentication system 100 of Figure 1. As described above, at a first step 201, the central server 101 produces validation information comprising encrypted user IDs and unique identifiers associated with each user 106 of the distributed authentication system 100. The central server 101 receives each user ID from each respective resource server 109a-d as they join the system 100. The central server 101 then creates the unique identifier associated with each user 106.

In some embodiments, the unique identifier is formed based on information specifically related to the user account, such as the user ID and access request details. For example, the unique identifier may comprise a hash of the user ID and a time and date of the last access request (time stamp). Each time a user 106 request access to a resource, the validation information can be updated with this information. In this manner, the unique identifier associated with the user inherently contains information detailing at least the last log in time and is also changed each time the user 106 requests access to a resource.

The validation information may also comprise the time stamp information to be checked during validation.

In embodiments wherein the unique identifier is formed of user access request information, the unique identifier may comprise a hash of all the access request information ever created for that user. Every time a user requests access to a resource, the validation information is then updated with a new unique identifier for that user 106, wherein information related to the most recent access request is hashed together with all previous access request information to form a new unique identifier. As such, the unique identifier may form a kind of immutable ledger, containing information relating to all access requests by the user.

At step 202, the central server 101 encrypts and distributes the validation information to each of the resource servers 109a-d associated with the premises A, B, C, D subscribed to the distributed authentication service. Each resource server 109a-d then stores this information for use during an authentication instance, either when acting as an authentication entity 102 or when acting as a validation entity 103. The validation information is stored, within each resource server 109a-d, within the MAD 105 within the VSA 104. The central server 101 also provides each resource server 109a-d with communication information. This communication information indicates to each resource server 109a-d which other resource servers 109a-d should be contacted when a user 106 needs to be validated. The communication information contains no more information than is necessary for one resource server 109a-d to contact another resource server 109a-d.

In this manner, an administrator of any one of the resource servers 109a-d is not provided with personal data as to the real-word location or owner of the other resource servers 109a-d.

At step 203, a first resource server 109a, receives an access request from a first user 106.

In receiving an access request, the first resource server 109a takes on the role of an authentication entity 102. The access request may be a request to gain access to a network or resource, or may be a request for information or any other kind of request for which a user 106 may need to provide authentication information.

Of course, the access request may be received by any of the resource servers 109a-d found within the distributed authentication system 100. In this manner, any of those servers may, at different points in time, take on the role of authentication entity 102. Similarly, with one resource server 109a-d acting as an authentication entity 102, any of the remaining servers 109a-d may take on a corresponding role as a validation entity 103.

The authentication entity 102, in order to decide whether to allow the access request, must then proceed with authenticating the user 106.

In general, there are several ways that a user can prove (with evidence) that they are who they say they are. Each type of authentication factor can be roughly defined as being one of three factors: something you know (e.g., a user ID, a password etc.); something you own (e.g., a mobile phone, a token generator etc.); and something you are (e.g., biometric information such as a finger print or facial recognition). In multifactor authentication, MFA, systems, a user attempting to gain access to a resource is asked to provide at least two different factors in order to confirm that the access attempt is genuine.

In this sense, an authentication factor may not be the evidence itself, but an indication that the required evidence has been provided. For example, a user may not provide an image of their fingerprint to an entity requesting authentication. Instead, a fingerprint scanning device may provide confirmation that a fingerprint scanned by the device matches a fingerprint image in a local database. This confirmation may form an authentication factor which is sent between entities. Alternatively, a user may input a secret password/PIN at a local device. The local device may encrypt the secret password/PIN and send the encrypted information to another entity for comparison with a stored encrypted password/PIN.

As such, although authentication factors are generally considered to be one of: something you know; something you own; or something you are, in the present context, an authentication factor may also include data indicating that such information has been provided to an entity capable of authenticating an authentication factor.

In line with the above, the authentication entity 102 requires an authentication factor from the user 106 in order to begin authentication. The authentication factor may be provided in conjunction with the initial access request. Alternatively, the authentication factor may be provided by the user 106 once the authentication entity 102 has prompted the user 106 for it.

Similarly, the authentication factor may be sent, by the user 106, using any kind of network connected device, such as a mobile phone 107 or a computer 108.

In the present example, the user 106, in conjunction with the initial access request, sends a user ID and password to the authentication entity 102 via means of a computer 108. At step 204, the authentication entity authenticates the user ID and password against a corresponding data entry in the MAD 105 stored in the VSA 104.

If the user ID and password provided by the user 106 match an entry in the MAD 105, the user proceeds with step 205. Alternatively, if the user ID and/or password do not match a corresponding entry in the MAD 105, then the authentication entity 102 returns to step 203, wherein the user 106 is informed at the computer 108 that the user ID and/or password is incorrect and must provide the user ID and/or password again.

At step 205, the authentication entity 102 (the first resource server 109a) contacts one or more validation entities 103 (other resource servers 109b-d) in order to begin validation of the user 106. A request to validate a user 106 must, of course, include some form of means of identifying the user 106. In the present example, the user ID, provided by the user 106, is encrypted and sent to the one or more validation entities 103. In encrypting the validation request in the correct manner, the authentication entity 102 confirms to the validations entities 103 that it is acting in accordance with a distributed authentication protocol of the system 100, from which the validation entities 103 can infer that the authentication entity 102 is not compromised. If a request to validate a user 106 is not properly encrypted, for example, because a disingenuous entity does not have the encryption key, then the validation entities 103 will reject the validation request.

In some embodiments, the authentication entity 102 may also provide the unique identifier associated with the encrypted user ID found in the validation information. In these embodiments, the authentication entity 102 provides the unique identifier to the one or more validation entities 103 in conjunction with the encrypted user ID. This provides the advantage of increasing the security of the present system 100, as will be explained below.

It is also possible for the password provided by the user 106 to be sent to the one or more validation entities 103. However, clearly, in the interest of improved security, it is preferable that a user's password is never sent to external entities, encrypted or otherwise. As such, in the present example, the user's password is not sent to the validation entity 103.

The number of validation entities 103 contacted by the authentication entity will depend upon the level of validation required by the system 100, the user 106 and/or the authentication entity 102. Validation by only one validation entity 103 will be quicker, but less secure. Whereas validation by three validation entities 103 will be slower but more secure.

The number of validation entities 102 to be contacted by the authentication entity 103 is configured when the system 100 is set up. The central server 101 provides information to each resource server 109a-d which details the validation entities they are to contact during their respective local authentication instances. For example, the resource server 109a at premises A may be set up such that validation is only required by the resource server 109b located at premises B. In this same example, the resource server 109c at premises C may be set up such that, when it performs local authentication, it is required to request validation by each of the resource servers 109a, 109b and 109d located at premises A, B and D respectively.

In the present example, validation of the user 106 only requires validation by a single validation entity 103, however, it is to be understood that any number of validation entities 103 may be used to validate the user 106.

At step 206, upon receiving the request to validate the user 106, the validation entity 103 locates the locally stored validation information and compares the received encrypted user ID with the locally stored user ID within the validation information. In order to perform the comparison, the validation entity 103 decrypts the received information and decrypts the locally stored validation information. If the received information matches the validation information stored locally at the validation entity 103, then it is assumed that the user 106 is genuine. The received user ID being found in the locally stored validation information indicates that the user's account is active and in good standing (i.e. not compromised). If the user's information is not found in the validation information, it is assumed that the user is disingenuous and the validation attempt fails.

In embodiments wherein the unique identifier is also provided to the validation entity 103, the validation entity 103 also compares the received unique identifier with a unique identifier stored locally in the validation information. Comparing these values provides a higher level of scrutiny in the validation process. In embodiments in which the unique identify is formed of the user's access request(s), the authentication entity 102 must provide the most up-to-date validation information (including the unique identifier) in order for the user 106 to be successfully validated. In this manner, if the authentication entity 102 has fallen out of synchronisation with the other members 103 of the distributed authentication system 100, then it will not be possible to validate any users 106 requesting access through that entity 102.

An authentication entity 102 may fall out of synchronisation with the other members 103 on a temporary basis if it is restarted or simply switched off. This can be corrected within a short period of the authentication entity 102 reconnecting to the Internet. Alternatively, the authentication entity 102 may become desynchronised if it is compromised or tampered with.

At step 207, the validation entity 103 informs the authentication entity 102 as to the outcome of the validation attempt. If the validation of the user 106 was successful, then the authentication entity 102 proceeds with responding to the access request. If the validation of the user 106 failed, a system administrator will have control over whether the authentication entity 102 is warned of the failure or whether the process is simply halted altogether. In one example, the authentication entity 102 is warned of the validation failure, at which point the authentication entity 102 is required to request validation of the user 106 again at step 205. In another example, the validation entity 103 simply informs the authentication entity 102 that the process has been terminated.

In the event of successful validation of the user 106 by the validation entity 103, the authentication entity 102 may immediately grant the user's access request. This would occur in the case where, for example, the resource server 109a located at premises A only requires a single authentication factor in order to enable access to a resource. In other situations, and in the present example, validation of the user 106 represents the end of the authentication of a first authentication factor provided by the user 106, and the beginning of a second authentication factor step.

In the present example, the resource server 109a at premises A requires multifactor authentication of a user 106 in order to grant a resource access request. As such, once the user has been validated by the validation entity 103, the authentication entity 102 proceeds with authentication of a user's second authentication factor. In this example, at step 208, the authentication entity 102 provides a one-time passcode (OTP) to a mobile device 107, which is assumed to be in the possession of the user 106.

At step 209, the user 106 receives the OTP at the mobile device 107. Then, at step 210, the user 106 provides the OTP back to the authentication entity 102 through the computer 108. In performing this step, the user 106 proves ownership of the mobile device 107 and provides further evidence that the user 106 is genuine.

At step 211, the authentication entity 102 authenticates the second authentication factor by checking that the OTP received from the computer 108 is the same as the OTP sent to the mobile device 107. If the two codes match, at step 212, the user is granted access to the resource. If the two codes do not match, the user 106 is informed, via the computer 108, that the second authentication factor was incorrect and then asked to try again.

Although the above example describes a second authentication factor based around the provision of an OTP, it is to be understood that other authentication factors may be provided as a second (or first) authentication factor, such as biometric information.

After a successful access request, the authentication entity 103 informs the central server 101 that a successful access request has occurred. The message to the central server 101 should contain an encrypted version of the information in its current form and an encrypted version of the updates to be made. In this manner, only a genuine entity with knowledge of the encryption key will be able to enable updates to the validation information. In response to receiving a genuine request to update the validation information, the central server 101 generates a new unique identifier for the corresponding user 106. After generating the new unique identifier, the central server 101 adds it to the validation information and then sends the encrypted updated validation information to each of the resource servers 109a-d for use in further authentication instances.

As discussed above, the unique identifier may be formed as a hash of the information detailing all of a user's 106 previous access requests. Each time the user requests access to a resource, the central server 101 produces a new hash of the data, including the latest access request. If any information relating to the user's access requests within the validation information is changed at one server 109a-d, then the hash of that data will not match the hash of the data stored at another server 109a-d and it will become clear that the data has been compromised. The central server 101 acts as a centralised authority in the distribution of the validation information. Each of the resource servers 109a-d act as slave members of the network, simply providing reference points for the validation information and requesting updates to the validation information upon successful authentication instances.

In this network, were a disingenuous entity to attempt to portray themselves as a genuine user 106, they would be required to modify the validation information at all locations in order to add themselves to it. If the disingenuous entity did not do this, but instead amended only the validation information at one resource server, for example, the first resource server 109a (located at premises A), the validation information stored at the central server 101 and each of the other resource servers 109b-d (those located at premises B, C, and D) would contain differing information. Therefore, any attempt along these lines would be easily identified and would not be validated, thus, the disingenuous request would fail.

Further, if a disingenuous entity attempted to request an update to the validation information without knowledge of the encryption key, the request would fail, as an update request requires an encrypted version of the current validation information as proof that the request is genuine.

With reference to Figure 3, there is shown a flow diagram detailing a method as performed by the authentication entity 102. The method of Figure 3 is largely as described with reference to Figure 2, however, Figure 3 details only those steps performed by the authentication entity 102.

At step 301, the authentication entity 102 receives an access request from a user 106. As with the above, the access request may contain an authentication factor or the user 106 may provide an authentication factor upon a request from the authentication entity 102.

At step 302, the authentication entity 102 authenticates the user's first authentication factor. In the present example, as an authentication factor, the user 106 provides a user ID and password. However, the authentication factor may also comprise any form of information which indicates something that the user knows, something that the user owns, or some form of biometric information of the user 106.

In performing step 302, the authentication entity 102 checks the user ID and password information against data stored in the MAD located in the VSA. If the received information matches the stored information, then the user 106 is successfully authenticated and the process moves on to step 304. If the received information does not match the stored information, then the authentication attempt fails, and the process returns to step 301, in which the user 106 is required to provide the first authentication factor again.

At step 304, after successfully authenticating the user 106, the authentication entity 102 encrypts the user ID and provides the encrypted data to one or more validation entities 103. Of course, the user ID is not required to be encrypted before being sent to the one or more validation entities, this step simply improves the security of the system by avoiding sending any form of user data in plain text and proving knowledge of the encryption key by the authentication entity 102.

As set out above, the authentication entity 102 may also provide a unique identifier in combination with the user ID, in order that the unique identifier can improve validation of the user 106.

At step 305, the authentication entity 102 receives a communication from the one or more validation entities relating to the validation attempt. If the one or more validation entities successfully validated the user 106, then the authentication entity is enabled to proceed to step 306. If the one or more validation entities were unable to validate the user 106, then the process moves back to step 301, wherein the user 106 is required to provide a user ID which can be validated. Failure of the validation attempt will also be logged at the authentication entity 102 and the validation entity 103. In one embodiment, the failure of a validation attempt is communicated to the central server 101, which includes this information in the validation information. In this manner, the validation information will comprise logs of failed access requests, indicating users/entities which may be compromised. The logs may also comprise a list of successful access requests in combination with the failed requests.

At step 306, the authentication entity 102 grants the user's access request. In this example, the authentication entity 102 only requires authentication of a single authentication factor in order to proceed with granting an access request. However, as with the above, the authentication entity may require authentication of a second authentication factor in order to grant an access request. In MFA environments, the authentication entity 102 may proceed with enabling receipt of a second authentication factor at step 306, instead of simply granting the access request.

After the authentication procedure has been completed, the authentication entity 102 provides, to the central server 101, an encrypted version of the user's current validation information along with a request to update that information based on the most recent authentication instance. In response, the authentication entity 102 receives the encrypted updated information, for use in further authentication instances.

It is to be appreciated that the servers 101, 109a-d may be physical servers, virtual servers or any other type of server. Further, the signal transmitted between the servers 101, 109a-d and/or the user devices 107, 108 may be electrical, or alternatively, there may be a transmitter and a receiver arrangement, such that the information may be sent via Bluetooth ®, RF signal, WiFi ® or any other type of wireless transmission means.

The skilled person will also realise that steps of various above-described methods can be performed by programmed computers. Accordingly the above-mentioned embodiments should be understood to cover storage devices containing machine-executable or computer-executable instructions to perform some or all of the steps of the above-described methods. The embodiments are also intended to cover computers programmed to perform the steps of the above-described methods.

The functionality of the elements shown in the Figures can be provided using either dedicated hardware and/or software. The expressions "processing", "processing means" and "processing module" can include, but is not limited to, any of digital signal processor (DSPs) hardware, network processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), read only memories (ROMs) for storing software, random access memories (RAMs), and non-volatile storage.

The above embodiments describe one way of implementing the present disclosure. It will be appreciated that modifications of the features of the above embodiments are possible within the scope of the independent claims. For example, the methods described herein may be applied to any kind of distributed network. The features of the central server 101 and resource servers 109a-d described herein are for example only and should not be seen as limiting to the claimed disclosure. For example, the resource servers 109a-d are described as being associated with separate premises A-D, however, the resource servers 109a-d may be located at the same premises. The present disclosure requires only that the resource servers 109a-d are operated independently of each other outside of the

present disclosure.

Features of the present disclosure are defined in the appended claims. While particular combinations of features have been presented in the claims, it will be appreciated that other combinations, such as those provided above, may be used.

Claims

Claims 1. A distributed authentication system, comprising: a central server, arranged to maintain validation information associated with a plurality of users and send updated validation information to one or more resource servers of a plurality of resource servers; a first resource server of the plurality of resource servers, arranged to authenticate an access request received from a user of the plurality of users and, upon a positive authentication of the user, request validation of the user; and a second resource server of the plurality of resource servers, arranged to receive a validation request from the first resource server, validate the user and, upon a positive validation of the user, send confirmation that the user has been validated to the first resource server.
2. The distributed system of claim 1, wherein, upon receiving the positive validation of the user, the first resource server is arranged to send, to the central server, confirmation that the user has been authenticated.
3. The distributed system of claim 2, wherein, upon receiving the confirmation that the user has been authenticated, the central sever is arranged to update the validation information and send the updated validation information to the one or more resource servers.
4. A method of authentication within a distributed authentication system, the distributed authentication system comprising a plurality of resource servers, each resource server storing replicated validation information associated with a plurality of users, wherein the method comprises: receiving, at a first resource server of the plurality of resource servers and from a first user of the plurality of users, an access request, the access request comprising a first authentication factor; authenticating the first authentication factor; in response to a positive authentication of the first authentication factor, sending, to a second resource server of the plurality of resource servers, a validation request, the validation request comprising at least a portion of the validation information; receiving, from the second validation entity, confirmation that the first user has been validated; and granting the access request.
5. The method of claim 4, wherein each resource server of the plurality of resource servers is associated with a respective network, separate from each other.
6. The method of claim 5, wherein each respective network is associated with a respective user premises.
7. The method of any of claims 4 to 6, wherein the method further comprises: sending, to the first user, confirmation that the first user has been validated; and receiving, from the first user, a second authentication factor.
8. The method of claim 7, wherein the access request and the second authentication factor are received via a first communication channel and wherein confirmation that the first user has been validated is sent to the user via a second communication channel, different from the first communication channel.
9. The method of either of claims 7 or 8, wherein sending, to the first user, confirmation that the first user has been validated comprises sending a one-time passcode to the first user.
10. The method of any of claims 4 to 9, wherein the validation information comprises a plurality of user IDs associated with the plurality of users, and wherein the method further comprises: retrieving, from the validation information, a first user ID associated with the first user.
11. The method of any of claims 4 to 10, wherein the method further comprises: receiving, from a central server, the validation information.
12. The method of claim 11, wherein the method further comprises: sending, to the central server, confirmation that the user has been validated; and receiving, from the central server, updated validation information.
13. The method of any of claims 4 to 12, wherein the method further comprises: receiving, from a central server, communication information, the communication information indicating means of contacting the at least one validation entity.
14. A distributed authentication system comprising: one or more processors; and at least one computer-readable storage medium, the computer-readable storage medium storing instructions that, when executed, cause the one or more processors to perform a method according to any one of claims 1 to 13.
15. An authentication apparatus for authentication within a distributed authentication system, the distributed authentication system comprising a plurality of resource servers, each resource server storing replicated validation information associated with a plurality of users, the authentication server comprising computer-readable instructions that, when executed, cause the device to: receive, from a first user of a plurality of users, an access request, the access request comprising a first authentication factor; authenticate the first authentication factor; in response to a positive authentication of the first authentication factor, send, to at least one resource server, a validation request, the validation request comprising at least a portion of the validation information; receive, from the at least one resource server, confirmation that the first user has been validated; and grant the access request.
16. The apparatus of claim 14, wherein each resource server is associated with a respective network, separate from each other.
17. The apparatus of claim 16, wherein the or each respective network is associated with a respective user premises.
18. The apparatus of any of claims 15 to 17, wherein the apparatus is further caused to: send, to the first user, confirmation that the first user has been validated; and receive, from the first user, a second authentication factor.
19. The apparatus of claim 18, wherein the access request and the second authentication factor are received via a first communication channel and wherein confirmation that the first user has been validated is sent to the user via a second communication channel, different from the first communication channel.
20. The apparatus of claim 19, wherein sending, to the first user, confirmation that the first user has been validated comprises sending a one-time passcode to the first user.
21. The apparatus of any of claims 15 to 20, wherein the validation information comprises a plurality of user IDs associated with the plurality of users, and wherein the device is further caused to: retrieve, from the validation information, the first user ID.
22. The apparatus of any of claims 15 to 21, wherein the device is further caused to: receive, from a central server, the validation information.
23. The apparatus of claim 22, wherein the device is further arranged to: send, to the central server, confirmation that the user has been validated; and receive, from the central server, updated validation information.
24. The apparatus of any of claims 15 to 23, wherein the device is further arranged to: receive, from a central server, communication information, the communication information indicating one or more means of contacting the at least one resource server.