Authentication protocol using a one-time password

Abstract

A method of authenticating a client to a server is provided. The client has beforehand registered on the server by storing therein a valid identifier (ID) and a hashed word (H<com:Sub>0< / com:Sub>; <com:Math><semantics>Hn<annotation encoding="application / x-tex">H_n< / annotation>< / semantics>< / com:Math>) generated by applying a hash function to a disposable random variable (RAND<com:Sub>0< / com:Sub>; RAND<com:Sub>n< / com:Sub>; R<com:Sub>n< / com:Sub>) possessed / known by both the client and the server. The disposable random variable (RAND<com:Sub>0< / com:Sub>; RAND<com:Sub>n< / com:Sub>; R<com:Sub>n< / com:Sub>) is concatenated with a sequence (ISC<com:Sub>0< / com:Sub>; ISC<com:Sub>n< / com:Sub>) resulting from hashing the concatenation of a password (PWD) known from the client, said disposable random variable (RAND<com:Sub>0< / com:Sub>; RAND<com:Sub>n< / com:Sub>; <com:Math><semantics>Rn<annotation encoding="application / x-tex">R_n< / annotation>< / semantics>< / com:Math>) and an initialization sequence (ISC<com:Sub>init< / com:Sub>) being possessed by the client.

Description

AUTHENTICATION PROTOCOL USING A ONE-TIME PASSWORD The present invention relates to methods for authentication using cryptographic hash functions. Democratization and growth of expanding high-performance digital technologies and of the Internet have considerably changed the world of communication. Needs to preserve trade protection are thus numerous. This can be commonly achieved thanks to secure protocols and hence using cryptographic mechanisms. Authentication of entities, whether they are persons, objects or services, on information systems can be done either interactively by a human being or in an automatic manner without any human intervention. When a system needs to identify a client, as for instance for a bank trade, a connection to a website or a system authentication, the main constraint remains focused on the authentication problem, the client having to confirm his / her / its identity to the system in order that the latter can be sure of the client's identity. To ensure this constraint, such systems require the use of cryptographic primitives. Classically, when an authentication protocol is applied, a client has previously registered an account on a server of the system, preferably information comprising a login ID and a password, the login ID being for example an account name, an e-mail address or a unique identifier, as shown in Figure 1a. The server can identify the client because the server knows the password. The password is generally not kept as a plaintext on the server. The registration phase includes a cryptographic hashing computation F of the password in order to obtain an associated fingerprint, also named digest, message-digest or hashed data. Thanks to the properties of cryptographic hash functions, this digest is a fixed-size bit string that allows identifying a data without accessing to its contents. This digest is stored on the server and then used to check data integrity each time a password is entered, as shown in Figure 1b. As can be seen in Figures 1a and 1b, conventional authentication is based on the client communicating to the server a password in plaintext. This presents several security flaws: the communication channel could be overheard by a malicious attacker or the server could be hacked, so a person with bad intentions could easily get all the client's identification information and steal his / her / its identity. This becomes all the more harmful so since a study has revealed that the majority of online users keep the same password to access to different services they connect to. To overcome such a security problem, the use of encrypted connections, at least at the client's authentication phase, has been proposed. Although widely used nowadays, the efficiency of this solution remains limited. Indeed, most users still tend to use simple passwords that are easy to remember, but these passwords are considered to be "weak" from a security standpoint, because even cyphered, they are easy to reconstruct. Moreover, end-to-end encryption of communications is not always possible, especially in firms where IT managers want to control all data flows passing on their network. Moreover, using encryption protocols like HTTPS may be incompatible with other security constraints of an information system, especially when it is connected to internet. Several existing algorithms can eliminate the risk of intercepting passwords such as the SRP (Secure Remote Password) algorithm of which an enhanced version was described in the IEEE article "SRP-6: Improvements and Refinements to the Secure Remote Password Protocol", October 2002, and APAKE (Augmented Password Authenticated Key Exchange) algorithm of which an improved version was proposed in the article "zkPAKE: A simple Augmented PAKE protocol", 2015. The SRP algorithm uses a method similar to the Diffie-Hellman algorithm for the transmission of connection information, rendering inoperative any eavesdropping on communications. Although the user password is unlikely to be guessed in these authentication protocols, they still have drawbacks like a considerable consumption of resources due to complexity of algebraic computing that involves calculations of exponentials from both sides, client's and server's. These protocols do not manage one-time password authentication, i.e. an authentication in which a password is used for a single connection and is changed for others. Users need to renew their passwords explicitly and the server knows when users changed them. Thus, there is a need to tackle the abovementioned security challenges and improve authentication protocols. The present invention proposes to tackle a part or all of these challenges and manages to better authentication methods. One object of the invention, according to a first of its aspects, is a method of authenticating a client to a server, the client having beforehand registered on the server by storing therein a valid identifier and a hashed word generated by applying a hash function to a disposable random variable possessed / known by both the client and the server and concatenated with a sequence resulting from hashing the concatenation of a password known from the client, said disposable random variable and an initialization sequence possessed by the client, comprising: a. the client requesting a connection session to the server by transmitting his / her / its identifier; b. the server checking the existence of the identifier and allowing the client to continue the authentication process; c. the client transmitting to the server a backhash; d. the server applying to the concatenation of the hashed word and the backhash an inverse hash function obtained by algebraically solving said hash function; e. the server comparing the result of the inversion to the random variable it possesses / knows; and f. if there is a match in the comparison of previous step e, authentication is successful for this connection session and the client is allowed to store on the server a new hashed word corresponding to a different random variable and a possibly different password for the next connection session; otherwise, authentication fails. The terms "possess" and "know" an information are different in that possession, unlike knowledge, implies a storage of that information on a memory. The backhash is an information allowing to reconstruct, when combined with the hashed word, the plaintext data that was input of said hash function to output said hashed word. The method according to the invention provides an authentication protocol where the password is never transmitted to the server. The transmitted hashed word is partially dependent on the password that is correlated with a disposable random variable and other sequences by means of concatenation and hashing. This brings several advantages: modification of the password from one connection to another is transparent to the server, password is preserved independently of any database that could be compromised, eavesdropping of client / server exchanges does not engender a risk to thieve the client's identity and in case the disposable random variable is kept secret, use of weak passwords is no longer a security threat. Besides, thanks to the invention, little computation resources on behalf of the client are required. Complex and time-consuming computation caused by the inversion of the hash function is done on the server's side, but this has the advantage to prevent brute- force attacks that cannot be performed in a reasonable time. Detailed description of figures The invention will be better understood on reading the following detailed description of non-limiting exemplary embodiments thereof and on examining the appended drawings in which: - Figure 1a, previously described, illustrates a general framework for the registration of a client on a server using a state-of-the-art method; - Figure 1b, previously described, illustrates a general framework for the authentication of a client on a server using a state-of-the-art method; - Figure 2, is a hashing process of an input sequence using the SHA-3 function; - Figure 3, illustrates the generation of a security key using a modified SHA- 3 function; - Figure 4 schematically represents a registration of a client on a server, according to the invention; - Figure 5 schematically illustrates an authentication of a client to a server according to the invention; - Figure 6 schematically represents an embodiment of the invention; - Figures 7a and 7b schematically illustrate another embodiment of the invention; - Figure 8 is an analogous view of figure 6 representing a third embodiment of the invention; - Figures 9 and 10 schematically illustrate a fourth embodiment of the invention; and - Figures 11 and 12 schematically represents an example where several servers are used at the registration step and at the authentication step respectively. Cryptographic hash functions In a known manner, a cryptographic hash function F computes a hashed word h from an input data m: <com:Math><semantics>h=F(m)<annotation encoding="application / x-tex">h = F(m)< / annotation>< / semantics>< / com:Math>. To one input data m, corresponds only one hashed word h. No recognizable link exists between the input data m and the hashed word h. Cryptographic hash functions are advantageously non-bijective. Finding a data m by knowing h and doing the inverse operation <com:Math><semantics>F−1(h)<annotation encoding="application / x-tex">F^{-1}(h)< / annotation>< / semantics>< / com:Math> is nearly impossible. This ensures the high security of hash functions. A registering / authentication protocol using hash functions may comprise a first step of registration: the password Mclient of the client is hashed, possibly with a given salt, and only the hashed word <com:Math><semantics>Hclient=F(Mclient)<annotation encoding="application / x-tex">Hclient = F(Mclient)< / annotation>< / semantics>< / com:Math> is stored by the server. Then, when the client needs to be authenticated on the server, he / she enters a sequence M'client. The server computes <com:Math><semantics>H′<annotation encoding="application / x-tex">H'< / annotation>< / semantics>< / com:Math> client = <com:Math><semantics>F(M′<annotation encoding="application / x-tex">F(M'< / annotation>< / semantics>< / com:Math> client). If <com:Math><semantics>H′<annotation encoding="application / x-tex">H'< / annotation>< / semantics>< / com:Math> client is equal to <com:Math><semantics>H<annotation encoding="application / x-tex">H< / annotation>< / semantics>< / com:Math> client, the server authenticates the client and rejects him / her otherwise, as can be shown in Figure 1b. To ensure hash functions are secure, they are required to be theoretically and computationally collision, preimage and second-preimage resistant. A collision is when one can find two messages m and m' such as <com:Math><semantics>F(m)=F(m′)<annotation encoding="application / x-tex">F(m) = F(m')< / annotation>< / semantics>< / com:Math>. This attack is the easiest way to weaken a hash function and supply many tremendous results, as explained in the articles of Xiaoyun Wang "Collisions for hash functions MD4, MD5, haval-128 and ripeMD", in Crypto'04, page 199, 1997, of Xiaoyun Wang and Hongbo Yu "How to break MD5 and other hash functions", in EUROCRYPT, pages 19- 35, 2005, of Hongbo Yu and Xiaoyun Wang, "Multi-collision attack on the compression functions of MD4 and 3-pass haval", in ICISC, pages 206-226, 2007, of Christophe De Cannière et al. "Collisions for 70-step SHA-1: On the full cost of collision search", in Selected Areas in Cryptography, pages 56-73, 2007, of Somitra Kumar Sanadhya and Palash Sarkar, "New collision attacks against up to 24-step SHA-2", in INDOCRYPT, pages 91-103, 2008, and of Marc Stevens et al. "Chosen-prefix collisions for MD5 and applications", IJACT, 2(4):322-359, 2012. A preimage attack consists in, given a hash function F and a hashed word h, finding a message m such as <com:Math><semantics>F(m)=h<annotation encoding="application / x-tex">F(m) = h< / annotation>< / semantics>< / com:Math>. In the following, the term "capacity" has to be understood as the number of bits of a bit string. SHA-3 The hash function is preferably a SHA-3 hash function, especially using the Keccak algorithm. The invention may however be adapted to any cryptographic hash function. The SHA-3 hash function, using the Keccak algorithm, belongs to the family of sponge functions, that is to say functions that take as input an any-size data and deliver a fixed-size word, as explained in the articles of Guido Bertoni et al. "Sponge functions", in Ecrypt Hash Workshop 2007, "The keccak reference", january 2011, and "Keccak", in EUROCRYPT, pages 313-314, 2013. The bit string used for being concatenated with the input data in order to reach the capacity of the SHA-3 permutation needed to compute a hashed word with the desired final capacity is named the sponge. Sponge functions advantageously incorporates a one-way compression function, which consists, within the framework of Keccak, in considering a fixed-size word of the shortened final state. More generally, a one-way compression function is a function that transforms two fixed-length inputs into a fixed-length output. This type of mechanism is a part of the classical Merkel- Damgard construction. Thus, each cryptographic hash function is consequently correlated to a one-way compression function. The Keccak algorithm may be implemented from 12 to 24 rounds, with an internal state capacity equal to 200, 400, 800 or 1600. - In SHA-3, a trade-off between the values of the bitrate <com:Math><semantics>rb<annotation encoding="application / x-tex">r_b< / annotation>< / semantics>< / com:Math> and the capacity <com:Math><semantics>c<annotation encoding="application / x-tex">c< / annotation>< / semantics>< / com:Math> of the sponge determines the security of the hash function against preimage and collision attacks. The internal state capacity of the SHA-3 permutation is defined by the sum of the bitrate <com:Math><semantics>rb<annotation encoding="application / x-tex">r_b< / annotation>< / semantics>< / com:Math> and the capacity c of the sponge. is a hashing process of an input sequence using the SHA-3 function. The SHA-3 permutation has for example an internal state capacity of 1600 bits, including 64-bit words for internal states, corresponding to the predefined capacity <com:Math><semantics>Cp=rb+c<annotation encoding="application / x-tex">C_p = r_b + c< / annotation>< / semantics>< / com:Math>, with <com:Math><semantics>rb=576<annotation encoding="application / x-tex">r_b = 576< / annotation>< / semantics>< / com:Math> and <com:Math><semantics>c=1024<annotation encoding="application / x-tex">c = 1024< / annotation>< / semantics>< / com:Math>, as illustrated in Figure 2 for a Data sequence, concatenated with one or several bits, named "padding" word, in order to reach the bitrate <com:Math><semantics>rb<annotation encoding="application / x-tex">r_b< / annotation>< / semantics>< / com:Math>. The complete permutation function advantageously consists in 24 rounds of 5 sub-functions, containing only operations limited to bitwise XOR, bitwise AND, operator NOT and Modulo. A detailed description of a single round, with 64-bit words for internal states, may be: Require: 64-bit words for internal states 25 internal states at the beginning of the Round (i.e. [plaintext | padding | ISC] at the first round) for xx in <com:Math><semantics>{00,…,24}<annotation encoding="application / x-tex">\{00, \ldots, 24\}< / annotation>< / semantics>< / com:Math> and for i in <com:Math><semantics>{0,…,63}<annotation encoding="application / x-tex">\{0, \ldots, 63\}< / annotation>< / semantics>< / com:Math>. Denoted <com:Math><semantics>𝑴pro[i]<annotation encoding="application / x-tex">\mathbf{M}_{\mathrm{pro}}[i]< / annotation>< / semantics>< / com:Math> * 25 internal states at the end of the round (i.e. [digest | FSC] at the final round) for xx in {00, ..., 24} and for 1 in {0, ..., 63}. Denoted <com:Math><semantics>𝑴xx+[i]<annotation encoding="application / x-tex">\mathbf{M}_{xx}^+[i]< / annotation>< / semantics>< / com:Math> 25 intermediate states of the round for xx in <com:Math><semantics>{00,…,24}<annotation encoding="application / x-tex">\{00, \ldots, 24\}< / annotation>< / semantics>< / com:Math> and for i in <com:Math><semantics>{0,…,63}<annotation encoding="application / x-tex">\{0, \ldots, 63\}< / annotation>< / semantics>< / com:Math>. Denoted <com:Math><semantics>T2x[i]<annotation encoding="application / x-tex">T_{2x}[i]< / annotation>< / semantics>< / com:Math> 24 rounds at most (one round described here) • 24 Tota Constants 64-bits words (denoted XII) where "r' is the round number): (note: big endianness notation) | X

[00] : 0x000000000000001, X

[01] : 0x00000000000000000000000000000000000 X

[04] : 0x0000000000000808B, X

[05] : 0x0000000080000001, X

[06] : 0x800000008008081, X

[07] : 0x80000000008009, X108]: 0x000000000000000000X, X

