EP2871615A1 - Method for authenticating a user by an authentication module - Google Patents

Abstract

The present invention relates to a method of authentication of a user by an authentication module, said authentication module managing access to a plurality of services and comprising an authentication threshold for each service, at least two data d authentication being associated with said user, said method comprising the steps of acquiring at least one authentication data of the user, by means of an interface between this user and said authentication module; and verifying said at least one authentication data and assigning an authentication value to the user, depending on the result of the verification; comparing the authentication value with the threshold value for the required service. If the authentication value is equal to or greater than the threshold value, access to the service required by the user is allowed. If the authentication value is less than the threshold value, checking whether unused authentication data is available to this user; if no unused authentication data is available for this user, denial of access to the required service. If at least one unused authentication data is available for this user, the method is repeated by acquiring authentication data that is different from the one (s) presented previously and by combining the authentication values, the comparison being made between the threshold value and the combination of the authentication values.

Description

TECHNICAL AREA

The present invention relates to a method of authenticating a user by an authentication module managing access to a plurality of services.

PRIOR ART

The authentication of a user is a complex problem which must take into account several contradictory parameters such as in particular the security and the ease of use.

Current methods are based on one or more characteristics that the user and the service provider had to agree in advance. These characteristics or secrets, hereinafter referred to as authentication data, are stored in an authentication module associated with the service provider. Authentication data can be classified into three categories. One of the categories contains something that the user knows (password, answer to a secret question, secret rule, ..). Another category contains something that the user owns (mobile phone, smart card, ...) and the last category contains something that the user is, that is to say essentially the biometric data and the data. related to the usual behavior of the user (fingerprint, conformation of the eye, how to type a password, ..).

In the current authentication systems, to access a secure service offered by a service provider or accessible from a device or device, one or more authentication data are requested from the user. The responses given by the user are transmitted to an authentication module in which they are compared with the answers expected by this authentication module. If the answers match, access to the service is allowed.

It happens, under certain circumstances or in certain systems, that several authentication data are requested from the user and that a partial answer is not sufficient to access the service. This may be the case when using certain applications requiring a high level of security where for example a password is requested in addition to biometric information. This may also be the case when the authentication module detects something unusual such as an attempt to connect to a server from an unusual IP address. In this case, the authentication module may, after receiving a correct password, request a confirmation by asking for example the answer to a secret question or a "backup" e-mail address, stored during a phase initializing.

In all cases, the security level is set in advance and the system is not flexible. In addition, access to a service is done in a binary way, that is to say that a data is considered either just or false. For example, if the password entered by the user is false, access to the service is prohibited.

Current methods to verify the authenticity of a user wishing to access a service are therefore inflexible in that they do not allow to be adapted to the level of security required by the service and / or to certain wishes of the user. the user. If the level of security is too high, the ease of use may be low and the authentication procedure may be restrictive or even prohibitive for the user. On the contrary, if access is simple for the user, the security might be too low.

It is therefore desirable to have a flexible method, in which the level of security can be varied easily, for example depending on the service requested or depending on the choice of the user or the provider.

SUMMARY OF THE INVENTION

1. a) acquisition d'au moins une donnée d'authentification de l'utilisateur, au moyen d'une interface entre cet utilisateur et ledit module d'authentification;
2. b) vérification de ladite au moins une donnée d'authentification et attribution d'une valeur d'authentification à l'utilisateur, en fonction du résultat de la vérification;
3. c) comparaison de la valeur d'authentification avec la valeur de seuil pour le service requis;
4. d) si la valeur d'authentification est égale ou supérieure à la valeur de seuil, accorder l'accès au service requis par l'utilisateur;
5. e) si la valeur d'authentification est inférieure à la valeur de seuil, vérification si une donnée d'authentification non utilisée est disponible pour cet utilisateur;
6. f) si aucune donnée d'authentification non utilisée n'est disponible pour cet utilisateur, refus de l'accès au service requis;
7. g) si au moins une donnée d'authentification non utilisée est disponible pour cet utilisateur, répétition des étapes a) à f) en acquérrant une donnée d'authentification différente de celle(s) présentée(s) antérieurement et en combinant les valeurs d'authentification, ladite comparaison étant faite entre la valeur de seuil et la combinaison des valeurs d'authentification.

