Patent Description:
In recent years, an increasing number of services and systems have been digitized, which users access via online accounts. A growing number of new services are also emerging, which also require a user to register with an account. As the number of online services grows, a user may be expected to remember a steadily increasing number of passwords associated with each of their myriad online accounts. Additionally, hackers are becoming more and more skilled in breaching secure sites and accessing personal information, and online services have thus begun to introduce more and more stringent password requirements for users as a way of mitigating data breach risks.

The growing number of passwords a user is required to remember, and their increasing complexity, presents a challenge for many users. In many cases, users simply attempt to use a single password for multiple accounts, which alleviates the mental burden of remembering multiple complex passwords. However, such a solution inherently introduces a security risk. Once the password for one account is obtained, access to all accounts may be achieved. Moreover, the same password may not be suitable for all of the multitude of online services, as each service may have different password requirements - for example, a first service may require a password without special characters, whilst a second service may require at least one special character. In this example, the same password could not be used by the user for both services.

There exist password managers which manage passwords for multiple online accounts associated with a single user. The multiple passwords may be stored locally or in the cloud and are typically encrypted such that they can be accessed by a single master password. This offers the advantages that the user need not remember the password for each service, allowing more complex strings to be used, although in practice more complex strings are not always used. A password manager may be used on multiple devices, facilitating easier login from a range of user devices. However, if the password manager is hacked, e.g. if the master password is discovered or obtained, then all accounts in the password manager may be compromised. There is then no way to invalidate all of the compromised passwords.

There may also be limitations on password strength imposed by an online service. For example, biometrics is now considered a secure means for access control that does not rely on user memory, although many online services do not have the capability or resources to exploit the use of biometrics for account logins.

European patent <CIT> describes a password generation device and method in which a computer address, a user identifier and a user password are used to generate a password for a service. The computer address may be one of multiple computer addresses which are mapped to a single base address and corresponding base system identifier, and the user identifier may be mapped to a user system identifier. The base system identifier and the user system identifier may be combined to generate a combined identifier which may serve as a password or from which a password may be generated. This system provides the advantage that in the case of a security breach, an entire class of passwords may be invalidated simply by changing one or more of the system identifiers (e.g. the user system identifier or the base system identifier). However, the password generation is dependent on the user inputting a single password - that is, a text-based password input. This can present a challenge to users with different accessibility needs and users of devices without, for example, an easily accessible keyboard. Some devices, for example, have increasingly small screens or input means, which can introduce additional challenges to users with visual impairment, reduced fine motor skills and the like. Moreover, the security is limited by the use of a single password and a single type of authentication. The benefits of newer, more secure authentication mechanisms with which devices are increasingly outfitted are not used.

<CIT> constitutes further relevant prior art. A first component of a cryptographic key is received from a user via a user interface of a user computing device. A second component of the cryptographic key is received via a short-range communication interface that communicatively couples the user computing device to a physically separate storage device. The cryptographic key is generated based at least on the first component and the second component.

There is therefore a need to develop a password management system which can overcome these widely varying accessibility challenges whilst also improving the security of the user's passwords.

It would be advantageous to have a password management system and method for reconstructing a password for accessing a password-protected resource, such as a service, which enables a user to use a variety of authentication types and which maintains or increases the security of the password management system.

A password management system is provided, addressing some of the concerns mentioned herein. The password management system for reconstructing a password for accessing a password-protected resource comprises.

wherein the client-side processor system or the server-side processor system is further configured to reconstruct a password by:.

The password management system may be configured to calculate, either on the client device or on the server device, a user-based password component. The user-based password component may be combined with an application-based password component calculated on the server side, and the password may be generated from the combination. In some embodiments, the combination itself may be used as the password, and in other embodiments, further processing may be performed on the combination to arrive at the password. For example, in some embodiments, password limitations such as requirements relating to password creation of an account for accessing a password-protected resource may be used to further adjust the password, for example by changing the length, types of characters and the like.

The password management system improves security by distributing the reconstruction of the password. Components used to generate the password are distributed across the client device and the server, meaning that if either of these elements become compromised, the user's password(s) for password-protected resource(s) are not directly obtainable from the components on the compromised device/server. That is, a data breach on the server or on the client device would not compromise the user's various online accounts.

In some embodiments, the password management system is configured to compute the user-based password component on the client device. In such cases, the protected authentication input do not need to be transmitted to the server device, which reduces the risk of the protected authentication input being obtained by a malicious party, for example via interception.

The database storage of the server device is configured to store a database comprising stored password factors for corresponding protected authentication inputs. That is, the authentication input obtained by the client device may have a corresponding stored password factor. By combining the protected authentication input with the corresponding stored password factor, the user-based password component may be obtained. Each stored password factor is initially computed to ensure that the same user-based password component is obtained when the stored password factor is combined with its associated protected authentication input. That is, the stored password factors on their own do not contain authentication information, but enable multiple authentication types and/or devices to be used to obtain the same user-based password component. This enables a user to make use of any authentication input capabilities offered by their device(s).

A method for generating a password or for enrolling a device according to the invention may be implemented on a computer as a computer implemented method, or in dedicated hardware, or in a combination of both. Executable code for a method according to the invention may be stored on a computer program product. Examples of computer program products include memory devices, optical storage devices, integrated circuits, servers, online software, etc. Preferably, the computer program product comprises non-transitory program code stored on a computer readable medium for performing a method according to the invention when said program product is executed on a computer.

In a preferred embodiment, the computer program comprises computer program code adapted to perform all the steps of a method according to the invention when the computer program is run on a computer. Preferably, the computer program is embodied on a computer readable medium.

The invention is defined by the claims as appended.

It should be noted that items which have the same reference numbers in different Figures, have the same structural features and the same functions, or are the same signals.

The following list of references signs of elements shown in <FIG> and <NUM>-<NUM> is provided for facilitating the interpretation of the drawings and shall not be construed as limiting the claims.

While this invention is susceptible of embodiment in many different forms, there are shown in the drawings and will herein be described in detail one or more specific embodiments, with the understanding that the present disclosure is to be considered as exemplary of the principles of the invention and not intended to limit the invention to the specific embodiments shown and described.

<FIG> schematically shows an overview of an environment for a password management system. A user <NUM> may have one or more devices <NUM> through which they may access one or more password-protected resources <NUM>.

The password management system may comprise a server <NUM> and at least one client device <NUM>. The password management system, the server <NUM> and the client device <NUM> will be described in detail with reference to <FIG>.

For example, user <NUM> may have a mobile phone <NUM>-<NUM>, a laptop <NUM>-<NUM> and a tablet <NUM>-<NUM>, and may wish to access a multitude of online password-protected resources from one or more of these devices. Password-protected resources may include, for example, a social media network, a banking application, an email application, a media provider, an online shopping service and the like. Further password-protected resources may provide access to files, databases, health information, digital records, and so on. It is to be understood that the examples of password-protected resources provided herein are merely exemplary and non-limiting.

User <NUM> may have an account with a password management system hosted on a server <NUM>. For a particular password-protected resource with which the user <NUM> has an account, the password management system is configured to generate the same password for the user <NUM> from any of their enrolled devices. For example, the user <NUM> may obtain their password for a first password-protected resource <NUM>-<NUM> from any one of their devices <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM>.

A password may be any authentication token. Some password-protected resources typically require a combination of a username and password - the combination of which may be referred to as the user identifier. In such cases, both the password in the combination and the user identifier itself may be considered authentication tokens. For example, the password reconstructed by the password management system may be a user identifier, which may be, for example, a strong user identifying string. In some cases, the password, or user identifier, may be sufficient to access a password-protected resource, e.g. without also providing a username. The password reconstructed by the password management system may be the password component of the user identifier, or the password may be the user identifier itself, e.g. removing the need for a separate username.