[09] : 0x00000000000000000000000000000000000 X

[12] : 0x0000000080008008B, X

[13] : 0x80000000000008B, X

[14] : 0x800000000008089, X

[15] : 0x80000000008003, X

[16] : 0x80000000000000000000, X

[17] : 0x8000000000000000000, X

[18] : 0x00000000000000A, X

[19] : 0x8000000008000000A, X

[20] : 0x8000000080008081, X

[21] : 0x800000000000000000, X

[22] : 0x000000000000001, X

[23] : 0x800000008008 欁 XOR qate is <com:Math><semantics>Θ<annotation encoding="application / x-tex">\Theta< / annotation>< / semantics>< / com:Math> Not x 1s x AND quie is A OR Gate is V Modulo is W [Image disponible dans le document PDF, Image available in the PDF document] [Image disponible dans le document PDF, Image available in the PDF document] * STEP 1: Compute intermediate internal state <com:Math><semantics>Txx[i]<annotation encoding="application / x-tex">T_{xx}[i]< / annotation>< / semantics>< / com:Math> h 10 <com:Math><semantics>∀i∈[0,63],∀xx∈[0,24],Txx[i]=⨁MISM[xx][j][i]⨁MISM[xx][j][(i−1)%64]<annotation encoding="application / x-tex">\forall i \in [0,63], \ \forall xx \in [0,24], \ T_{xx}[i] = \bigoplus M_{ISM[xx][j]}[i] \bigoplus M_{ISM[xx][j]}[(i-1)\%64]< / annotation>< / semantics>< / com:Math> ) mm () ) | | | | | | | | | | | | | | | | | | | * STEP 2: Compute internal states at the end of the round <com:Math><semantics>Mxx+[i]<annotation encoding="application / x-tex">M_{xx}+[i]< / annotation>< / semantics>< / com:Math> <com:Math><semantics>∀i∈[0,63],M00+[i]=T0[i]⊕(T6[(i−44)%64]¯∧T12[(i−43)%64])⊕Xr<annotation encoding="application / x-tex">\forall i \in [0,63], \ M_{00}^{+}[i] = T_0[i] \oplus (\overline{T_6[(i-44)\%64]} \wedge T_{12}[(i-43)\%64]) \oplus X_r< / annotation>< / semantics>< / com:Math> <com:Math><semantics>∀i∈[0,63],∀xx∈[1,24]Mxx+[i]=TA0[(i−B0)%64]⊕(TA1[(i−B1)%64]¯∧TA2[(i−B2)%64])<annotation encoding="application / x-tex">\forall i \in [0,63], \ \forall xx \in [1,24] \ M_{xx}^+[i] = T_{A_0}[(i-B_0)\%64] \oplus (\overline{T_{A_1}[(i-B_1)\%64]} \wedge T_{A_2}[(i-B_2)\%64])< / annotation>< / semantics>< / com:Math> where <com:Math><semantics>Ay=MSM[xx][y]<annotation encoding="application / x-tex">A_y = MSM[xx][y]< / annotation>< / semantics>< / com:Math> and <com:Math><semantics>By=MSS[xx][y]<annotation encoding="application / x-tex">B_y = MSS[xx][y]< / annotation>< / semantics>< / com:Math> At the end of the final round, only the first n bits of the internal state are considered as the digest, this number of bits <com:Math><semantics>n<annotation encoding="application / x-tex">n< / annotation>< / semantics>< / com:Math> depending on the bitrate <com:Math><semantics>rb<annotation encoding="application / x-tex">r_b< / annotation>< / semantics>< / com:Math> and the capacity c of the sponge, n being equal for example to 512 in the case where <com:Math><semantics>rb=576<annotation encoding="application / x-tex">r_b = 576< / annotation>< / semantics>< / com:Math> and <com:Math><semantics>c=1024<annotation encoding="application / x-tex">c = 1024< / annotation>< / semantics>< / com:Math>. A particularity of SHA-3 is that the hash function is easily invertible from an internal state if all the bits are known, thanks to any procedure of polynomial complexity. Algebraic solving of cryptographic hash functions The algebraic solving of the hash function having generated the hashed word allows inverting said hash function and retrieving the original data. This can be done thanks to a Boolean encoding of the hash function primitive and a dedicated or generic algebraic solver. The algebraic solving of the hash function is advantageously a Boolean SATisfiability (SAT) solving. This type of constraint-problem solving is a well-known NP-complete problem, as described in the articles of A. Biere et al. "Handbook of Satisfiability", volume 185 of Frontiers in Artificial Intelligence and Applications, IOS Press, February 2009, and of Stephen A. Cook "The complexity of theorem proving procedures", in ACM Symposium on Theory of Computing, pages 151- 158, 1971. SATisfiability solving consists in determining if a Boolean expression F has at least one assignment of truth value {TRUE, FALSE}, also named an interpretation, to its variable so that it is true. F is preferably considered as a CNF-formula ("Conjunctive") Normal Form") which can be defined as a set of clauses, interpreted as a conjunction, where a clause is a set of literals, interpreted as a disjunction. More precisely, let <com:Math><semantics>𝒱={v1,...,vn}<annotation encoding="application / x-tex">\mathcal{V} = \{v_1, ..., v_n\}< / annotation>< / semantics>< / com:Math> be a set of n Boolean variables. A signed Boolean variable is named a literal. One can denote <com:Math><semantics>vi<annotation encoding="application / x-tex">v_i< / annotation>< / semantics>< / com:Math> and <com:Math><semantics>vi<annotation encoding="application / x-tex">v_i< / annotation>< / semantics>< / com:Math> the positive and negative literals referring to the variable <com:Math><semantics>vi<annotation encoding="application / x-tex">v_i< / annotation>< / semantics>< / com:Math> respectively. The literal <com:Math><semantics>vi<annotation encoding="application / x-tex">v_i< / annotation>< / semantics>< / com:Math> , respectively <com:Math><semantics>vi<annotation encoding="application / x-tex">v_i< / annotation>< / semantics>< / com:Math> , is TRUE, also said "satisfied", if the corresponding variable "vi is assigned to TRUE, respectively FALSE. Literals are commonly associated with logical AND and OR operators, respectively denoted by \(^\) and \(^\). A disjunction of literals is for instance denoted by <com:Math><semantics>v1∨v2¯∨v3∨v4<annotation encoding="application / x-tex">v_1 \vee \overline{v_2} \vee v_3 \vee v_4< / annotation>< / semantics>< / com:Math>. A clause is generally satisfied if at least one of its literals is satisfied, the expression F being satisfied if all its clauses are satisfied. In other words, if its exists an assignment of <com:Math><semantics>V<annotation encoding="application / x-tex">V< / annotation>< / semantics>< / com:Math> on {TRUE, FALSE} such as to make the expression <com:Math><semantics>F<annotation encoding="application / x-tex">F< / annotation>< / semantics>< / com:Math> TRUE, <com:Math><semantics>F<annotation encoding="application / x-tex">F< / annotation>< / semantics>< / com:Math> is said SAT, and UNSAT otherwise. Logical cryptanalysis consists in a two-step process using a modelling associated to an algebraic solving to model and. This can lead to the attack of a crypto- system, as explained in the articles of Fabio Massacci "Using walk-SAT and rel-sat for cryptographic key search", in IJCAI, pages 290-295, 1999, and of Fabio Massacci and Laura Marraro "Logical cryptanalysis as a SAT problem", J.Autom.Reasoning, pages 165- 203, 2000, in the three articles of Florian Legendre et al. "Encoding hash functions as a SAT problem", in ICTAI, pages 916-921, 2012, "Inverting thanks to SAT solving - an application on reduced-step MD*", in SECRYPT, pages 339-344, 2012, and "From a logical approach to internal states of hash functions - how SAT problem can help to understand SHA-* and MD*"; in SECRYPT, 2013, and in the Master thesis of Vegard Nossum "SAT-based preimage attacks on SHA-1", 2012. The article of Ilya Mironov and Lintao Zhang "Applications of SAT solvers to cryptanalysis of hash functions", in SAT, pages 102-115, 2006, presents an interesting result on applying logical cryptanalysis to cryptographic hash functions. In this article, the authors assume that the runtime of a cryptanalytic attack should be improved by using a logic formalism to express complex operations. They model a whole differential path for the well-known hash functions MD* and SHA-*, into a Boolean circuit and obtain conclusive results by using some of well-known SAT solvers. SATisfiability solving of SHA-3 Modeling a hash function as a SAT formula may be realized thanks to automatic tools, as for instance CryptLogVer described in the article of Pawel Morawiecki and Marian Srebrny "A SAT-based preimage analysis of reduced Keccak hash functions", in Inf. Process. Letters, 113(10-11):392-397, 2013, or by a handmade approach. Using a handmade approach allows obtaining an optimized resulting modeling, in terms of number of clauses and variables involved. Encoding the SHA-3 hash function as a SAT formula advantageously requires considering each bit of each word involved into the original primitive as a variable. Each internal operation, also corresponding to a logical circuit, is associated to a set of clauses. A direct SATisfiability solving of the Keccak hash function for a single round, with 64-bit words for internal states, may be expressed as: [Image disponible dans le document PDF, Image available in the PDF document] with the 25 internal states denoted <com:Math><semantics>Mxx[i]<annotation encoding="application / x-tex">M_{xx}[i]< / annotation>< / semantics>< / com:Math>, <com:Math><semantics>Txx[i]<annotation encoding="application / x-tex">T_{xx}[i]< / annotation>< / semantics>< / com:Math> an intermediate 64-bit word named "Theta", <com:Math><semantics>Exx[i]<annotation encoding="application / x-tex">E_{xx}[i]< / annotation>< / semantics>< / com:Math> a 64-bit word named "equivalency", and r the round number. The SAT encoding of the SHA-3 hash function according to the invention may comprise 869 120 clauses and 92 160 variables. These values may vary according to the implemented encoding technique. More features of the authentication method The backhash information, also called security key, is preferably obtained by a modified hash function configured to conserve all the bits of the last internal state computed from the input data of said hash function. Actually, the hash function HF is advantageously modified to form the hash function HF*, configured to conserve all the bits of the last internal state computed from the data to be preserved as input of the hash function HF, and divide it into two parts, preferably by ignoring the compression function correlated to said hash function HF. Preferably, the hashed word corresponds to a 512-least significant bits vector of a 1600- bits internal state, and the security key corresponds to a 1088-least significant bits vector of a 1600-bits internal state. The modified hash function <com:Math><semantics>HF*<annotation encoding="application / x-tex">HF^*< / annotation>< / semantics>< / com:Math> is configured to preserve all the standard specifications of hash function HF, but is also configured to compute any extra information that can lead to a security key allowing to reconstruct the plaintext data when combined with the hashed word computed by hash function HF. The generation of the security key <com:Math><semantics>Hc<annotation encoding="application / x-tex">H_c< / annotation>< / semantics>< / com:Math>, illustrated in Figure 3 for an internal state capacity of 1600 bits, may be expressed as: [Image disponible dans le document PDF, Image available in the PDF document] The capacity <com:Math><semantics>Chc<annotation encoding="application / x-tex">C_{hc}< / annotation>< / semantics>< / com:Math> of the security key <com:Math><semantics>Hc<annotation encoding="application / x-tex">H_c< / annotation>< / semantics>< / com:Math>, also named the final sponge capacity, is equal to the difference between the predefined capacity <com:Math><semantics>Cp<annotation encoding="application / x-tex">C_p< / annotation>< / semantics>< / com:Math> and the capacity <com:Math><semantics>Chb<annotation encoding="application / x-tex">C_{hb}< / annotation>< / semantics>< / com:Math> of the hashed word <com:Math><semantics>Hb<annotation encoding="application / x-tex">H_b< / annotation>< / semantics>< / com:Math>: <com:Math><semantics>Chc=Cp−Chb<annotation encoding="application / x-tex">C_{hc} = C_p - C_{hb}< / annotation>< / semantics>< / com:Math>. The sequence ISC, also called initial sponge, may be randomly sampled, comprising for example only bits equal to 0. In addition to being concatenated with such a sequence, the disposable random variable may be concatenated with a padding word in order to reach a predefined capacity of input data of the hash function. Likewise, in addition to being concatenated with the initialization sequence and the disposable random variable, the password may be concatenated with a padding word in order to reach a predefined capacity of input data of the hash function. Preferably, a padding word is a bit stream comprising a one followed by zeros. The disposable random variable is regarded as a nonce word which is intended for a single usage, i.e., it is meant to be used for one connection solely, especially in order to prevent replay attacks. The client and the server may exchange the disposable random variable in plaintext. Another alternative may be that a dedicated trustworthy server generates the disposable random variable and transmits it to the client and the server. A third alternative could be that the disposable random variable is generated by a specific device owned by both the client and the server. It could be either a hardware or a software token. A fourth alternative may consist in generating the disposable random variable for a current connection from the backhash of the immediately previous connection. Keeping track of the random variable between two connections at the client's or the generating device permits detection of identity theft. As regard to the alternative where the random variable is generated from the backhash, since it is possible to know the exact number of connections since registration, the client can check if an undue connection occurred since his / her / its last legitimate connection. Indeed, the entire chain of successive connections can be reconstructed, hence leading to the last backhash used. Moreover, when the disposable random variable is generated from the backhash, in addition to being concatenated with said sequence, the disposable random variable may be concatenated with a short data. In this case, the method according to the invention may further comprise the following steps: _ if there is a match in the comparison of step e, the client's identity and the short data are validated by the server which computes from the backhash the next disposable random variable and sends its hashed value to the client; --- the client computes the same way the next disposable random variable and compares its hashed value to the one received by the server; ---- if there is a match in the comparison of previous step, the server is authenticated to the client, otherwise authentication fails; - if the server's authentication is successful, the client can store on the server a new hashed word corresponding to the next disposable random variable and a possibly different password for the next connection session; - the server hashes the concatenation of the next random variable and the corresponding hashed word, and sends it to the client; - the client performs the same hashing operation and compares the obtained result with that sent by the server; and - if there is a match in the comparison of previous step, the client validates storing of the new hashed word by the server. These supplementary steps allow to authenticate the server to the client, and constitute a shield against Man in the Middle attacks. A variant of the invention may be that the disposable random variable is unknown to the server. In this case, the server should know the initial sponge value to be able to perform comparison at step e, on the basis of known ISC. Preferably, more than one server may be involved in the authentication process. More precisely, step d may be performed on at least two servers, each of them partially carrying out algebraic solving of the hash function. Actually, the inversion operation could be divided in sub-operations executed by these servers. The more servers are involved, the more difficult hacking all of them becomes. Likewise, the hashed word may be stored on several servers. The more different actors the consensus <com:Math><semantics>⟨server(s)+client⟩<annotation encoding="application / x-tex">\langle server(s) + client \rangle< / annotation>< / semantics>< / com:Math> involves, the better the security. Preferably, in each exchange between client and server, both parties or at least one of them may transmit a timestamp that is checked by the other party to verify synchronization and obviate replay attacks. Computer program products Another object of the invention, according to another of its aspects, is a computer program product comprising a computer-readable memory storing computer- executable instructions that can be read by a client. These instructions, when executed by a computer, control the client's authentication to a server on which is stored a valid identifier for the client and a hashed word generated by applying a hash function to a disposable random variable possessed / known by both the client and the server and concatenated with a sequence resulting from hashing the concatenation of a password known from the client, said disposable random variable and an initialization sequence possessed by the client, said instructions comprising: _ requesting a connection session to the server by transmitting the identifier and waiting for the server's acknowledgment; transmitting to the server a backhash; and _ if authentication is allowed for this connection session, having the possibility to store on the server a new hashed word corresponding to a different random variable and a possibly different password for the next connection session. Another object of the invention, according to another of its aspects, is also a computer program product comprising a computer-readable memory storing computer- executable instructions that can be read by a server. These instructions control a client's authentication to the server on which is stored a valid identifier for the client and a hashed word generated by applying a hash function to a disposable random variable possessed / known by both the client and the server and concatenated with a sequence resulting from hashing the concatenation of a password known from the client, said disposable random variable and an initialization sequence possessed by the client, said instructions comprising: - allowing a connection session to the client if the right identifier is transmitted by the client after his / her / its connection request; - waiting to receive from the client a backhash; --- applying the concatenation of the hashed word and the backhash to an inverse hash function obtained by algebraically solving said hash function; comparing the result of the inversion to the random variable possessed / known by the server; and - if comparison matches allowing authentication for this connection session, and allowing to store a new hashed word corresponding to a different random variable for the next connection session; otherwise rejecting authentication. Another object of the invention, according to another of its aspects, is as well a computer program product comprising a computer-readable memory storing computer- executable instructions that can be read by both a client and a server. These instructions control the client's authentication to the server on which is stored a valid identifier and a hashed word generated by applying a hash function to a disposable random variable possessed / known by both the client and the server and concatenated with a sequence resulting from hashing the concatenation of a password known from the client, said disposable random variable and an initialization sequence possessed by the client, said instructions cause the following actions to be performed: a. the client requesting a connection session to the server by transmitting his / her / its identifier; b. the server checking the existence of the identifier and allowing the client to continue the authentication process; C. the client transmitting to the server a backhash; d. the server applying to the concatenation of the hashed word and the backhash an inverse hash function obtained by algebraically solving said hash function; e. the server comparing the result of the inversion to the random variable it possesses / knows; and f. if there is a match in the comparison of previous step e, authentication is successful for this connection session and the client is allowed to store on the server a new hashed word corresponding to a different random variable and a possibly different password for the next connection session; otherwise, authentication fails. All features defined here above for the method of authentication apply to all three computer program products, objects of the invention. Figure 4 depicts the steps of a registration phase of a client on a server, necessary and prior to any connection to that server. A secured connection is preferably established between the client and the server, as for example a SSL or TLS connection ("Secure Sockets Layer" or "Transport Layer Security"). First and foremost, the client chooses an identifier ID whose availability is checked by the server. If the ID does not already exist in the server's database, registration is allowed. Then, the client gets a disposable random variable RAND<com:Sub>0< / com:Sub> that is also possessed by the server. The client concatenates this variable to a password PWD and an initialization sequence ISC<com:Sub>init< / com:Sub> and hashes the result of the concatenation to obtain the sequence ISC<com:Sub>0< / com:Sub>. This sequence is then concatenated to the random variable RAND<com:Sub>0< / com:Sub> and hashed by a modified hash function to give the hashed word H<com:Sub>0< / com:Sub> and the backhash FSC<com:Sub>0< / com:Sub>. At the registration phase, only the hashed word <com:Math><semantics>H0<annotation encoding="application / x-tex">H_0< / annotation>< / semantics>< / com:Math> is sent to the server that stores it in a memory along with the associated identifier ID. The memory may be an internal memory of the server or a remote one. At the end of the registration phase, the client possesses RAND<com:Sub>0< / com:Sub> and ISC<com:Sub>init< / com:Sub> and knows his / her / its identifier ID and password PWD, while the server possesses RAND<com:Sub>0< / com:Sub>, ID and H<com:Sub>0< / com:Sub> and knows nothing. It is worth noting that, at the registration phase, both client and server do not consume huge computation resources, assuming that the hash function is a Keccak-type one. In Figure 5, steps of an authentication phase of a client to a server are schematically represented. For genericity purposes, the random variable noted RAND<com:Sub>0< / com:Sub> at registration phase on previous figure is noted RAND<com:Sub>n< / com:Sub> in this figure. First, the client requests a connection to the server by transmitting his / her / its identifier ID. The server then checks its existence to allow continuation of the authentication process, if appropriate. Possessing RAND<com:Sub>n< / com:Sub> and ISC<com:Sub>init< / com:Sub>, and knowing his / her / its password PWD, the client is able to compute ISC<com:Sub>n< / com:Sub>, like he / she did at registering. Also, as was done at registration phase, the client hashes the concatenation of ISC<com:Sub>n< / com:Sub> and RAND<com:Sub>n< / com:Sub> to obtain the couple <com:Math><semantics>(Hn,FSCn)<annotation encoding="application / x-tex">(H_n, FSC_n)< / annotation>< / semantics>< / com:Math>. The backhash information FSC<com:Sub>n< / com:Sub> can be now transmitted to the server that possesses the hashed word <com:Math><semantics>Hn<annotation encoding="application / x-tex">H_n< / annotation>< / semantics>< / com:Math> since the end of registration phase. By applying an inverse hash function to said couple, the server can reconstruct the random variable RAND<com:Sub>n< / com:Sub> used by the client, and compare it to the one it possesses. The comparison should match if the client has entered the right password. At this step, the server can get from the client a new proof of authentication associated with a new hashed word <com:Math><semantics>Hn+1<annotation encoding="application / x-tex">H_{n+1}< / annotation>< / semantics>< / com:Math> computed from a new random variable RAND<com:Sub>n+1< / com:Sub> and possibly a new password PWD in case the client wants to change his / her / its password for the next connection session. Such protocol offers the option of a one-time password. And as long as the password is entangled with a nonce random variable and a sequence ISC, weak passwords, as for example « azerty », « 12345 » or « 00000 », may be authorized and used without any risks, provided the random variable is kept secret. It should be noted that the most resource-consuming computation in the authentication method according to the invention is the algebraic solving of hash function. This computation is achieved by the server. So, implementation of such method on the client is rather cheap and simple, hence allowing to use the authentication process on low- power objects or sensors or connected objects e.g. cameras and remote actuators. For instance, in a remote control of opening / turning on (a car, a door, etc.), the identifier ID is a unique number that is factory set, having 128 bits. The password, a value of 256 bits, may be either factory set, chosen or generated by the user or even derived from a biometric measure like a digital print, iris of the eye, etc. In case the disposable random variable is generated from the backhash, the short data may be not used or may represent a control identifier (opening / closing, turning on / off, etc.). In various sensors such as motion / smoke / flood detectors and measurement tools such as electric / water meters, the identifier ID and the password are also the same as for a remote control of opening / turning on, but in case the disposable random variable is generated from the backhash, the short data is directly measured by the sensor (intensity, meter value, etc.). The authentication method according to the invention requires generating a different random variable whenever a registration or a connection is requested. This constraint mitigates replay attacks and also prevents an observer from the ability to determine whether the password has changed or not between two connections. There are different ways allowing the client and the server to share possession of the disposable random variable. Since it is not a confidential data, the random variable could be exchanged in plaintext between the client and the server, as shown in the embodiment of Figure 6. The client can transmit to the server the random variable along with the hashed word, and the server can transmit to the client the random variable with the identifier acknowledgment at the beginning of the authentication phase. In the embodiment illustrated in Figures 7a and 7b, generation of the random variable is delegated to a dedicated server named "Cryptonid server". As shown in Figure 7a, at registration phase, the client transmits his / her / its identifier and the server's identity to the "Cryptonid server". Then, this one stores these pieces of information with a random variable that it generates and transmits to the client to enable him / her to compute the hashed word. Later during the authentication phase, and just after receiving the backhash, the server transmits its identity and the client's identifier to the "Cryptonid server" as can be seen in Figure 7b. The dedicated server then communicates the random variable. The random variable may also be generated and shared via a specific device, as shown in the embodiment of Figure 8. This device is in possession of both client and server and could be physical, for example a chip card like in SecurID technology, or software-based for instance, a smartphone or a computer application, etc. Figure 9 schematically depicts another embodiment of the invention where the disposable random variable is computed from the backhash of previous connection. This computation is done on both sides: the client's and the server's. Generating the random variable this way, independently of any external service / device, ensures that the same value of random variable cannot be reused and permits to authenticate the server to the client, as well. Figure 10 schematically represents a scenario of mutual authentication between the client and the server. After initiating a secure connection, the value of the random variable RAND<com:Sub>n< / com:Sub> is communicated to both parties by a trusted entity. Still while having a secure connection, the client transmits to the server the hashed word H<com:Sub>n< / com:Sub>, computed on the basis of the random variable RAND<com:Sub>n< / com:Sub> and a short data d<com:Sub>n< / com:Sub> that could be 256 bits long. Then, not necessarily with a secure connection, the client sends the backhash F<com:Sub>n< / com:Sub> to the server that will be able to inverse the hash function in order to check the correspondence of random variables. If the random variable R'<com:Sub>n< / com:Sub> resulting from the inversion is equal to the one stored, the server authenticates the client. Thereafter, the server calculates the random variable R'<com:Sub>n+1< / com:Sub> to be used for the next connection, on the basis of the backhash <com:Math><semantics>Fn<annotation encoding="application / x-tex">F_n< / annotation>< / semantics>< / com:Math>. Its hashed value <com:Math><semantics>h(Rn+1′)<annotation encoding="application / x-tex">h(R'_{n+1})< / annotation>< / semantics>< / com:Math> is then transmitted to the client. From its side, the client also computes the same way the next random variable <com:Math><semantics>Rn+1<annotation encoding="application / x-tex">R_{n+1}< / annotation>< / semantics>< / com:Math>. If <com:Math><semantics>h(Rn+1)=h(Rn+1′)<annotation encoding="application / x-tex">h(R_{n+1}) = h(R'_{n+1})< / annotation>< / semantics>< / com:Math>, the client validates the server's authentication and computes the next hashed word <com:Math><semantics>Hn+1<annotation encoding="application / x-tex">H_{n+1}< / annotation>< / semantics>< / com:Math> using <com:Math><semantics>Rn+1<annotation encoding="application / x-tex">R_{n+1}< / annotation>< / semantics>< / com:Math>, <com:Math><semantics>dn+1<annotation encoding="application / x-tex">d_{n+1}< / annotation>< / semantics>< / com:Math> and possibly another password. The server then stores the hashed word <com:Math><semantics>Hn+1<annotation encoding="application / x-tex">H_{n+1}< / annotation>< / semantics>< / com:Math> received from the client, and calculates <com:Math><semantics>h(Hn+1,Rn+1)<annotation encoding="application / x-tex">h(H_{n+1}, R_{n+1})< / annotation>< / semantics>< / com:Math> and sends it to the client, <com:Math><semantics>Hn+1<annotation encoding="application / x-tex">H_{n+1}< / annotation>< / semantics>< / com:Math> being the hashed word it should have recorded and that should correspond to <com:Math><semantics>Hn+1<annotation encoding="application / x-tex">H_{n+1}< / annotation>< / semantics>< / com:Math> received. The client validates recording of last hashed word if <com:Math><semantics>h(Hn+1,Rn+1)=h(Hn+1,Rn+1)<annotation encoding="application / x-tex">h(H_{n+1}, R_{n+1}) = h(H_{n+1}, R_{n+1})< / annotation>< / semantics>< / com:Math> <com:Math><semantics>Rn+1<annotation encoding="application / x-tex">R_{n+1}< / annotation>< / semantics>< / com:Math>). After that, next connection can be initiated; otherwise, if current connection is interrupted at any step, authentication process is reinitiated from the beginning. These validation steps are useful to prevent Man in the Middle attacks. Figure 11 and 12 represent an embodiment where several servers <com:Math><semantics>s0,…,sxp<annotation encoding="application / x-tex">s_0, \dots, s_{xp}< / annotation>< / semantics>< / com:Math> are involved at the registration step and at the authentication step respectively. At registration step, the first server <com:Math><semantics>s0<annotation encoding="application / x-tex">s_0< / annotation>< / semantics>< / com:Math> does not store the digest value <com:Math><semantics>h0<annotation encoding="application / x-tex">h_0< / annotation>< / semantics>< / com:Math> but only stores the backhash fsc<com:Sub>0< / com:Sub> resulting from the computation of H(H<com:Sub>n< / com:Sub>, s<com:Sub>0< / com:Sub>), s<com:Sub>0< / com:Sub> being a unique identifier of this server. The digest <com:Math><semantics>h0<annotation encoding="application / x-tex">h_0< / annotation>< / semantics>< / com:Math> is sent to the next server <com:Math><semantics>sx1<annotation encoding="application / x-tex">s_{x1}< / annotation>< / semantics>< / com:Math>. The destination server identifier is chosen using the digest value, so it is unpredictable without knowing all the information the first server knows about the user identity. Then, the next server proceeds the same way constructing a cycle that ends by sending the last hash and server identifier <com:Math><semantics>(hp,sxp)<annotation encoding="application / x-tex">(h_p, s_{xp})< / annotation>< / semantics>< / com:Math> to the first server <com:Math><semantics>s0<annotation encoding="application / x-tex">s_0< / annotation>< / semantics>< / com:Math>. At authentication step, the first server s<com:Sub>0< / com:Sub> sends back the hash to the last server s<com:Sub>xp< / com:Sub> which computes the previous hash and server identifier based on the backhash information fsc<com:Sub>p< / com:Sub> it stored at registration step, and so on until the digest h<com:Sub>0< / com:Sub> returns back to the first server that can verify the user identity. The invention is not limited to the examples that have just been described. In particular, features from the embodiments illustrated may be combined within embodiments that are not illustrated. Other algebraic solving than SATisfiability solving may be used, as for example automated reasoning techniques, meta-heuristics, finite algebra solving techniques, or Gröbner bases. The method for authentication according to the invention and as defined above can be used in order to avoid the circulation of plaintext passwords on a network. The invention is not restricted to authentication on an information system but may be used in a lot of different applications, as for example in biometrics, internet of things, online transactions, locks, open / close control, turning on / off of devices, transmission of commands needing to be secured, etc., and wherever an authentication is required, demanding a high level of security. The expression "comprising a" or "including a" must be understood as being synonymous with "comprising at least one" or "including at least one", unless specified otherwise.