The object of the invention is achieved by a method of authentication of a user by an authentication module, said authentication module managing access to a plurality of services and including an authentication threshold for each service, at least two authentication data being associated with said user, said method comprising the following steps:

1. a) acquisition of at least one authentication data of the user, by means of an interface between this user and said authentication module;
2. b) checking said at least one authentication data and assigning an authentication value to the user, depending on the result of the verification;
3. c) comparing the authentication value with the threshold value for the required service;
4. d) if the authentication value is equal to or greater than the threshold value, grant access to the service required by the user;
5. e) if the authentication value is less than the threshold value, checking whether unused authentication data is available for this user;
6. f) if no unused authentication data is available for this user, denial of access to the required service;
7. g) if at least one unused authentication data is available for this user, repeating steps a) to f) by acquiring authentication data that is different from the one (s) previously presented and combining the values of authentication, said comparison being made between the threshold value and the combination of the authentication values.

According to this method, the authentication of a user wishing to access a service is very flexible. The security level may in particular be adapted to the service to which the user wishes to access and other conditions related to the environment, such as for example the time of day. A high level of security may be required for services such as payments or any services for which identity theft can have significant consequences, while a lower level of security may be required for services in which spoofing is required. identity has few consequences.

According to this invention, the user and the authentication module can share several secrets or authentication data. At least one of these authentication data is in principle introduced into the authentication module during an initialization phase, for example at the conclusion of a subscription. As explained in detail below, it is possible that a single authentication datum is not sufficient to access all the services offered by a provider. It is possible to introduce additional secrets or authentication data at the same time as the first authentication data, or subsequently, for example when the user wishes to be able to access additional services. Some authentication data may be acquired without the active and informed participation of the user. Thus, the behavior of the user can be stored without the latter being informed or not aware of it, this behavior forming a secret or an authentication data used in the context of the present invention.

According to one embodiment of the invention, the user can choose on the basis of which authentication data he wishes to access the service. For example, if a user can access a service by means of a smart card, a password or biometric data, he will have the choice of the type of data and will be able to access the service itself. it does not have the smart card available, for example by choosing to use the biometric data.

According to one variant, the authentication data to be provided to the authentication module may vary according to the type of services required. Some choice may however be left to the user. By way of example, access to a service for which identity theft will have little consequence may be authorized with, at the user's choice, information from a password, a smart card or a card. given biometric. Access to a service requiring a higher level of security may for example be done only with a password combined with a smart card or the password combined with a biometric data.

According to one variant, the data provider can suggest or impose on the user the authentication data that the latter must use to access the required service. In this variant, the provider may propose to use sufficient authentication data to access the required service, but having the lowest value possible for a third party intercepting this data. Indeed, the higher the value is for the user, the higher it is also for a usurper. It may therefore be interesting to use the information which is sufficient to access the service in question, but which has the least possible value for a usurper.

The method of the invention makes it possible to efficiently use authentication data for which the verification of the conformity between what is received by the authentication module and what is expected can be difficult to evaluate in a binary manner. . This can be the case for example by analyzing the behavior of the user when introducing a password or a passphrase. A given user will generally have a way to write his password reproducibly. In particular, the time required to write the password, the interval between two consecutive keys, will be very close from one time to another. Another user entering the same password will most likely behave differently. This type of data may be used in the method of the invention.

The minimum level of security is in principle set by the service provider. However, it is possible for the user to set a higher security level than this minimum level. This can be done by each user individually. This increase in the level of security is usually at the expense of ease of use. Each user will be able to adapt the level of security and ease of use according to their desires, within the framework set by the service provider. In general, however, a user can not set a security level below the minimum security level set by the service provider for the service.

SUMMARY DESCRIPTION OF THE DRAWINGS

• la figure 1 illustre sous forme de schéma bloc, le déroulement de la méthode de l'invention;
• la figure 2 représente de façon schématique, un exemple de réalisation de l'invention.

The present invention and its advantages will be better understood with reference to the appended figures and to the detailed description of a particular embodiment, in which:

• the figure 1 illustrates in block diagram form the flow of the method of the invention;
• the figure 2 shows schematically an exemplary embodiment of the invention.

MANNER OF REALIZING THE INVENTION

The present invention relates to a method for authenticating a user who wishes to access a service. This authentication is done by means of an authentication module, using an interface between the user and the authentication module.