Some of the client devices <NUM>, may be configured to accept one or more types of authentication. For example, client device <NUM>-<NUM> may be configured to accept a fingerprint authentication and a textual authentication, e.g. input via a keyboard or touchscreen, whilst client device <NUM>-<NUM> may be configured to use facial recognition. In some embodiments, the password management system is configured to reconstruct the same password using information on the authentication input, such as an authentication type, and/or a device identifier. An authentication type may be, for example, fingerprint authentication, facial recognition authentication and the like. For example, user <NUM> may access a social media network <NUM>-<NUM> from their mobile phone <NUM>-<NUM> using fingerprint authentication and from their tablet PC <NUM>-<NUM> using facial recognition. In this example, the same password may be generated by the password management system. Moreover, a single device may be configured to accept multiple authentication means. For example, mobile phone <NUM>-<NUM> may be configured to accept fingerprint authentication, facial recognition, voice recognition and a text-based authentication input (e.g. password). The user <NUM> may obtain the same password for social media network <NUM>-<NUM> using any of these authentication types. A client device <NUM> may also, or alternatively, use continuous authentication, which may continuously re-verify the identity of the user of the client device <NUM>, for example by monitoring the behaviour of the user with the client device <NUM> and the use of the client device <NUM>. In some embodiments, the authentication input may be obtained without a user input. For example, the authentication input may be obtained through system authentication without user involvement. The authentication input may, in these cases, be a certificate or the like.

Prior to reconstructing a password through the password management system, a client device <NUM> may be enrolled in the password management system. For example, a user <NUM> may have an account with the password management system. Each client device that the user <NUM> wishes to use in conjunction with the password management system may be enrolled with the user's account in the password management system. The user <NUM> may enrol more than one client device <NUM>. In some embodiments, a single device <NUM> may be enrolled with multiple authentication types. For example, a user's mobile phone may be enrolled first using a text-based password, and again using a fingerprint authentication. A method of enrolling a device with the password management system will be described in detail with reference to <FIG>. The method of generating the password will be described in detail with reference to <FIG>, <FIG>, <FIG> and <FIG>.

<FIG> schematically shows an example of an embodiment of a password management system. Password management system <NUM> may comprise a server <NUM> and at least one client device <NUM>. Password management system <NUM> may take the form of an application, a browser plug-in, an extension and/or the like. Although in <FIG> only one client device <NUM> is shown, it is to be understood that this is for the sake of simplicity and illustration, and multiple client devices of a single user <NUM> may be included in the password management system. The client device <NUM> and/or the server <NUM> may be configured to communicate with a password-protected resource <NUM>.

The client device <NUM> may comprise a client-side communication interface <NUM> and a client-side processor system <NUM>, and in some embodiments, a protected storage <NUM>. The server <NUM> may comprise a database storage <NUM>, a server-side communication interface <NUM> and a server-side processor system <NUM>.

The client-side communication interface <NUM> may be configured to receive, from another device such as client device <NUM>-<NUM>, a request for generating a password for a password-protected resource. That is, another device may request the client device <NUM> to reconstruct a password for accessing a password-protected resource <NUM>. This is a form of multi-factor authentication (MFA) where the second factor is integrated in the password generation process. That is, the systems and methods described throughout this disclosure may be implemented in a multi-factor authentication system or method.

The client-side communication interface <NUM> may be configured to receive user input, including an authentication input, from a user of the device <NUM>, e.g. user <NUM>. The client-side communication interface <NUM> may be further configured to communicate with the server <NUM> and at least one password-protected resource <NUM>.

The authentication input may comprise, for example, a string of characters, a vector, a number, and in some embodiments the authentication input may have a minimum number of bits.

The client-side processor system <NUM> may be configured to compute a protected authentication input. In some embodiments, a non-invertible, deterministic function may be applied to a received authentication input to obtain the protected authentication input. The non-invertible, deterministic function may be, for example, a key derivation function, such as a hash function, or an encryption function.

The database storage <NUM> of the server <NUM> may be configured to store a database for one or more password factors for corresponding protected authentication inputs. The database may associate each stored password factor with an authentication type of the protected authentication input and/or a device identifier identifying the client device <NUM> used to obtain the authentication input. That is, in some embodiments, the client-side communication interface may be configured to send, to the server, information on the authentication input such as the authentication type of the authentication input and/or a device identifier identifying the client device <NUM>. In some embodiments, the server-side communication interface <NUM> may retrieve a stored password factor using one or more of an authentication type and a device identifier. Database storage <NUM> may be stored remotely, such as in a remote storage, in the cloud or in a distributed fashion, or database store <NUM> may be stored within the hardware of the server <NUM>, for example in local memory.

The server-side communication interface <NUM> may be configured to communicate with the client device <NUM> and, in some embodiments, a password-protected resource <NUM>.

A client device <NUM> may be enrolled with the password management system <NUM> prior to use in reconstructing a password. The user <NUM> may be registered with an account in the password management system <NUM>.

The client-side communication interface <NUM> may be configured to receive an authentication input from a user of the client device <NUM>, e.g. user <NUM>. The authentication input may be in the form of, for example, a text-based password, for example input via a keyboard or touch input, or a biometric input, such as a fingerprint, facial recognition or retinal scan. In some embodiments, the authentication input may be a certificate, which may allow for authentication without user input. The authentication input has a corresponding authentication type. The authentication type indicates a type of authentication input, such as a fingerprint, text-based password input, touch input, swipe input, facial recognition, speech or voice recognition, retinal scan and the like.

The client-side communication interface <NUM> may be configured to send a message to the server <NUM>, for example to request enrolment of the device. In some embodiments, the message may include the authentication type associated with the authentication input. In some embodiments, a device identifier may also or alternatively be transmitted to the server <NUM>. The device identifier may be an identification code uniquely identifying the device <NUM>.

The message may comprise a request to check if the user <NUM> has any previous enrolments, such as any devices previously enrolled, in their account with the password management system.

Upon receiving the message, the server <NUM> may check whether there is already a device previously enrolled in the user's account, for example by checking the database for existing entries associated with the user's account. The server, e.g. the server-side communication interface <NUM>, may respond to the client device <NUM> to indicate whether there is a device already enrolled with the user's account.

If the user's account has no previous enrolments, the client device <NUM> may perform a first-time enrolment.

The client-side processor system <NUM> may be configured to generate a user-based password component by randomly generating a number. The client-side processor system <NUM> may be further configured to compute, from the protected authentication input and the randomly generated number, a password factor (PF). This is schematically shown in the equation below: <MAT> where input represents the authentication input, and f(input) represents the protected authentication input, the function f(·) being the non-invertible deterministic function. The function may comprise including a seed to the authentication input before applying a non-invertible deterministic function. In some embodiments, the seed associated with the user's password management system account may be obtained from the server <NUM>. The non-invertible function may be, for example, a hash function. The protected authentication input may be a string, a vector, or the like, and in some embodiments, the protected authentication input may have a minimum and/or maximum length.

Although the above equations depict the use of addition to obtain the password factor from the randomly generated number and the protected authentication input, it is to be understood that any invertible, deterministic function may be used. For example, the invertible, deterministic function may comprise an arithmetic operation such as addition or subtraction, a geometric operation, ring addition, convolution, and so on.

Once the password factor is determined, the client-side communication interface <NUM> may be configured to transmit the password factor to the server <NUM>, along with the associated authentication type. When enrolling a first device, e.g. when no previous devices are enrolled for a user's account with the password management system, it is preferable that the authentication input is a text-based password. In some examples, however, a swipe input or speech input may be used. The server <NUM> may be configured to store the received password factor in the database such that the password factor is associated with the user's account and one or more of the authentication type and a device identifier.

If there is a previous enrolment, e.g. a device previously enrolled with the password management system in the user's account, the client-side communication interface <NUM> may be configured to prompt the user to input a previous authentication input associated with the previously enrolled device. For example, if the previously enrolled device was enrolled with a text-based password, the client device <NUM> may prompt the user for a text-based password. If there are multiple devices previously enrolled with the user's account, one of the multiple previously enrolled devices may be selected or designated as a default device for facilitating new enrolments, such as by selecting a device associated with a text-based authentication type, for example a password, or a touch or swipe input. Examples of touch inputs or swipe inputs may be a passcode, a pattern dragged on an <NUM>-segment, a swipe connecting a plurality of dots or pattern elements or the like.