Claims

1. A method of authenticating a client to a server, the client having beforehand registered on the server by storing therein a valid identifier (ID) and a hashed word (H 0 ; H n ) generated by applying a hash function to a disposable random variable (RAND 0 ; RAND n ; R n ) possessed / known by both the client and the server and concatenated with a sequence (ISC 0 ; ISC n ) resulting from hashing the concatenation of a password (PWD) known from the client, said disposable random variable (RAND 0 ; R A N D n RAND_n ; R n R_n ) and an initialization sequence (ISC init ) possessed by the client, comprising: a. the client requesting a connection session to the server by transmitting his / her / its identifier (ID); b. the server checking the existence of the identifier (ID) and allowing the client to continue the authentication process; c. the client transmitting a backhash (FSC n ; F n ) obtained by a modified hash function configured to conserve all the bits of the last internal state computed from the input data of said hash function; d. the server applying to the concatenation of the hashed word ( H 0 ; H n ) (H_0; H_n) and the backhash (FSC n ; F n ) an inverse hash function obtained by algebraically solving said hash function; e. the server comparing the result of the inversion to the random variable (RAND 0 ; RAND n ; R n ) it possesses / knows; and f. if there is a match in the comparison of previous step e, authentication is successful for this connection session and the client is allowed to store on the server a new hashed word ( H n + 1 ) (H_{n+1}) corresponding to a different random variable (RAND n+1 , R n + 1 R_{n+1} ) and a possibly different password for the next connection session; otherwise, authentication fails.