This interface can be a keyboard such as an alphanumeric keyboard by means of which the user can enter an access code, a password, a passphrase, a value resulting from a calculation, ... The interface can also include a sensor and a processing device, the sensor can be used for the detection of biometric information such as fingerprints, facial recognition, retinal recognition, ... The interface generally comprises a display allowing the user to read instructions for him.

The user may have to enter data in an active way (password, PIN code, ...) or let the interface acquire the data (fingerprints, retinal recognition, voice recognition, ...)

The method of the invention can be used to access a specific service provider, this provider offering access to one or more services. Such a service provider may for example be a bank, in which case the services may be consulting one or more accounts, transferring money, payments, withdrawals, etc. Another provider could be a provider of access to pay-TV events or other events such as news, stock market information, weather, ...

The method of the invention can also be used to access services offered by a device such as a tablet, a car, etc. In this case, the authentication module is integrated into the device or device offering the required service.

Before starting an authentication procedure, the authentication module usually requires an identification of the user. This allows this module to determine which data and parameters to use to authenticate the user. This identification can be done for example by asking the user to enter a name (user name) or a personal code (PIN code). Of course, other ways of identifying a user can be considered.

In the case where the provider or the apparatus gives access to several different services, it is possible that this supplier or this apparatus asks the user to indicate first, the service to which he wishes to access. It is also possible that the service provider or the device requests this information in a second time only or that it does not ask for it at all.

When the user has identified himself, the authentication module may, for example, indicate to the user which services he / she may have access to as long as authentication succeeds.

If the authentication module asks which service the user wishes to access, this user enters his answer for example by means of the interface. If the authentication module does not ask which service the user wants to access, the interface acquires a first authentication data corresponding to the user. This first authentication data may be for example a password typed on a keyboard by the user. It can also be a biometric data such as an image of the retina of the user, etc. The first authentication data can also be a combination of several elements, for example a response to a calculation that the user must pronounce aloud, this calculation can be displayed on the screen or result from a secret rule agreed between the service provider and the user. In this case, voice recognition can be used as authentication data, possibly in addition to the secret rule.

This initial authentication data, as well as all the other authentication data, is associated with at least two values, one of the values being associated with the correct introduction of the authentication data and the other value being associated with the incorrect introduction of this authentication data. It should be noted that these values are not necessarily static. According to a preferred embodiment, the value associated with the correct introduction of the authentication data is positive. The value associated with the incorrect introduction of the authentication data may be zero or negative, for example. It could be positive, but less than the value associated with introducing a valid authentication value.

According to one variant, an authentication datum is associated with more than two values. This could be the case of an authentication datum using the behavior of the user. Since this behavior is not strictly reproducible from one time to the next, different values can be associated with the authentication data, with the rule that the more the behavior measured during a connection attempt moves away from the memorized behavior. by the authentication module, the lower the assigned value. Several values could also be associated with a password or passphrase, which would, to a certain extent, allow a user to enter a password or passphrase with a typo. The fact of having several values associated with an authentication datum is particularly interesting in cases where the authentication data is biometric data. Generally, when using biometric data, a relatively large number of elements are measured and a match is sought between the measured elements and the corresponding data stored for the user concerned. In the systems of the prior art, a limit value is set. If, for a number of points greater than the limit value, the measured elements and the stored data match, the authentication is considered to be correct. If the number of matching data is less than the limit value, the authentication is considered incorrect.

In the present invention, it is possible to assign a value dependent on the number of matching points, on a much finer scale than in existing systems.

The association between an authentication datum and an authentication value can be done in different ways. For example, it is possible to define a fixed value per type of authentication data. Generally, the more the type of authentication data is easy to forge, the lower the value. Thus, a password will generally have less value than a biometric data. In the case of assigning a fixed value per data type, a password will always have the same value regardless of the password.

It is also possible to assign a value that does not depend only on the type of data, but also on the data itself. In this case, a short password from the current vocabulary will have a lower value than a long password including uppercase and lowercase letters, special characters and numbers.