The server <NUM> may provide, e.g. via the server-side communication interface <NUM>, the client device <NUM> with a stored password factor associated with the previous enrolment, or in the case of multiple previous enrolments, a stored password factor associated with a selected or default previous enrolment. The stored password factor may be retrieved from the database storage <NUM>. The client-side processor system <NUM> may be configured to compute a previous protected authentication input by applying a non-invertible, deterministic function, such as a key derivation function or an encryption function, to the previous authentication input obtained from the user via the client-side communication interface <NUM>. From the previous protected authentication input and the received previous password factor, the client-side processor system <NUM> may be configured to calculate a user-based password component. Then, the client-side processor system <NUM> may be configured to calculate a password factor associated with the client device <NUM> (e.g. the device being enrolled) from the protected authentication input and the calculated user-based password component. This is illustrated in the following equations, in which subscript '<NUM>' is used to denote terms associated with the previously enrolled device and subscript '<NUM>' is used to denote terms associated with the client device <NUM>, e.g. the device being enrolled.

Using the following two equations, the user-based password component may be calculated using the protected authentication input of the previous enrolment and the password factor associated with the previous enrolment. The user-based password component may then be used to calculate the password factor PF<NUM> for the current enrolment (that is, for the authentication or device being enrolled), as shown in the third equation: <MAT> <MAT>.

In other words, the password factor associated with the client device <NUM> is determined such that the same user-based password component (UserPassComponent) may be computed from the password factor and the protected authentication input.

In some embodiments, the function f(input) may comprise adding a seed to the input before applying the non-invertible, deterministic function. The seed may be retrieved, e.g. from a database such as the database stored in database storage <NUM>.

In the above equations, although a simple addition is depicted for combining the protected authentication input (f(inputi)) and the user-based password component, it is to be understood that any invertible, deterministic function may be used.

This construction is illustrated in <FIG>. Referring now to <FIG>, a system with three client devices, e.g. client device <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM>, is shown. Database <NUM> is shown, which may be stored in the database store <NUM> of the server <NUM>. Each client device <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM> may be used to provide a respective authentication input <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, which may be the protected authentication input. In some embodiments, a single client device may be enrolled with multiple authentication types. In other words, client device <NUM>-<NUM> and client device <NUM>-<NUM> may be the same client device, and may refer to different authentication inputs of different authentication types. For example, client device <NUM>-<NUM> as shown in <FIG> may refer to a user's mobile phone in which a password is used as the authentication input, thereby having a text-based, or password, authentication type, whereas client device <NUM>-<NUM> may refer to the same physical device, the user's mobile phone, in which a fingerprint is used as the authentication input, thereby having a fingerprint or biometric authentication type.

For each authentication type and/or each device, an associated stored password factor may be retrieved from the database <NUM>. In other words, a stored password factor may be retrieved using an authentication type and/or a device identifier. For example, stored password factor <NUM>-<NUM> may be associated with the authentication type of authentication input <NUM>-<NUM>, stored password factor <NUM>-<NUM> may be associated with the authentication type and the device used to obtain authentication input <NUM>-<NUM>, and stored password factor <NUM>-<NUM> may be associated with the authentication type of authentication input <NUM>-<NUM>. This is illustrated in Table <NUM> below.

The stored password factors may be stored locally in the server <NUM>, e.g. in a database of the database storage <NUM>, or in a remote database such as in a cloud-based storage resource.

As shown in Table <NUM>, a first password factor, PF1, may be stored, associated with the authentication type denoted by password. A second password factor, PF2, associated with a fingerprint authentication on a first client device, may also be stored, whilst a third password factor, PF3, may be a different password factor associated also with a fingerprint authentication but on a different client device (e.g. client device <NUM>-<NUM>). The first client device, e.g. client device <NUM>-<NUM>, may also have an associated password factor PF4 stored in the database, associated with a facial recognition authentication type. In some embodiments, a client device identification on its own may be used to obtain the corresponding stored password factor. For example, if a client device has only a single authentication or if the client device only has the capability for a single type of authentication, the database may not store the authentication type and instead the client device identifier is used to retrieve the stored password factor. This is shown in the last row of Table <NUM>. A client device denoted <NUM>-<NUM> in the table below may be associated with stored password factor PF6. The password factors may be strings, vectors, arrays, or the like. In some embodiments, the password factors may have a minimum bit length, maximum bit length or the like.

In each case, the authentication input <NUM> and the associated stored password factor <NUM> may be combined in a function <NUM> to obtain the same output, the user-based password component <NUM>. In other words, function <NUM> may be used to combine authentication input <NUM>-<NUM> and stored password factor <NUM>-<NUM> to obtain the user-based password component <NUM>. The same user-based password component <NUM> may also be obtained when the function <NUM> is applied to the authentication input <NUM>-<NUM> and associated stored password factor <NUM>-<NUM>, and when the function <NUM> is applied to the authentication input and associated stored password factor <NUM>-<NUM>.

The authentication inputs <NUM> themselves need not be used to retrieve the associated stored password factor <NUM> from the database <NUM>. In some embodiments, the authentication type and/or a device identifier may be used to retrieve the stored password factor <NUM>. A device identifier may be used, for example, in embodiments where a single authentication type results in different authentication inputs being obtained depending on the client device. In some embodiments, the transmission of the authentication input <NUM> itself, which may be the protected authentication input, may therefore be avoided, and the associated risk of interception may be mitigated.

Referring once again to <FIG>, once the password factor is determined for the client device <NUM>, the client-side communication interface <NUM> may be configured to transmit the password factor to the server <NUM>. The server <NUM> may be configured to store the received password factor in the database of the database storage <NUM>, such that the password factor is associated with the protected authentication input used during the enrolment. In some embodiments, a device identifier and/or an authentication type of the authentication input may also be associated with the password factor in the database. In some embodiments, a confirmation message may be transmitted from the server <NUM> to the client device <NUM> to confirm successful enrolment.

The types of authentication input accepted may be based on the capabilities of the client device <NUM>. For example, a mobile phone may be equipped with biometric authentication means, such as fingerprint scanning, facial recognition, speech and/or voice recognition and the like, as well as keyboard and/or touch input and so on. Biometric inputs, such as fingerprint scanning, may be used to access a protected storage <NUM> of the client device <NUM>. In some embodiments, the authentication input may comprise a string stored in the protected storage <NUM>, accessed via authentication through a fingerprint scan. In some embodiments, the contents of the protected storage <NUM> may differ from one device to another. For example, a fingerprint scan used for authentication on a first client device, e.g. client device <NUM>-<NUM>, may provide access to the protected storage <NUM> of said device, in which a first string is stored. A fingerprint scan used for authentication on a second client device, e.g. client device <NUM>-<NUM>, may provide access to its own protected storage <NUM> in which a different string is stored. Thus the password factor associated with a fingerprint authentication in the first device, e.g. client device <NUM>-<NUM>, may be different from the password factor associated with a fingerprint authentication in the second device, e.g. client device <NUM>-<NUM>. In some embodiments, therefore, a device identifier may be transmitted from the client device <NUM> to the server <NUM> during enrolment and stored in the database of database storage <NUM>, such that the stored password factor is associated with the device identifier.

For the sake of illustration, a practical example is introduced. This example will be referred to throughout the present disclosure.

User <NUM> has an account with the password management system and wishes to use the password management system on his mobile phone. At this stage in the example, the user <NUM> has no previous enrolments in his password management system account.