2. The method according to claim 1, wherein the hash function is a SHA-3 hash function.

3. The method according to any one of claims 1 or 2, wherein the algebraic solving of the hash function is a SATisfiability solving.

4. The method according to any one of the claims 1 to 3, wherein in addition to being concatenated with the sequence (ISC 0 ; ISC n ), the disposable random variable (RAND 0 ; RAND n ; R n ) is concatenated with a padding word in order to reach a predefined capacity of input data of the hash function.

5. The method according to any one of the claims 1 to 4, wherein in addition to being concatenated with the initialization sequence (ISC init ) and the disposable random variable (RAND 0 ; RAND n ; R n ), the password (PWD) is concatenated with a padding word in order to reach a predefined capacity of input data of the hash function.

6. The method according to any one of the claims 1 to 5, wherein the client and the server exchange the disposable random variable (RAND 0 ; RAND n ; R n ) in plaintext.

7. The method according to any one of claims 1 to 6, wherein a dedicated server generates the disposable random variable (RAND 0 ; RAND n ; R n ) and transmits it to the client and the server.

8. The method according to any one of claims 1 to 6, wherein the disposable random variable (RAND 0 ; RAND n ; R n ) is generated by a specific device owned by both the client and the server.

9. The method according to any one of claims 1 to 6, wherein the disposable random variable for a current connection is generated from the backhash (FSC n ; F n ) of the immediately previous connection.