The authentication value for a given authentication data may also depend on other parameters such as for example the time of day and / or the day of the week. For example, the same password that allows access to payment services for businesses could have a high value during business hours and a lower value outside those periods. This makes it possible to take into account the fact that a request for access to the service outside working hours is more likely to be the act of an usurper than the same access request during the opening hours of the service. business. These hours of operation could be defined by the company itself, so individualized and would not necessarily be common to all services and service users of a specific provider. The authentication value may also depend on the user's history or access request. Thus, the introduction for the first time of a fake password could be associated with a first negative value. The introduction for the second time during the same access request, of a false password could be associated with a second negative value, different from the first value and having an absolute value greater than that of the first value. .

Alternatively, a weight could be associated with unsuccessful connection attempts. Thus, a weight of 1 could for example be associated with the introduction of a first false authentication datum, a weight of 1.2 at the introduction of a second false authentication datum and a weight of 1.5 at the same time. introducing a third false authentication data.

According to the method of the invention, when the interface has acquired an authentication datum, the authentication module assigns an authentication value to this datum. For this, the authentication module determines which are the different possible values for this authentication data, what are the conditions associated with these possible values and what specific condition, the authentication data introduced by the user filled.

According to a simple embodiment, the conditions can be the allocation of the maximum value if the authentication data input is identical to the authentication data stored or expected by the authentication module and a null value in the opposite case .

The authentication module then determines which threshold value must be reached to access the service required by the user. This threshold is stored by the authentication module may be fixed for a service or on the contrary depend on different parameters. These parameters can be, for example, a period in the day or certain days of the week. They can also consider the location from which a user wishes access a service. The place from which the access request originates could also be considered as an authentication datum.

In the next step of the method, the authentication module checks whether the initial authentication value reached by the user is greater than or equal to the threshold value for the service in question. If the answer to this question is positive, access to the service is allowed.

If the answer to this question is negative, the method continues by searching for additional authentication data for that user. The authentication module has, for each user, a directory of the available authentication data. In addition, authentication data that has already been used during the current login procedure is marked as unavailable or unused. The authentication module is therefore able to know if other authentication data are available for the user in question.

If no additional authentication data is available and the authentication value has not reached the threshold, access to the service is denied. If, on the other hand, one or more additional authentication data are available, the interface acquires such authentication data. This acquisition is similar to the acquisition of the initial authentication data.

It should be noted that if several authentication data are available, several variants are possible. According to a variant, the user chooses which authentication data he wishes to use. According to another variant, a usage order is defined and the authentication module sticks to this order. According to another variant, the authentication module chooses additional authentication data that will allow the user to access the service if the authentication is successful, but which will have the weakest possible authentication value to allow the user to access the service. access to this service. This can be interesting because, in principle, the more authentication data has a high authentication value, the more interesting it will be to intercept for a usurper. It is therefore wise to use, and potentially to disclose, information having the lowest value possible to achieve the desired goal, namely to access a specific service. In this context, it is also possible to indicate to the user what is the authentication value that he has reached, what threshold value he must reach and what are the authentication values of the different authentication data. which he has. Thus, he can choose at best, the authentication data that he will use.

When this authentication data is chosen and acquired by the authentication module by means of the interface, an authentication value is assigned to it as before. This value is named here additional authentication value. This additional authentication value is combined with the stored authentication value, which is the initial authentication value.

The combination could be simply the addition of both values. This addition is however not the only possible solution. For example, it is possible to add a "weight" to each authentication value. The weight could be 1 for the initial value, 0.9 for the first additional value, 0.8 for the second additional value, etc. It is clear that the invention is not limited to the combinations described here.

The result of this combination is called the combined authentication value, which value is stored either in place of the initial authentication value or in addition to this value. The combined authentication value is compared to the threshold value. If the threshold is reached or exceeded, access to the service is allowed. Otherwise, as before, the authentication module determines whether it still has additional authentication data for this user.

The method continues thus, combining at each turn, the stored authentication value and the additional authentication value. This method terminates either when the combined authentication value reaches or exceeds the threshold, or when all authentication data available for this user were used, without the threshold value being reached.

It is also possible to limit the number of laps of the method by imposing a maximum number of authentication data per connection attempt. Thus, even if the authentication module has for example five authentication data or five secrets for a given user, a maximum of three data can be used for access to the service. If the threshold is not reached after the use of these three authentication data, access is denied