For the first enrolment for user <NUM>, user <NUM> may log into the password management system, via an app on his mobile phone or through an extension, for example a downloadable browser extension, widget or the like. The user <NUM> may provide an authentication input in the form of a password, input via the touchscreen keyboard of his mobile phone. Upon obtaining the password, the user's mobile phone may calculate a protected authentication input from the password and as described above, may randomly generate a number as the user-based password component <NUM>. The user's mobile phone may then compute the password factor as described above. By doing so, the user-based password component <NUM> does not need to be stored, either at the client device or at the server device, which improves the security of the system. The user-based password component <NUM> can be reconstructed as described above from values distributed over the client device <NUM> and the server <NUM>, which removes the need for storing the user-based password component <NUM>. Alternatively, the user's mobile phone may randomly generate the password factor and compute the user-based password component <NUM> from the randomly generated password factor and the protected authentication input.

The user's mobile phone may then transmit the password factor, along with an indication that the password factor corresponds to an authentication type and/or a device, to the server <NUM>, and the enrolment is complete.

The user may then decide that inputting a password is inconvenient, or difficult, or may decide to make use of the biometric capabilities of his mobile phone. The user may therefore decide to also enrol a fingerprint authentication, since his mobile phone is equipped with fingerprint verification means.

To do so, the user may again log into the password management system and may enrol a further authentication. In this case, the user may provide a fingerprint as an authentication. His mobile phone may verify that the received fingerprint matches fingerprint data stored in the mobile phone, and upon determining that the received fingerprint matches the fingerprint data, may provide access to a protected storage such as a vault, on the mobile phone. The protected storage, or vault, may store a vector, string or array which may be used as the authentication input. The authentication input may be a value which has previously been randomly generated, for example. The mobile phone may then compute a protected authentication input from the, e.g. vector, stored in the protected storage. In some cases, the protected authentication input may be identical to the authentication input.

Since the user <NUM> already has an existing enrolment in the password management system, the user <NUM> may be prompted to input his previous authentication, e.g. the password used in the first enrolment. Once the user <NUM> inputs the password used in the previous enrolment, the mobile phone may send a request to the server <NUM> for the password factor associated with the password-based authentication. That is, the password itself need not be sent. It is sufficient for the user's mobile phone to send an indication of the type of authentication used (e.g. a password, or a text-based input, or the like). The server <NUM> may then retrieve the stored password factor associated with a password authentication and may transmit the retrieved stored password factor to the user's mobile phone. The user's mobile phone may then compute a protected authentication input from the password received from the user, and then compute the user-based password component from the received stored password factor and the protected authentication input computed from the password. Once the user-based password component is computed, the mobile phone may compute a further password factor, associated with the fingerprint authentication, from the user-based password component and the protected authentication input computed from the, e.g. vector obtained using the fingerprint authentication. The mobile phone may then transmit the further password factor, along with an indication of the associated fingerprint authentication type, to the server <NUM>. The mobile phone may also transmit a device identifier which can be used to identify the mobile phone.

The password management system may be used to reconstruct a password for accessing a password-protected resource <NUM>.

A user <NUM> may wish to log into, or create an account with, a password-protected resource <NUM>, which may be for example, a banking application, a social network application, an online shopping application or the like. The password management system may be configured to compute a plurality of components or factors used to reconstruct a password, and said components or factors may be stored or computed in a distributed fashion. For example, at least one component or factor used to reconstruct the password may be stored or computed on the client device <NUM>, whilst at least one component or factor used to reconstruct the password may be stored or computed on the server <NUM>. By distributing the components or factors used to reconstruct the password, the password may be kept secure even if one of the devices becomes compromised.

The client-side communication interface <NUM> may be configured to obtain application information, e.g. information about the password-protected resource <NUM>. The application information may comprise, for example, a unique resource location (URL) for the password-protected resource. Additionally, the client-side communication interface <NUM> may be configured to obtain an authentication input from the user <NUM> of the client device <NUM>. The authentication input may comprise, for example, a password input into a touch screen or a keyboard of the client device <NUM>. In some embodiments, the authentication input may be obtained using a biometric input, such as a fingerprint obtained via a fingerprint scanner (e.g. via a touch screen), facial recognition via a camera of the client device <NUM>, voice recognition via a microphone of the client device <NUM>, or the like. In some embodiments, the authentication input may be stored in a protected storage of the client device <NUM> accessed via a biometric authentication input. The authentication input may have an associated device identifier and/or an associated authentication type indicating the type of authentication input, such as a password, fingerprint, retinal scan, swipe input, and the like.

The client-side processor system <NUM> may be configured to compute a protected authentication input by applying a non-invertible, deterministic function, such as a key derivation function, to the obtained authentication input.

The client-side communication interface <NUM> may send a message, or multiple messages, to the server <NUM>. In some embodiments, the message may be a request for retrieving a stored password factor. In some embodiments, the client-side communication interface <NUM> may transmit information on the authentication input, such as an authentication type and/or a device identifier identifying the client device <NUM>. In some embodiments such as that described in detail with regard to <FIG>, the client-side communication interface <NUM> may further transmit, in the same transmission (e.g. message) or in an additional transmission, the protected authentication input. However, the transmission of the protected authentication input is not required in all embodiments, and an alternative embodiment in which the protected authentication input is not transmitted to the server <NUM> is described in detail with reference to <FIG>. In some embodiments, for example if the authentication type is a biometric authentication type, e.g. fingerprint, facial recognition, retinal scan etc, the client-side communication interface <NUM> may further transmit a device identifier identifying the client device <NUM> to the server <NUM>.

The server <NUM>, e.g. the server-side communication interface <NUM>, may retrieve the stored password factor from the database stored in the database storage <NUM>, for example using the received authentication type and/or the device identifier. In some embodiments, account information identifying the user's account with the password management system may be received from the client device <NUM> and also used to retrieve the stored password factor.

In some embodiments, the client-side communication interface <NUM> may be configured to transmit application information, e.g. information associated with the password-protected resource <NUM> such as a URL or the like. The application information may be obtained from the password-protected resource <NUM> by the client device <NUM> prior to transmission to the server <NUM>.

The server-side processor system <NUM> may be configured to compute an application-based password component from the application information. For example, the application-based password component may be computed by applying a deterministic function, preferably a non-invertible deterministic function, to the application information and, in some embodiments, a seed or user account information associated with the user <NUM>'s account in the password management system.

In some embodiments, the server-side processor system <NUM> may be configured to compute a user-based password component from the protected authentication input and the stored password factor which has been retrieved from the database in the database storage <NUM>. The user-based password component may be calculated by combining the protected authentication input and the stored password factor using an invertible, deterministic function. In embodiments where the computation of the user-based password component is performed by the server <NUM>, the client device <NUM> (e.g. the client-side communication interface <NUM>) may be configured to transmit the protected authentication input to the server <NUM>.

In some alternative embodiments, the client-side processor system <NUM> may be configured to compute the user-based password component. In such embodiments, the server-side communication interface <NUM> may be configured to transmit, to the client device <NUM>, the retrieved stored password factor. The client-side processor system <NUM> may then compute the user-based password component from the stored password factor and the protected authentication input, for example by applying an invertible, deterministic function thereto. In such embodiments, it is not necessary for the client device <NUM> to transmit the protected authentication input to the server <NUM>.

Once the user-based password component has been computed, either at the server <NUM> or at the client device <NUM>, the user-based password component may be combined with the application-based password component calculated by the server <NUM>. The user-based password component and the application-based password component may be combined, for example, by applying a deterministic function thereto, the deterministic function preferably being non-invertible.

In some embodiments, the user-based password component and the application-based password component may be combined by the client-side processor system <NUM>. In such embodiments, the server-side communication interface <NUM> may be configured to transmit, to the client device <NUM>, the computed application-based password component. A password may then be reconstructed from the combination of the user-based password component and the application-based password component by the client-side processor system <NUM>.

In other embodiments, the user-based password component and the application-based password component may both be computed by the server-side processor system <NUM>, in which case the server-side processor system <NUM> may be configured to combine the user-based password component and the application-based password component, and to reconstruct a password from the combination of the user-based password. In such embodiments, the server-side processor system <NUM> may be configured to reconstruct the password and transmit the reconstructed password to the client device <NUM>, for example through a backend channel or in an encrypted form.