10. The method according to claim 9, wherein in addition to being concatenated with the sequence (ISC 0 ; ISC n ), the disposable random variable (RAND 0 ; RAND n ; R n R_n ) is concatenated with a short data ( d 0 d_0 ; d n d_n ), method further comprising: - if there is a match in the comparison of step e, the client's identity and the short data (d 0 ; d n ) are validated by the server which computes from the backhash (FSC n ; F n ) the next disposable random variable and sends its hashed value to the client; - the client computes the same way the next disposable random variable and compares its hashed value to the one received by the server; - if there is a match in the comparison of previous step, the server is authenticated to the client, otherwise authentication fails; .... if the server's authentication is successful, the client can store on the server a new hashed word ( H n + 1 ) (H_{n+1}) corresponding to the next disposable random variable (RAND n+1 , R n + 1 R_{n+1} ) and a possibly different password for the next connection session; - the server hashes the concatenation of the next disposable random variable ( R A N D n + 1 , R n + 1 ) (RAND_{n+1}, R_{n+1}) and the corresponding hashed word ( H n + 1 ) (H_{n+1}) , and sends it to the client; ---- the client performs the same hashing operation and compares the obtained result with that sent by the server; and _ if there is a match in the comparison of previous step, the client validates storing of the new hashed word ( H n + 1 ) (H_{n+1}) by the server.