• une carte à puce associée à une valeur de 60 lorsque cette carte donne un résultat correct et une valeur de -10 si la carte donne un résultat erroné;
• un mot de passe correspondant à une valeur de 30 lorsqu'il est introduit correctement et de zéro s'il est introduit de façon incorrecte;
• une donnée biométrique associée à la reconnaissance faciale de l'utilisateur, cette donnée étant associée à une valeur de 70 si la reconnaissance vocale est totalement réussie, de zéro si elle est partiellement réussie et de -50 si l'authentification échoue; et
• une règle secrète, consistant pour l'utilisateur, à multiplier par 4, la valeur que le fournisseur indique à l'utilisateur. Cette règle secrète est associée à une valeur de 55 si la réponse de l'utilisateur est juste et de -10 si elle est fausse

According to a concrete example illustrated by figure 2 , assume that the user has at his disposal four elements associated with authentication data, namely:

• a smart card associated with a value of 60 when this card gives a correct result and a value of -10 if the card gives a wrong result;
• a password corresponding to a value of 30 when correctly entered and zero if entered incorrectly;
• a biometric data associated with facial recognition of the user, this data being associated with a value of 70 if the speech recognition is totally successful, zero if it is partially successful and -50 if the authentication fails; and
• a secret rule, consisting for the user, to multiply by 4, the value that the supplier indicates to the user. This secret rule is associated with a value of 55 if the user's answer is correct and -10 if it is false

In a first example of use of the invention, the service provider offers two services. Access to the first service is allowed as soon as the authentication value exceeds a fixed threshold, for example 80. The threshold for the authentication value for accessing the second service is set to 120 in our example.

According to this exemplary embodiment, when the user wishes to access the service, the authentication module indicates to the user that he must provide authentication data. Depending on the implementation, the user may have the choice of the type of data that he wishes to introduce or on the contrary, this choice may be imposed by the authentication module.

Suppose here that the choice is left to the user and that the latter chooses to use the smart card. If the data read from the smart card by the interface corresponds to the data expected by the authentication module, an initial authentication value of 60 is assigned to this user. This initial authentication value is compared with the threshold value, which is 80 in the example considered, for the first service. The initial authentication value is less than the threshold value. Access to the first service is not allowed at this stage.

The authentication module then checks whether another authentication data is available for this user. This other data may be a password or any other authentication data, but must of course be different from the authentication data already used. For this, the authentication data already used during a connection attempt is marked as used or unavailable.

In the example described, three other authentication data are available, namely a password, a secret rule and a biometric data. According to a first embodiment, the user has the choice of the type of data that he wishes to use among the possible data not yet used. According to a second embodiment, the authentication module imposes the type of data. In an advantageous embodiment, the authentication module will impose the type of data that has the lowest possible value to reach the threshold value.

In our example, the user will use the password. If this password is entered correctly and corresponds to what is expected by the authentication module, an additional authentication value is assigned to the user. In the example, this value is 40.

The initial authentication value (60) and the additional authentication value (40) are combined. In the case of a combination corresponding to an addition, the result of the combination is referred to as the combined authentication value and would be 60 + 40 = 100, according to the example.

This combined authentication value is compared with the threshold value which is 80 in the example. The combined authentication value is greater than the threshold value. As a result, access to the first service is allowed.

It goes without saying that it is possible to define that access to the service is authorized as soon as the threshold value is reached or, on the contrary, to impose that threshold value is exceeded.

If the user wants to access the second service, which requires an authentication value greater than or equal to 120, it may for example use the secret rule, which is to multiply by 4, the value displayed on the interface. In the example considered, illustrated by the figure 2 , imagine that the user introduces a wrong result in response to the secret rule. This erroneous result is associated with a value of -50. Referring to the case where the combination is an addition of the authentication values, the combined authentication value will be 100 - 50 = 50. This value being lower than the threshold value for the second service, the user does not will not have access.

It should be noted that the value obtained is also lower than the threshold value for the first service. In this case, several variants are possible. In a first variant, since the user previously had access to the first service, as long as this user does not disconnect, the threshold value of the first service is not controlled and the user continues to have access to this first service. service.

In another variant, the threshold value is checked during each use of an authentication data item. Since the combined authentication value (50) is less than the threshold value (80) for the first service, access to this service is disabled and the user must use a new one. authentication data to access the services, whether the first or the second service.