In some embodiments, either the client-side processor system <NUM> or the server-side processor system <NUM> may be configured to adjust the reconstructed password. One or more password requirements may be obtained from the password-protected resource, by either the client-side communication interface <NUM> or by the server-side communication interface <NUM>. In some embodiments, the one or more password requirements may be obtained by the client device <NUM> from the password-protected resource <NUM> and may be used by the client device <NUM>, or may be transmitted to the server <NUM>. The one or more password requirements may comprise, for example, a minimum and/or maximum password length, character requirements, such as a number of uppercase or lowercase letters, numbers, special characters, and the like.

In some embodiments, the client-side processor system <NUM> may be configured to reconstruct the password as described above, and may be further configured to adjust the reconstructed password using the one or more password requirements associated with the password-protected resource <NUM>.

In some embodiments, the server-side processor system <NUM> may be configured to reconstruct the password as described above, and may be further configured to adjust the reconstructed password using the one or more password requirements associated with the password-protected resource <NUM>. For example, the one or more password requirements may be obtained from the server <NUM>. For example, the one or more password requirements may be stored when the user account with the password-protected resource is created, or at another time. The server-side communication interface <NUM> may be configured to transmit the adjusted password to the client device <NUM>, for example via a backend channel or in an encrypted form or the like.

In some embodiments, the server-side processor system <NUM> may be configured to reconstruct the password as described above, and the server-side communication interface <NUM> may be configured to transmit the reconstructed password to the client device <NUM>. The client-side communication interface <NUM> may be configured to obtain the one or more password requirements, for example from the server <NUM>, and the client-side processor system <NUM> may be configured to adjust the received password according to the one or more password requirements. That is, the password may be reconstructed on the server side, and adjusted on the device side.

The methods of reconstructing a password for accessing the password-protected server <NUM> will be further elucidated with reference to <FIG> and <FIG>, and the additional aspect of adjusting the password will be described in detail with reference to <FIG> and <FIG>.

<FIG> schematically shows an example of an embodiment of a method of enrolling a device in a password management system.

The enrolment of a device in the password management system may be performed in one of at least two ways, depending on whether the user's account with the password management system has an associated previously enrolled device. That is, the method of enrolling a first device, e.g. a first enrolment, differs from the method of enrolling a second or subsequent device. Although throughout this description reference is made to enrolling a device, it is to be understood that a single device may have multiple enrolments, e.g. corresponding to different authentication inputs. That is, in essence, an authentication input may be enrolled. However, enrolling a device either as a first enrolment or as a subsequent enrolment may be performed using four main operations as illustrated in <FIG>.

The method comprises, in a first operation entitled "OBTAIN AUTHENTICATION INPUT", obtaining <NUM> an authentication input, for example from a user prompted to input an authentication input. In some embodiments, the authentication input may be obtained from protected storage of the client device <NUM>, accessed for example using a biometric authentication means, e.g. fingerprint scanning. In some embodiments, the authentication input may be a password input into a keyboard or touchpad of the client device <NUM> by a user <NUM>. In some embodiments, the authentication input may be a passphrase spoken into a microphone of the client device <NUM> by a user <NUM>, for example using speech recognition. In some embodiments, obtaining the authentication input may comprise obtaining, from the user <NUM>, a biometric input such as a fingerprint, retinal scan, facial recognition, voice recognition or the like, which may enable access to a protected storage of the client device <NUM> in which an authentication input, e.g. a string, is stored. In some embodiments, obtaining the authentication input may comprise obtaining a user identifier using continuous authentication, for example from a protected storage of the client device <NUM>. In some embodiments, the operation of obtaining the authentication input may further comprise computing a protected authentication input from the authentication input by applying a non-invertible, deterministic function to the authentication input.

The method comprises, in an operation entitled "OBTAIN USER-BASED PASSWORD COMPONENT", obtaining <NUM> a user-based password component. Depending on whether the enrolment being performed is a first enrolment or a subsequent enrolment, the method of obtaining the user-based password component may differ. The operation of obtaining <NUM> the user-based password component is illustrated in more detail in <FIG>.

Referring now to <FIG>, in some embodiments, the client device <NUM> may query the server <NUM> to determine, in operation <NUM>, whether there are any previous enrolments associated with the user's account with the password management system. In some embodiments, this query operation may be omitted, for example if the user has, immediately preceding the enrolment, registered for a new account with the password management system.

In operation <NUM>, the server <NUM> may check whether the user's account has at least one previously enrolled device, for example by checking for entries in database <NUM>.

If there are no previous enrolments, e.g. if there are no devices previously enrolled for the user's account, then the method of <FIG> continues to operation <NUM>. That is, if the enrolment being performed is a first enrolment, the user-based password component is obtained in operation <NUM>. The method comprises, in an operation entitled "GENERATE USER-BASED PASSWORD COMPONENT", generating <NUM> a user-based password component as a random number. That is, the client device <NUM> may generate a random number to be the user-based password component.

Otherwise, if there is at least one previous enrolment, e.g. there is already a device that has already been enrolled for the user's account in the password management system, the method of <FIG> continues to operation <NUM>. The method comprises, in an operation entitled "RETRIEVE PREVIOUSLY STORED PASSWORD FACTOR", retrieving <NUM> a previously stored password factor. The previously stored factor may be associated with a previous enrolment. If there are multiple previous enrolments, one previous enrolment may be chosen as a default, for example a previous enrolment associated with a password, or text-based, authentication type, or a default previous enrolment may be selected by a user.

The method may then comprise, in an operation entitled "PROMPT USER FOR PREVIOUS AUTHENTICATION INPUT", requesting <NUM> the user to provide the previous authentication input, e.g. the authentication input associated with the previous enrolment. The user <NUM> may then input the authentication input used in the previous enrolment. Preferably, the previous authentication input is a text-based authentication, e.g. having a text-based authentication type. A text-based authentication input such as a password may be advantageous if the previous enrolment involved a different client device, as the same authentication input (e.g. same text-based password) may be obtained by different devices. In some embodiments, a biometric input (e.g. a fingerprint) provided on one device may not lead to the same authentication input string on a first device as that obtained by inputting the same biometric input (e.g. the same fingerprint) on a second device. In such cases, it is advantageous to use a previous enrolment in which a text-based authentication such as a password is used, to ensure that the same authentication input is received from one device to another.

It is to be noted, however, that the previous enrolment may be on the same device as the client device being used in the current enrolment, for example using a different authentication type. In such a case, the previous enrolment may be any authentication input, such as a fingerprint, retina scan, facial recognition, voice recognition or the like.

The method may comprise, in an operation entitled "COMPUTE PREVIOUS PROTECTED AUTHENTICATION INPUT", computing <NUM> a previous protected authentication input from the received previous authentication input. The previous protected authentication input may be obtained by applying the non-invertible deterministic function, e.g. function <NUM>, to the previous authentication input received from the user <NUM>.

The method may comprise, in an operation entitled "CALCULATE USER-BASED PASSWORD COMPONENT", calculating <NUM> a user-based password component from the retrieved stored password factor and the previous protected authentication input. The user-based password component may be calculated by combining the retrieved stored password factor and the previous protected authentication using an invertible, deterministic function.

Returning now to <FIG>, once the user-based password component is obtained, the method of <FIG> may comprise, in an operation entitled "CALCULATE PASSWORD FACTOR", calculating <NUM> a password factor from the obtained user-based password component and the protected authentication input. The password factor may be computed by applying the invertible, deterministic function to the user-based password component and the protected authentication input. In operation <NUM>, entitled "STORE CALCULATED PASSWORD FACTOR", the computed password factor may be stored <NUM>, for example in the database <NUM>. Storing the calculated password factor may comprise transmitting the calculated password factor to the server prior to storage of the calculated password factor.