11. The method according to any one of the claims 1 to 10, wherein step d is performed on at least two servers ( s 0 , s x 1 , . . . , s x p ) (s_0, s_{x_1}, ..., s_{x_p}) , each of them partially carrying out algebraic solving of the hash function.

12. A computer program product comprising a computer readable memory storing computer-executable instructions that can be read by a client, wherein these instructions, when executed by a computer, control the client's authentication to a server on which is stored a valid identifier (ID) for the client and a hashed word ( H 0 ; H n ) (H_0; H_n) generated by applying a hash function to a disposable random variable (RAND 0 ; RAND n ; R n ) possessed / known by both the client and the server and concatenated with a sequence (ISC 0 ; ISC n ) resulting from hashing the concatenation of a password (PWD) known from the client, said disposable random variable (RAND 0 ; RAND n ; R n ) and an initialization sequence (ISC init ) possessed by the client, said instructions comprising: requesting a connection session to the server by transmitting the identifier (ID) and waiting for the server's acknowledgment (ACK); - transmitting to the server a backhash (FSC n ; F n ) obtained by a modified hash function configured to conserve all the bits of the last internal state computed from the input data of said hash function; and _ if authentication is allowed for this connection session, having the possibility to store on the server a new hashed word ( H n + 1 ) (H_{n+1}) corresponding to a different random variable (RAND n + 1 n+1 , R n + 1 n+1 ) and a possibly different password for the next connection session.