In the example chosen, the authentication module still has an authentication data available for this user, namely a biometric data. The user who chooses to access the second service allows the interface to acquire the biometric data. If the authentication is done correctly, the authentication value of these biometric data, which is 70 in the example. The combination of the additional authentication value linked to the biometric data with the stored combined authentication value, linked to the other three data used, gives a value of 50 + 70 = 120. This combined authentication value is equal to the threshold 120 to access the second service. Access is therefore allowed to this user.

As can be seen in this example, it is possible for the user to be authorized to access a service despite the fact that at least one of the authentication data does not correspond to the expected result. As can also be seen from this example, the authentication values are stored during the running of the method.

The authentication data or secrets already used can not be used during this connection to a service, otherwise it would be possible to reach any value by entering the same data, for example a correct password. , a sufficient number of times. An authentication data already correctly used is therefore marked as such. Authentication data that the user has tried to use, unsuccessfully, such as an incorrect password, may be marked as unusable for this login attempt. It may also not be marked or marked as usable. In this case, the user can try as many times as he wishes, to use the authentication data. Finally, according to a preferred embodiment, each attempt to use authentication data is stored and the number of attempts during a connection session is limited, for example to three. If after three failed attempts, the authentication data does not have could be used, depending on the implementation chosen, access to the services is blocked, even if other authentication data are still available, or on the contrary, only the use of the authentication data that led to a failure is blocked, the other authentication data is still usable.

It should be noted that a mixture of these variants is possible. For example, for the consultation of bank accounts, three PIN code errors prohibit the use of this PIN during the current connection, this connection is still possible by means of a smart card. On the other hand, for withdrawals of money greater than X, three errors result in a blocking of the connection.

Now suppose that the user who is trying to access a service first enters a recognized smart card as valid and then the password incorrectly. In this example, the wrong password is associated with a value of -50. The authentication module, when verifying the existence of additional authentication data for this user will find that it has authentication data. Suppose the user enters a false result when using the secret rule. The combined authentication value will be 60 - 50 - 50 = -40, applying the principles described above. The authentication module will check if it has other authentication data. In a first embodiment, the authentication module will ask the user to use this data by introducing additional authentication data. In a second advantageous embodiment, before asking the user to enter additional authentication data, the authentication module will check whether the combination of the current combined authentication value (-40) and the value authentication that the user can obtain with all the authentication data available to this authentication module (70), is sufficient to reach the threshold value. If this is not the case, it will indicate to the user that access to the service is denied.

In the above example, the user has a current combined authentication value of -40. The authentication module has only one authentication data for this user, the value of which is 70. Regardless of the value obtained during the authentication using this additional data, the combined authentication value will not reach not the threshold value and access will be denied. It is therefore both useless and risky to ask the user to enter the last authentication data. Indeed, this data could be memorized by a usurper.

According to a concrete embodiment, if the service provider is for example a financial institution, a first threshold for a first service could be associated with the consultation of the user's accounts. A second threshold, generally higher than the first threshold could be associated with transfers from one user account to another account of the same user. A third threshold could be associated with payments of less than a certain amount, and a fourth threshold could be associated with payments in excess of that amount.

In the case where the provider is a provider of pay-TV events for example, a first threshold could be associated with access to one channel or set of determined channels and a second threshold could be associated with another set of pay-TV events. canals.

In these cases, several variants of the method of the invention may be used. According to a first variant, the user must indicate, for example before introducing the first authentication data, which service he wishes to access. It can also indicate the service just after the introduction of the first authentication data, before the introduction of the additional authentication data. The rest of the process proceeds in the same manner as described above, the threshold used depending on the service to which the user wishes to access.

According to a second variant, the user does not indicate to which service he wishes to access, but the authentication module indicates a list of services that the user can access based on the combined authentication value achieved. This list may increase as the user enters correct authentication data or on the contrary, decrease if incorrect data is entered. The user can stop entering authentication data as soon as the service he wishes to access is available.

The authentication module can also indicate to the user all the services offered, this indication being in the form of two lists. One of the lists may contain the services to which the user has access, in particular taking into account the combined authentication value reached by the user and the other list containing the services to which the user does not have access . The lists can be distinguished by colors, for example green for accessible services and red for others or black for accessible services and gray for others.