In some embodiments, the method may further comprise a confirmation step in which the server <NUM> may transmit a message to the client device <NUM> after the calculated password factor is stored, confirming the successful enrolment.

<FIG> and <FIG> schematically show examples of embodiments of a password reconstruction method. In the embodiment depicted in <FIG>, the password for accessing a password-protected resource may be reconstructed by the server <NUM>, whereas in the embodiment depicted in <FIG>, the password for accessing the password-protected resource may be reconstructed by the client device <NUM>. In both embodiments, the components used to reconstruct the password are distributed, which provides an advantage that the password cannot be obtained if one of the client device <NUM> and the server <NUM> is compromised.

The method may comprise, in an operation entitled "OBTAIN APPLICATION INFORMATION", obtaining <NUM>, by the client device <NUM>, application information associated with the password-protected resource <NUM>. Application information may comprise a URL of the password-protected resource <NUM>, an identifier identifying the password-protected resource <NUM> or the like.

The method may comprise, in an operation entitled "OBTAIN AUTHENTICATION INPUT", obtaining <NUM>, by the client device <NUM>, an authentication input from a user, e.g. user <NUM>. The authentication input may have an associated device identifier and/or an associated authentication type, indicating the type of authentication input provided by the user <NUM>. Examples of authentication types include a password, or text-based input, a touch-based input such as a swipe pattern, a biometric input such as a fingerprint authentication, facial recognition, retinal scan, voice recognition and the like. In some embodiments, the authentication input may comprise a value stored in a protected storage of the client device <NUM>, which is accessed, for example, using biometric authentication means. For example, the user <NUM> may provide a fingerprint as an input to the client device <NUM>. If the fingerprint provided by the user <NUM> matches a fingerprint previously registered with the client device <NUM> (for example, client device <NUM> may already be configured to be unlocked by a fingerprint input), a protected storage <NUM> of the client device <NUM>. The protected storage <NUM> may store a string or code, and said string or code may be used as the authentication input throughout the methods described herein.

The method may comprise, in an operation entitled "COMPUTE PROTECTED AUTHENTICATION INPUT", computing <NUM>, by the client device <NUM>, a protected authentication input from the authentication input obtained in operation <NUM>. The protected authentication input may be computed by applying a non-invertible, deterministic function to the obtained authentication input. In some embodiments, for example when the authentication input is obtained from a protected storage <NUM> of the client device <NUM>, the protected authentication input may be the authentication input itself, e.g. computing the protected authentication input may comprise applying the identity function to the authentication input. In some embodiments, computing the protected authentication input may comprise obtaining seed, e.g. a seed associated with the user's account with the password management system, combining the seed with the authentication input, and applying a function to the combination of the seed and the authentication input. Said function may be an identity function, or, in some embodiments, a non-invertible deterministic function such as a key derivation function.

It should be noted that although operation <NUM> is depicted as preceding operations <NUM> and <NUM>, operation <NUM> may be performed at any time prior to operation 640a, e.g. simultaneously or substantially simultaneously with operation <NUM> and/or <NUM>.

The method may comprise, in an operation entitled "SEND MESSAGE TO SERVER", transmitting 640a, 640b a message, or a plurality of messages, from the client device <NUM> to the server <NUM>. The content of the message, or plurality of messages or transmissions, may differ between the embodiment shown in <FIG> and that of <FIG>.

Referring first to the embodiment of <FIG>, in which the password is reconstructed by the server <NUM>, operation 640a comprises transmitting, by the client device <NUM> to the server <NUM>, the protected authentication input, application information associated with the password-protected resource <NUM>, and in some embodiments, an authentication type indicating the type of the authentication input and/or a device identifier identifying the client device <NUM>. In some embodiments, account information identifying the account of the user <NUM> with the password management system may also be transmitted from the client device <NUM> to the server <NUM>. Although depicted as a single operation, operation 640a may comprise one or more transmissions from the client device <NUM> to the server <NUM>.

The method may comprise, in an operation entitled "RETRIEVE STORED PASSWORD FACTOR", retrieving <NUM> a stored password factor from a database such as the database stored in database storage <NUM>. The server <NUM> may retrieve the stored password factor using the information received from the client device <NUM>, such as the authentication type and/or a device identifier identifying the client device <NUM>. In some embodiments, account information identifying the account of the user <NUM> with the password management system may be used to retrieve the stored password factor. In some embodiments, the authentication input- and therefore the protected authentication input- obtained when a first authentication type (e.g. a fingerprint) is used on a first client device, e.g. client device <NUM>-<NUM>, may differ from the authentication input obtained when that same authentication type (e.g. fingerprint) is used on a second client device, e.g. client device <NUM>-<NUM>. In such cases, the device identifier may be used to retrieve the stored password factor associated with the authentication type and the client device <NUM>. For example, a fingerprint input on a first client device may provide access to an authentication input in the protected storage of the first client device. The authentication input may have been previously randomly generated or uniquely generated. A fingerprint input on a second client device may provide access to an authentication input in the protected storage of the second client device, and the authentication input of the second client device may not match that of the first client device. The authentication inputs may be randomly or uniquely generated by each device prior to being stored in the protected storage. In some embodiments, different types of operating systems or applications on the client device(s) may handle biometric inputs differently, such that the authentication input obtained as a result of a biometric input may vary from one client device to another.

The method may comprise, in an operation entitled "COMPUTE APPLICATION-BASED PASSWORD COMPONENT", computing <NUM> the application-based password component. The server <NUM> may compute the application-based password component from the application information. In some embodiments, account information identifying the user's account in the password management system may also be used in the computation of the application-based password component. The application-based password component may be computed by applying an invertible or non-invertible deterministic function to the application information and, optionally, the account information associated with the password management system account of the user <NUM>. The calculation of the application-based password component is described in detail in European patent <CIT>.

It is to be noted that, although depicted sequentially, operations <NUM> and <NUM> may be performed in any order, simultaneously or substantially simultaneously.

The method may comprise, in an operation entitled "COMPUTE USER-BASED PASSWORD COMPONENT", computing 670a, by the server <NUM>, a user-based password component from the protected authentication input and the retrieved stored password factor. The user-based password component may be computed by applying an invertible, deterministic function to the protected authentication and the retrieved stored password factor.

The method may comprise, in an operation entitled "RECONSTRUCT PASSWORD", reconstructing 680a, by the server <NUM>, the password for accessing the password-protected resource <NUM>. The password may be reconstructed by combining the user-based password component and the application-based password component, for example by applying a deterministic function to the user-based password component and the application-based password component. The reconstructed password may also be referred to as a raw password. In some embodiments, the reconstructed password may be used directly to access the password-protected resource <NUM>. In other embodiments, the reconstructed password may be adapted or adjusted to obtain an adjusted password for accessing the password-protected resource <NUM>. Adjusting the reconstructed password will be described with reference to <FIG> and <FIG>.

The method may comprise, in an operation entitled "TRANSMIT PASSWORD", transmitting 690a the reconstructed password from the server <NUM> to the client device <NUM>. In some embodiments, the reconstructed password may be transmitted via a backend channel. In some embodiments, the reconstructed password may be encrypted prior to being transmitted to the client device <NUM>.

Returning to the previous example, the user <NUM> may wish to access an online shop with which he has an account.

The user <NUM> may, on his mobile phone, access a login page for the online shop, for example in a browser or in an application on the mobile phone. The user may then activate, or select, the password management system, which may be a browser plug-in, extension, application, or the like. The user <NUM> may then input his fingerprint as a means of authentication. The user's mobile phone may then compare the received fingerprint with fingerprint data used for fingerprint authentication on the mobile phone, and upon determining that the fingerprint matches the fingerprint data, may access the protected storage of the mobile phone, and thereby access the authentication input, which may be a vector in this example.

The user's mobile phone may compute the protected authentication input and transmit the protected authentication input, the associated authentication type and a device identifier identifying the mobile phone to the server <NUM>. The server <NUM> may then retrieve the stored password factor associated with a fingerprint authentication on the mobile phone. The server <NUM> may then compute the user-based password component by combining the received protected authentication input and the retrieved stored password factor. Combining may comprise, for example, a sum, a summing modulo a modulus, an XOR, or any other invertible operation.