13. A computer program product comprising a computer readable memory storing computer-executable instructions that can be read by a server, wherein these instructions, when executed by a computer, control a client's authentication to the server on which is stored a valid identifier (ID) for the client and a hashed word ( H 0 ; H n ) (H_0; H_n) generated by applying a hash function to a disposable random variable (RAND 0 ; RAND n ; R n ) possessed / known by both the client and the server and concatenated with a sequence (ISC 0 ; ISC n ) resulting from hashing the concatenation of a password (PWD) known from the client, said disposable random variable (RAND 0 ; RAND n ; R n ) and an initialization sequence (ISC init ) possessed by the client, said instructions comprising: _ allowing a connection session to the client if the right identifier (ID) is transmitted by the client after his / her / its connection request; ..... waiting to receive from the client a backhash (FSC n ; F n ) obtained by a modified hash function configured to conserve all the bits of the last internal state computed from the input data of said hash function; applying the concatenation of the hashed word ( H 0 ; H n ) (H_0; H_n) and the backhash (FSC n ; F n ) to an inverse hash function obtained by algebraically solving said hash function; comparing the result of the inversion to the random variable (RAND 0 ; R A N D n RAND_n ; R n R_n ) possessed / known by the server; and .... if comparison matches, allowing authentication for this connection session, and allowing to store a new hashed word ( H n + 1 ) (H_{n+1}) corresponding to a different random variable (RAND n + 1 n+1 , R n + 1 n+1 ) for the next connection session; otherwise rejecting authentication.