It should be noted that the authentication data, as well as the services offered, are not necessarily communicated by the authentication module. This results in the possibility for the latter to collect authentication data (including "behavior" or biometric) without the knowledge of the user and then use this data to develop the authentication value.

According to one variant, the combined value acquired by the user during a session is stored. Thus, if the user has introduced enough authentication data to view his accounts in a bank, but not allowed to make a payment, he will have to introduce additional authentication data when he wants to make a payment.

According to another variant, access to a service could be granted to a user as soon as the authentication value has reached the threshold, but the behavior of the service provider could be different depending on this authentication value. For example, access to a service could be granted once the authentication value has reached 50. However, if the authentication value has not exceeded 80, information for example relating to the operations performed or to a place or logical address from which operations are performed, are stored.

The present invention provides several variants for managing the authentication of a user. These variants can be combined with each other.

This invention offers great flexibility, which allows the user to access services in a manner that suits him best.

This user can also set to a certain extent, the level of security he wants. Thus, if the provider imposes a minimum value of 80 for access to a certain service, the user can define that for this specific service, the combined authentication value should be 90 instead of 80. Given that in this case is the user who chooses to increase the level of security, it will be ready to accept a decrease in ease of use that generally results.

It is also possible to provide that the provider defines a certain range, for example between 70 and 90, that it sets a certain value by default, for example 80 and that the user can specify the value that he wishes to use, in the range of values defined by the provider.

In the various examples and embodiments described above, it is possible to display, for the attention of the user, the authentication values. Thus, it is for example possible at any time to display the current authentication value and the authentication value of each data available for this user. On the contrary, it is also possible to display nothing and to have an authentication method that is completely transparent to the user. It is also possible to display only part of the information related to authentication.

Claims (11)

A method of authenticating a user by an authentication module, said authentication module managing access to a plurality of services and comprising an authentication threshold for each service, at least two authentication data being associated with said authentication user, said method comprising the following steps: a) acquisition of at least one authentication data of the user, by means of an interface between this user and said authentication module; b) checking said at least one authentication data and assigning an authentication value to the user, depending on the result of the verification; c) comparing the authentication value with the threshold value for the required service; d) if the authentication value is equal to or greater than the threshold value, grant access to the service required by the user; e) if the authentication value is less than the threshold value, checking whether unused authentication data is available for this user; f) if no unused authentication data is available for this user, denial of access to the required service; g) if at least one unused authentication data is available for this user, repeating steps a) to f) by acquiring authentication data that is different from the one (s) previously presented and combining the values of authentication, said comparison being made between the threshold value and the combination of the authentication values. Authentication method according to claim 1, characterized in that the authentication value assigned to an authentication datum depends on the concordance between the authentication data acquired by said interface and the corresponding authentication data stored by said module authentication. Authentication method according to claim 1, characterized in that the combination of the authentication values is an addition of said authentication values. Authentication method according to claim 1, characterized in that each authentication data is associated with at least two distinct authentication values. Authentication method according to claim 4, characterized in that one of the authentication values associated with an authentication data item is assigned in case of identity between the authentication data acquired by the interface and the data item. corresponding authentication stored by the authentication module, another of the authentication values being assigned if there is a difference between the authentication data acquired by the interface and the corresponding authentication data stored by the authentication module. Authentication method according to claim 1, characterized in that the authentication data are associated with at least three distinct authentication values, and in that the more there are differences between an authentication data acquired by the authentication interface and the corresponding authentication data stored by the authentication module, the lower the authentication value assigned. Authentication method according to claim 1, characterized in that each service is associated with a different threshold value. Authentication method according to claim 1, characterized in that the authentication module indicates to the user the authentication data that this user must use. Authentication method according to claim 8, characterized in that the authentication module chosen, according to the threshold corresponding to the service required by the user and according to the authentication value reached by the user, the service having the lowest possible authentication value allowing access to the service. Authentication method according to claim 1, characterized in that the authentication module indicates to the user at least the threshold value for access to said service, the combined authentication value reached by the user and the value authentication of the unused authentication data available to said user. Authentication method according to claim 1, characterized in that at least three authentication data are associated with said user and in which said user can access a service either by using a single authentication datum among said at least three data authentication, or by using at least two other authentication data among the authentication data different from the authentication data alone allowing access to said service.

Images