The server <NUM> may also obtain application information, such as the URL of the online shop that the user <NUM> wishes to access. The server <NUM> may calculate an application-based password component from the obtained application information, and optionally from information of the user's password management system account. The server <NUM> may then reconstruct a password by combining the user-based password component and the application-based password component. The server <NUM> may then transmit the reconstructed password to the user's mobile phone. The reconstructed password may then be forwarded or input into the online shop access page. In some embodiments, however, the reconstructed password may be adjusted using one or more password requirements associated with the online shop, and the adjusted password may be used to access the online shop. Adjusting the password will be described with reference to <FIG> or <FIG>.

Referring now to the embodiment shown in <FIG>, in which the password is reconstructed on the client device <NUM>, operation 640b may comprise transmitting, by the client device <NUM> to the server <NUM>, application information associated with the password-protected resource <NUM> and, in some embodiments, information on the authentication input, such as a device identifier identifying the client device <NUM> and/or the authentication type indicating the type of the authentication input. That is, the protected authentication input need not be transmitted from the client device <NUM> to the server <NUM>. In some embodiments, a device identifier identifying the client device <NUM> may also be transmitted from the client device <NUM> to the server <NUM>. In some embodiments, account information identifying the account of the user <NUM> with the password management system may also be transmitted from the client device <NUM> to the server <NUM>. Although depicted as a single operation, operation 640b may comprise one or more transmissions from the client device <NUM> to the server <NUM>.

The method may comprise, in an operation entitled "RETRIEVE STORED PASSWORD FACTOR", retrieving <NUM> a stored password factor from a database such as the database stored in database storage <NUM>. The server <NUM> may retrieve the stored password factor using the information received from the client device <NUM>, which may include the authentication type and/or a device identifier identifying the client device <NUM>. In some embodiments, account information identifying the account of the user <NUM> with the password management system may be used to retrieve the stored password factor. In some embodiments, the authentication input - and therefore the protected authentication input- obtained when a first authentication type (e.g. a fingerprint) is used on a first client device, e.g. client device <NUM>-<NUM>, may differ from the authentication input obtained when that same authentication type (e.g. fingerprint) is used on a second client device, e.g. client device <NUM>-<NUM>. In such cases, the device identifier may be used to retrieve the stored password factor associated with the authentication type and the client device <NUM>. For example, a fingerprint input on a first client device may provide access to an authentication input in the protected storage of the first client device. The authentication input may have been previously randomly generated or uniquely generated. A fingerprint input on a second client device may provide access to an authentication input in the protected storage of the second client device, and the authentication input of the second client device may not match that of the first client device. The authentication inputs may be randomly or uniquely generated by each device prior to being stored in the protected storage. In some embodiments, different types of operating systems or applications on the client device(s) may handle biometric inputs differently, such that the authentication input obtained as a result of a biometric input may vary from one client device to another.

The method may comprise, in an operation entitled "TRANSMIT PASSWORD RECONSTRUCTION INFORMATION", transmitting <NUM>, from the server <NUM> to the client device <NUM>, information for reconstructing the password. The information for reconstructing the password may comprise the stored password factor and the computed application-based password component. In some embodiments, the stored password factor and the computed application-based password component are transmitted from the server <NUM> to the client device <NUM> in separate transmissions, and in other embodiments a single transmission comprising both the stored password factor and the application-based password component may be sent. In some embodiments, one or both of the stored password factor and the application-based password component may be sent via a backend channel to the client device <NUM>, and/or in an encrypted form.

The method may comprise, in an operation entitled "CALCULATE USER-BASED PASSWORD COMPONENT", computing 670b, by the client device <NUM>, a user-based password component from the protected authentication input and the received stored password factor. The user-based password component may be computed by applying an invertible, deterministic function to the protected authentication and the retrieved stored password factor. In this embodiment, since the user-based password component is computed by the client device <NUM>, there is no need for the protected authentication input to be transmitted to the server <NUM>. Avoiding an unnecessary transmission of the protected authentication input, which is a value used to reconstruct the password for accessing the password-protected resource, thus reduces the risk of interception and improves security. Moreover, in such a case, the server <NUM> would not receive the protected authentication input, meaning that the protected authentication input would remain secure even if the server <NUM> were compromised.

The method may comprise, in an operation entitled "RECONSTRUCT PASSWORD", reconstructing 680b, by the client device <NUM>, the password for accessing the password-protected resource <NUM>. The password may be reconstructed by combining the computed user-based password component and the received application-based password component, for example by applying a deterministic function to the user-based password component and the application-based password component. The reconstructed password may also be referred to as a raw password. In some embodiments, the reconstructed password may be used directly to access the password-protected resource <NUM>. In other embodiments, the reconstructed password may be adapted or adjusted to obtain an adjusted password for accessing the password-protected resource <NUM>. Adjusting the reconstructed password will be described with reference to <FIG>.

In the previous example, the user's password for the online shop was computed by the server. However, as described above, the user's password for the online may instead be computed by the user's mobile phone.

As in the example above, the user <NUM> may, on his mobile phone, access a login page for the online shop, for example in a browser or in an application on the mobile phone. The user may then activate, or select, the password management system, which may be a browser plug-in, extension, application, or the like. The user <NUM> may then input his fingerprint as a means of authentication. The user's mobile phone may then compare the received fingerprint with fingerprint data used for fingerprint authentication on the mobile phone, and upon determining that the fingerprint matches the fingerprint data, may access the protected storage of the mobile phone, and thereby access the authentication input, which may be a vector in this example.

The user's mobile phone may compute the protected authentication input, but in this case, the user's mobile phone may merely transmit the associated authentication type and a device identifier identifying the mobile phone to the server <NUM>. That is, the protected authentication input is not transmitted to the server <NUM> in this example. The server <NUM> may then retrieve the stored password factor associated with a fingerprint authentication on the mobile phone. The server <NUM> may then transmit the retrieved stored password factor to the mobile phone. Unlike in the previous example, the server <NUM> does not compute the user-based password component, since in this example, the server <NUM> has not been provided with the protected authentication input.

The server <NUM> may also obtain application information, such as the URL of the online shop that the user <NUM> wishes to access. The server <NUM> may calculate an application-based password component from the obtained application information, and optionally from information of the user's password management system account. The server <NUM> may then transmit the application-based password component to the mobile phone. The application-based password component may be transmitted simultaneously with the retrieved stored password factor in some cases.

The user's mobile phone may then compute the user-based password component from the received stored password factor and the protected authentication input, and may then reconstruct the password from the user-based password component and the received application-based password component. The reconstructed password may then be used to access the online shop. In some embodiments, however, the reconstructed password may be adjusted using one or more password requirements associated with the online shop, and the adjusted password may be used to access the online shop. Adjusting the password will be described with reference to <FIG>.

<FIG> and <FIG> schematically show examples of embodiments of a method of adjusting a reconstructed password. In the embodiment depicted in <FIG>, the reconstructed password is adjusted by the server <NUM>, whereas in the embodiment depicted in <FIG>, the reconstructed password is adjusted by the client device <NUM>.

The embodiment of <FIG> may be considered an optional progression of the method of <FIG>, e.g. the method of reconstructing a password on the server side. The embodiment depicted in <FIG> may be considered an optional progression of the method of either <FIG> or <FIG>.

Referring first to the embodiment of <FIG>, the method may comprise, in an operation entitled "OBTAIN PASSWORD REQUIREMENT(S)", obtaining 710a at least one password requirement. The server <NUM> may obtain the at least one password requirement, for example from a memory of the server or a remote memory accessible by the server <NUM>. Although the operation of obtaining at least one password requirement is depicted in <FIG> as occurring after the password has been reconstructed, e.g. after operation 680a as shown in <FIG>, it is to be understood that the operation 710a of obtaining the password requirement(s) of the password-protected resource <NUM> may occur at any time prior to adjusting the password. For example, the password requirement(s) of the password-protected resource <NUM> may be obtained when the user <NUM> creates an account with the password-protected resource <NUM> and said password requirement(s) may be stored remotely, such as in the database storage <NUM> of the server <NUM>, or in a further remote entity.