14. A computer program product comprising a computer-readable memory storing computer-executable instructions that can be read by both a client and a server, wherein these instructions, when executed by a computer, control the client's authentication to the server on which is stored a valid identifier (ID) and a hashed word ( H 0 ; H n ) (H_0; H_n) generated by applying a hash function to a disposable random variable (RAND 0 ; RAND n ; R n ) possessed / known by both the client and the server and concatenated with a sequence (ISC 0 ; ISC n ) resulting from hashing the concatenation of a password (PWD) known from the client, said disposable random variable (RAND 0 ; RAND n ; R n ) and an initialization sequence (ISC init ) possessed by the client, said instructions causing: a. the client to request a connection session to the server by transmitting his / her / its identifier (ID); b. the server checking the existence of the identifier (ID) and allowing the client to continue the authentication process; c. the client transmitting to the server a backhash (FSC n ; F n ) obtained by a modified hash function configured to conserve all the bits of the last internal state computed from the input data of said hash function; d. the server applying to the concatenation of the hashed word ( H 0 ; H n ) (H_0; H_n) and the backhash (FSC n ; F n ) an inverse hash function obtained by algebraically solving said hash function; e. the server comparing the result of the inversion to the random variable (RAND 0 ; RAND n ; R n ) it possesses / knows; and f. if there is a match in the comparison of previous step e, authentication is successful for this connection session and the client is allowed to store on the server a new hashed word ( H n + 1 ) (H_{n+1}) corresponding to a different random variable (RAND n + 1 n+1 , R n + 1 n+1 ) and a possibly different password for the next connection session; otherwise, authentication fails.