The method may comprise, in an operation entitled "ADJUST PASSWORD", adjusting 720a the password using the obtained at least one password requirement. In embodiments in which the server <NUM> is configured to adjust the reconstructed password, the operation of adjusting the password may be performed prior to the password being transmitted to the client device <NUM>. The at least one password requirement may comprise, for example, a minimum password length, a maximum password length, a character requirement, such as a number of uppercase and lowercase letters, numbers, special characters etc., and the like. Adjusting the password may comprise shortening the reconstructed password in accordance with a maximum password length and/or a minimum password length, replacing one or more characters with one or more special characters, numbers, or uppercase letters or the like. The adjusted password may be suitable for accessing the password-protected resource <NUM>.

Once the adjusted password is obtained in operation 720a, the adjusted password may be transmitted to the client device <NUM> in operation 690a', which is similar to the operation of 690a described with reference to <FIG>, although in operation 690a' the adjusted password is transmitted, rather than the merely reconstructed password. The transmission of the adjusted password from the server <NUM> to the client device <NUM> may be performed via a backend channel, and/or the adjusted password may be encrypted prior to transmission.

Referring now to the embodiment of <FIG>, the method may comprise, in an operation entitled "OBTAIN PASSWORD REQUIREMENT(S)", obtaining 710b at least one password requirement. The client device <NUM> may obtain the at least one password requirement from the server <NUM>. Although depicted as occurring after either the password is reconstructed in operation 680b or the password is received from the server <NUM> in operation 690a, it is to be understood that the operation 710b of obtaining the password requirement(s) of the password-protected resource <NUM> may occur at any time prior to adjusting the password. For example, the password requirement(s) of the password-protected resource <NUM> may be obtained when the user <NUM> creates an account with the password-protected resource <NUM> and said password requirement(s) may be stored for example, in the database storage <NUM> of the server <NUM>, or in a further remote entity.

The method may comprise, in an operation entitled "ADJUST PASSWORD", adjusting 720b the password using the obtained at least one password requirement. In embodiments in which the client device <NUM> is configured to reconstruct the password, the operation of adjusting the password may be performed after the password is reconstructed in operation 680b. In some embodiments, the server <NUM> may be configured to reconstruct the password, and to transmit the reconstructed password to the client device <NUM> in operation 690a'. In such embodiments, the client device <NUM> may be configured to adjust the reconstructed password after the reconstructed password is received from the server <NUM> in operation 690a. The at least one password requirement may comprise, for example, a minimum password length, a maximum password length, a character requirement, such as a number of uppercase and lowercase letters, numbers, special characters etc., and the like. Adjusting the password may comprise shortening the reconstructed password in accordance with a maximum password length and/or a minimum password length, replacing one or more characters with one or more special characters, numbers, or uppercase letters or the like. The adjusted password may be suitable for accessing the password-protected resource <NUM>.

Returning to the example introduced previously, the online shop may have a maximum password length (e.g. no more than <NUM> characters) and a requirement of at least one special character and one uppercase letter.

Once the password has been reconstructed, the password may be adjusted using these limitations, which may be obtained from the online shop (e.g. from the application of the online shop, or from its website). Either the user's mobile phone or the server <NUM> may adjust the length of the password, for example by selecting the first <NUM> characters of the reconstructed password and deleting the rest. The user's mobile phone or the server <NUM> may further adjust the password by randomly selecting one or more characters to swap with an uppercase version of the same character (if applicable), or with a special character. The adjusted password may then be used to access the online shop.

<FIG> shows a computer readable medium <NUM> having a writable part <NUM> comprising a computer program <NUM>, the computer program <NUM> comprising instructions for causing a processor system to perform a method, such as any or all of the methods of <FIG>, <FIG>, <FIG>, <FIG>, <FIG> and <FIG>. The computer program <NUM> may be embodied on the computer readable medium <NUM> as physical marks or by magnetization of the computer readable medium <NUM>. However, any other suitable embodiment is conceivable as well. Furthermore, it will be appreciated that, although the computer readable medium <NUM> is shown here as an SD card, the computer readable medium <NUM> may be any suitable computer readable medium, such as a compact disk, a hard disk, solid state memory, flash memory, etc., and may be non-recordable or recordable. The computer program <NUM> comprises instructions for causing a processor system to perform said method of encrypting and/or decrypting authentication information.

<FIG> shows in a schematic representation of a processor system <NUM>, an example of a client-side processor system <NUM> or a server-side processor system <NUM>, according to embodiments of the client device <NUM> and the server <NUM> shown in <FIG>. The processor system <NUM> comprises one or more integrated circuits <NUM>. Circuit <NUM> comprises a processing unit <NUM>, e.g., a CPU, for running computer program components to execute a method according to an embodiment and/or implement its modules or units. Circuit <NUM> comprises a memory <NUM> for storing programming code, data, etc. Part of memory <NUM> may be read-only. Circuit <NUM> may comprise a communication element <NUM>, e.g., an antenna, connectors or both, and the like. Circuit <NUM> may comprise a dedicated integrated circuit (IC) <NUM> for performing part or all of the processing defined in the method. Processor <NUM>, memory <NUM>, dedicated IC <NUM> and communication element <NUM> may be connected to each other via an interconnect <NUM>, for example a bus. The processor system <NUM> may be arranged for contact and/or contact-less communication, using an antenna and/or connectors, respectively.

For example, in an embodiment, processor system <NUM>, e.g., the client-side processor system <NUM> and/or the server-side processor system <NUM> as shown in <FIG>, may comprise a processor circuit and a memory circuit, the processor being arranged to execute software stored in the memory circuit. For example, the processor circuit may be an Intel Core i7 processor, ARM Cortex-R8, etc. In an embodiment, the processor circuit may be ARM Cortex M0. The memory circuit may be an ROM circuit, or a non-volatile memory, e.g., a flash memory. The memory circuit may be a volatile memory, e.g., an SRAM memory. In the latter case, the device may comprise a non-volatile software interface, e.g., a hard drive, a network interface, etc., arranged for providing the software.

While the processor system <NUM> is shown as including one of each described component, the various components may be duplicated in various embodiments. For example, the processor <NUM> may include multiple microprocessors that are configured to independently execute the methods described herein or are configured to perform steps or subroutines of the methods described herein such that the multiple processors cooperate to achieve the functionality described herein. Further, where the client device <NUM> and/or the server <NUM> is implemented in a cloud computing system, the various hardware components may belong to separate physical systems. For example, the processor <NUM> may include a first processor in a first server and a second processor in a second server.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments.

Claim 1:
A password management system for reconstructing a password for accessing a password-protected resource, the password management system comprising:
- a client device comprising:
- a client-side communication interface configured to:
- receive an authentication input from a user of the client device, and
- send, to a server device of the password management system, application information indicating the password-protected resource for which password reconstruction is requested; and
- a client-side processor system configured to:
- apply a non-invertible deterministic function to the authentication input to obtain a protected authentication input;
- the server device comprising:
- a database storage configured to store a database comprising stored password factors for corresponding protected authentication inputs, wherein a same user-based password component is obtained from each of the stored password factors and the corresponding protected authentication input;
- a server-side communication interface configured to:
- receive, from the client device, the application information, and
- retrieve, from the database, the stored password factor corresponding to the protected authentication input; and
- a server-side processor system configured to:
- compute an application-based password component from the application information;
wherein the client-side processor system or the server-side processor system is further configured to reconstruct a password by:
- calculating a user-based password component by combining the retrieved stored password factor and the protected authentication input using an invertible, deterministic function; and
- combining the user-based password component and the application-based password component to generate the password.