KR20090035381A - Secure user session managing method under web environment and recording medium recorded program executing it - Google Patents

Abstract

A user session managing method and a recording medium recording a program by using an authentication algorithm of trial-response method on web are provided to protect the session of the user by applying authentication algorithm to HTTP(HyperText Transfer Protocol). A server calculates a first server authentication value by using a sharing key stored in a server and random number(S11). The server newly produces the random number. The server uses the shared key stored in the random number and server and the second server authenticator is calculated(S15). The server including random number transmits the HTTP response to the client. The HTTP request including server is the cookie from the client is received. The cookie comprises the client authentication value. By using the random number included in the shared key stored in client and the HTTP response which client is transmitted, the client authentication value is calculated.

Description

Secure user session managing method under web environment and recording medium recorded program executing it}

The present invention relates to a method for secure user session management in a web environment.

In general, the web environment is an open environment in which a large number of unspecified users access and receive web services. In web services, a session is a series of consecutive requests from a user in the hypertext transfer protocol (HTTP) protocol, which is used to transfer documents between a web server and a user's Internet browser. Refers to information stored and exchanged between a server and a client in order to process a service request.

In order to manage a user's session in a web environment, the user has been previously identified or authenticated using a cookie of the client. For example, a cookie may contain a user's IP, a hashed user's password, and a digital signature.

However, since the cookie of the client is automatically sent to the server in plain text every HTTP request, the information contained in the cookie is exposed to an attacker. In addition, there is a problem that cannot be a fundamental solution in protecting a user's session by using a cookie because it is vulnerable to IP spoofing or offline dictionary attack.

That is, the cookie used to maintain the session of the user can be easily exposed through sniffing or the like. ActiveX to prevent this has a problem that does not burden the user or provide convenience. Also, if you have a problem installing ActiveX itself, you may not even be able to access Web services.

The present invention provides a user session management method capable of protecting a user's session by applying a challenge-response authentication algorithm to the HTTP protocol, and a recording medium on which a program for performing the same is recorded.

The present invention also provides a method for managing user sessions overcoming the shortcomings of conventional cookies, which are automatically transmitted in plain text by using a storage space other than a cookie to store a secret key in a web browser, and a recording medium on which a program for performing the same is recorded. To provide.

In addition, when the challenge-response method is applied to the HTTP protocol, the present invention can reduce an error in which a shared key revalidation routine is added when the random number shared by the user's behavior pattern or the network situation is not synchronized. Provide management methods.

In addition, the present invention provides a user session management method that can flexibly respond to simultaneous HTTP requests by setting a threshold time.

According to an aspect of the present invention, a method for managing a user session with a client in a server connected to the client via a network in a web environment is provided.

The user session management method includes: calculating a first server authentication value using a random number previously generated by the server and a shared key stored in the server; Generating a new random number; Calculating a second server authentication value using the random number and the shared key stored in the server; Sending an HTTP response including the random number to the client; Receiving an HTTP request including a cookie from the client, wherein the cookie includes a client authentication value, wherein the client authentication value is a shared key stored in the client and the client received Calculated using a random number included in the HTTP response; And comparing the client authentication value with any one of the first server authentication value and the second server authentication value to determine success or failure of sender authentication of the client.

Here, the server may share the shared key with the client during a user login process from the client.

The determining may include determining that the sender authentication succeeds when the client authentication value and the first server authentication value are the same and the arrival time of the HTTP request is a predetermined time elapsed from the arrival time of the previous HTTP request. If the sender authentication is successful, the method may further include including a random number used to calculate the second server authentication value in an HTTP response and transmitting the same to the client.

Meanwhile, the determining may include determining that the sender authentication succeeds when the client authentication value and the second server authentication value are the same, but generating a new random number; Copying the second server authentication value to the first server authentication value; Updating the second server authentication value using the newly generated random number and the shared key stored in the server; And including the newly generated random number in an HTTP response and transmitting the same to the client.

The determining may include determining that the sender authentication has failed when the client authentication value is not the same as the first server authentication value and the second server authentication value. And transmitting an HTTP response to the client, the HTTP response including the random number and an execution code that causes the client to immediately request a new client authentication value calculated using the random number and the shared key stored in the client. have. The transmitting of the HTTP response including the random number and the execution code may be repeated for a predetermined number of times. After repeating the predetermined number of times, the transmitting of the HTTP response including the random number and the execution code may be repeated for a predetermined time. The method may further include deleting the user session after the predetermined time elapses.

The first server authentication value and the second server authentication value may be calculated as a one-way function that takes a server secret key and the random number generated using a shared key and a key modification factor stored in the server. The transmitting of the HTTP response to the client may further include the key modification factor in the HTTP response. The client authentication value may be calculated as a one-way function that takes a client secret key generated using the shared key stored in the client and the key modification factor and the random number as arguments.

Meanwhile, the above-described user session management method may be performed by a computer, and may be recorded on a computer-readable recording medium for recording a program to be executed on the computer, and then performed by a server.

According to another aspect of the present invention, a method for managing a user session in a client connected to a server via a network in a web environment is provided.

A user session management method includes: sharing a shared key with the server by the client; The shared key may be assigned to a window name (window.name), a local shared object (LSO) or ActiveX of a window object of a document object model (DOM) of a web browser. Storing; Receiving an HTTP response from the server, wherein the HTTP response includes session information generated at the server; Calculating a client authentication value using the session information and the shared key; And storing the client authentication value in a cookie, wherein the session information is stored in a storage space storing the shared key.

The method may further include receiving a plurality of HTTP responses from the server. If the session information included in the plurality of HTTP responses is identical to the session information stored in the storage space, the cookie may be reused. The session information stored in the storage space may be updated, the client authentication value may be newly calculated using the updated session information, and the cookie may be newly generated.

And in case of a plurality of HTTP requests requiring sender authentication within a predetermined time, the HTTP requests are commonly transmitted to the server including a cookie including a client authentication value generated using session information stored in the storage space. It may include.

In addition, the client authentication value may be calculated as a one-way function using the session information and the shared key.

The session information may be a random number.

Meanwhile, the session information may include a random number and a key modification factor. The client authentication value may be calculated as a one-way function that takes a client secret key calculated using the shared key and the key modification factor stored in the client, and the random number included in the HTTP response.

Meanwhile, the above-described user session management method may be performed by a computer, and may be recorded on a computer-readable recording medium for recording a program to be executed on the computer and executed by the client.

Other aspects, features, and advantages other than those described above will become apparent from the following drawings, claims, and detailed description of the invention.

The method of managing a user session according to the present invention and a recording medium on which a program for performing the same are recorded can protect a user's session by applying an authentication algorithm of an attempt-response method to the HTTP protocol.

In addition, by using a storage space other than the cookie to store the shared key in the web browser it is possible to overcome the disadvantage of the conventional cookie that is automatically transmitted in the form of plain text.

In addition, a channel between a user logged in to a web service and a server in HTTP can be secured from an attack such as sniffing, injection, and forgery using a challenge-response authentication algorithm.

In addition, users' sessions can be protected without distributing new programs such as ActiveX to the client, and the client's web browser does not have to maintain communication with the server. In addition, the session can be securely shared with various web services provided by the server using the authenticated cookie.

In addition, when the challenge-response method is applied to the HTTP protocol, errors can be reduced by adding a revalidation routine of the shared key when the random number shared by the user's behavior pattern or the network situation is not synchronized.

In addition, it is possible to flexibly respond to multiple HTTP requests by setting a threshold time.

As the invention allows for various changes and numerous embodiments, particular embodiments will be illustrated in the drawings and described in detail in the written description. However, this is not intended to limit the present invention to specific embodiments, it should be understood to include all transformations, equivalents, and substitutes included in the spirit and scope of the present invention. In the following description of the present invention, if it is determined that the detailed description of the related known technology may obscure the gist of the present invention, the detailed description thereof will be omitted.

Terms such as first and second may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting of the present invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this application, the terms "comprise" or "have" are intended to indicate that there is a feature, number, step, operation, component, part, or combination thereof described in the specification, and one or more other features. It is to be understood that the present invention does not exclude the possibility of the presence or the addition of numbers, steps, operations, components, components, or a combination thereof.

1 is a view for explaining the authentication method of the challenge-response protocol applied to the present invention. Hereinafter, the secret key is a key required for the client 1 to calculate the client authentication value and the server 2 to calculate the server authentication value, and the shared key is used by the client 1 and the server 2 during the initial user login process. Means a shared key.

The client 1 and the server 2 share K, which is a secret key between the client 1 and the server 2 (step S10). Here, the secret key K corresponds to the shared key. The shared key K can be shared during the user login process to the server 2 via the client 1 using a secure key exchange protocol (e.g., Password Authenticated Key Exchange (PAKE), etc.).

The server 2 generates a random number R1 (step S11) and stores the random number R1 using a session or the like. The generated random number R1 is transmitted to the client 1 (step S12). The process of transmitting the random number R1 to the client 1 corresponds to a challenge process.

The client 1 calculates the client authentication value C using the random number R1 received from the server 2 and the shared key K previously stored by the client 1 (step S13). The function of calculating the client authentication value C using the random number R1 and the shared key K is a one-way function. One-way functions are simple to get the result (function value) from the argument, but it is difficult to get the argument from the result. Such one-way functions include hash functions, pseudorandom functions, and the like.

The client 1 transmits the generated client authentication value C to the server 2 (step S14). The process of transmitting the client authentication value C to the server 2 corresponds to the response process.

The server 2 generates the server authentication value S using the random number R1 and the shared key K previously stored by the server 2 at any point in the process up to step S16, which will be described later, after generating the random number R1 in step S11. Calculate (step S15). The function of calculating the server authentication value S using the random number R1 and the shared key K is a one-way function, preferably the same as the one-way function used by the client 1.

The server 2 compares the client authentication value C received from the client 1 with the server authentication value S generated in the server 2 (step S16).

As a result of the comparison, when the client authentication value C and the server authentication value S are different, it is determined that the shared key K possessed by the client 1 is different from the shared key K possessed by the server 2. (Step S17a), the user session is not valid and the user session is deleted.

As a result of the comparison, if the client authentication value C and the server authentication value S are the same, it is determined that the shared key K of the client 1 is the same as the shared key K of the server 2 and the authentication of the client 1 is successful. (Step S17b), the user session is maintained valid. Then, a new random number R2 is generated (step S18). Then, the trial-response process described in the above steps S12 to S16 is repeated using the new random number R2.

When the server 2 transmits a new random number R2 from the server 2 to the client 1 (step S19), the random number R1 previously transmitted from the client 1 to the client 1 before the new random number R2 reaches the client 1. The corresponding client authentication value C can be sent back to the server 2 (step S14a).

In this case, the server 2 generates a new random number R2. The server authentication value is a function value corresponding to the new random number R2, and the client authentication value is a function value corresponding to the existing random number R1. Random numbers shared by 2) may not be synchronized.

In the present invention, when the above-described challenge-response protocol is applied to the HTTP protocol, random numbers shared by the client 1 and the server 2 may not be synchronized as described above according to the behavior pattern of the user or the situation of the network. You need to prepare for this. Here, the behavior pattern of the user may be using a plurality of web browsers or simultaneous service requests. The network condition refers to a case where a packet is delayed or lost.

Depending on the user's behavior patterns or network conditions, the HTTP request or HTTP response may be delayed or lost. If the HTTP response is delayed or lost, the server 2 updates the random number to make the HTTP response, but the client 1 does not receive it or the HTTP request corresponding to the unrenewed random number is sent while the reception is late. The random number shared between the server 2 and the client 1 is not synchronized.

Since the purpose of the above-described challenge-response method is to verify the shared key, when verification fails because of the random number being out of sync, client side script, flash, or ActiveX. Only the concise executable code is sent to the client 1 to re-verify the shared key. The number of times to re-verify the shared key is limited. If the re-validation attempt exceeds a predetermined number, the user session is deleted and logged out. Here, the revalidation routine uses the cache of the client 1 to reduce the burden on revalidation.

In addition, in a web environment, HTTP requests may occur concurrently. An example is the inclusion of another document in a document. In this case, the order of the HTTP request and the HTTP response can be mixed. Therefore, from the second HTTP request that arrives within a certain time, the client authentication value used in the first HTTP request can be used as it is, and the client authentication value can be extended for a valid time to flexibly respond to a large number of HTTP requests in a short time. Allow the response.

Hereinafter, a method of managing a secure user session in a web environment to which the above description is applied will be provided.

2 is a block diagram of a session management module included in a server according to an embodiment of the present invention.

2, the session management module 20, the random number generator 21, the authentication value calculator 22, the authentication value comparison unit 23, the authentication manager 24, the time analyzer 25, and an error. Acceptance analysis section 26 is shown.

The session management module 20 is included in the server 2 that provides a web service. The session management module 20 manages sessions for sender authentication for HTTP requests from client 1.

The random number generator 21 generates a random number for sharing with the client 1.

The authentication value calculation unit 22 calculates a server authentication value which is a result obtained by calculating a predetermined function using the generated random number and a pre-stored shared key as an argument. In the present invention, a first server authentication value and a second server authentication value corresponding to two random numbers generated at time intervals are calculated. The first server authentication value is a result value corresponding to the random number generated first, and the second server authentication value is a result value corresponding to the newly generated random number.

The authentication value comparison unit 23 is configured to calculate the first server authentication value or the second server authentication value calculated by the authentication value calculator 22 and the client authentication value (random number and shared key from the client 1). And the result calculated by a predetermined function whose arguments are the same).

The authentication manager 24 determines the sender authentication success or the authentication failure of the client 1 that made the HTTP request according to the comparison result. If authentication fails, it is determined as an HTTP request (for example, an HTTP request of an attacker) from the inappropriate client 1, and the session is deleted. If authentication succeeds, it is determined as an HTTP request from the appropriate client 1 and the session is maintained.

The time analyzer 25 determines that an HTTP request continuously arriving from the client 1 within a predetermined time (for example, a threshold time) has the same client authentication value, and the client authentication value is the same as the first server authentication value. It is judged as a simultaneous service request and provides HTTP response without updating random number.

If the client authentication value is the same as the second server authentication value, it is determined that the HTTP request to which the random number generated first is applied is terminated and the HTTP request to which the newly generated random number is applied is received. In this case, the second server authentication value is copied to the first server authentication value. A new random number is generated, a new second server authentication value is calculated, and the newly generated random number is included in an HTTP response transmitted to the client 1.

If the HTTP request does not arrive continuously from the client 1 within a predetermined time, and the client authentication value is different from the second server authentication value, the HTTP request is usually an HTTP request by an attacker. However, as described above, even if the client 1 has the same shared key as the server 2 according to a user's behavior pattern or network situation, an error may occur due to asynchronous synchronization of random numbers.

In order to allow such an error, the error tolerance analyzing unit 26 uses a shared key revalidation routine. An HTTP response is sent to the client 1 for sending a random number to the client 1 for a predetermined number of times and / or for a predetermined time and for immediately sending a client authentication value calculated according to this random number as an HTTP request. The client authentication value included in the immediately transmitted HTTP request is compared with the first server authentication value or the second server authentication value to re-verify whether the client 1 has a shared key.

Referring to FIGS. 3 and 4, a method of stably managing a user session when the client 1 and the server 2 share a shared key will be described. After that, the time according to the present invention will be described with reference to FIGS. This article describes how to manage a flexible and error-tolerant user session.

3 is a diagram illustrating a secure user session management method and a sender authentication protocol of an HTTP request.

The secret key K between the client 1 and the server 2 is shared between the client 1 and the server 2 (step S30). That is, the secret key K corresponds to the shared key. The shared key K can be shared during the user login process of the web service via the client 1 to the server 2 using a secure key exchange protocol (e.g., PAKE, etc.).

The shared key K must be stored in the web browser until it is exchanged and logged out at the login stage of the client 1. And even if the web page changes, it must be maintained.

In this case, when the shared key is stored in a cookie, the cookie is included in the HTTP request from the client 1 and transmitted to the network, thereby exposing the shared key as it is.

Therefore, the client 1 stores the shared key K in a separate storage space rather than a cookie. Among the properties of the window object of the document object model (DOM) of the web browser, the storage space of the window name (window.name), local shared object (LSO) of Flash, ActiveX, etc. Can be used. This storage space will be described later in detail.

When an HTTP request is transmitted from the client 1 (step S31), the server 2 operates as follows.

The server 2 generates a random number R (step S32). Pseudo code associated with this is as follows.

R = random ()

The server 2 calculates a server authentication value S which is a result calculated by a predetermined function using the random number R and the shared key K (step S37). Here, ID, which is user identification information, may be further included as an argument of a predetermined function. The pseudo code related to this is as follows.

S = Func (K, R, ID,…)

Here, the predetermined function is preferably a one-way function. One-way functions are simple to get the result (function value) from the argument, but it is difficult to get the argument from the result. Such one-way functions include hash functions, pseudorandom functions, and the like.

The server 2 stores the shared key K, the random number R, and the server authentication value S in a session or database provided by the web application. The pseudo code related to this is as follows.

Session = {K, R, S}

It is sufficient that step S37 described above is performed at the server 2 at any point in time after step S32 and before step S38 described later.

The server 2 transmits the random number R generated in step S32 to the client 1 via an HTTP response (step S33). The random number R corresponds to session information. Here, the session information refers to information that the server 2 provides to the client 1 for user session authentication.

The client 1 calculates the client authentication value C, which is a result of the calculation using a predetermined function, using the received random number R and the shared key K stored in the predetermined storage space (step S34). Here, ID, which is user identification information, may be further included as an argument of a predetermined function. Here, the predetermined function must be the same as the one-way function used by the server 2 in step S37.

The client 1 then stores the calculated client authentication value C in a cookie (step S35). The pseudo code related to this is as follows.

setCookie (C = Func (K, R, ID,…))

When the client 1 makes an HTTP request, the cookie that stores the client authentication value C is automatically included and sent to the server 2 (step S36).

The server 2 compares the client authentication value C included in the cookie with the server authentication value S calculated in step S37 (step S38). The comparison proceeds to step S39 if the two authentication values are different, and if so, to step S40.

In step S39, since the two authentication values are different, the server 2 regards the sender authentication of the client 1 as failed and deletes the server-side session maintenance information (random number R, shared key K, etc.) stored in the server 2, and Delete the session. The pseudo code related to this is as follows.

Session destroy ()

Then, the client-side script, flash, or ActiveX is transmitted to the client 1 so that all client-side session maintenance information (shared key K, random number R, cookies, etc.) stored in the client 1 are set to NULL. In this process, the user is logged out.

In step S40, since the two authentication values are the same, the server 2 considers the sender authentication of the client 1 to be successful, and generates a new random number R (step S41). Then, the client 1 attaches the newly generated random number R to the HTTP response to the service requested through the HTTP request and transmits it to the client 1 (step S42). Thereafter, when the server 2 receives another HTTP request, the server 2 repeats the process of step S38 or less.

The client 1 stores the shared key K exchanged in step S30 in a separate storage space rather than a cookie. Among the properties of the window object of the document object model (DOM) of the web browser, the storage space of the window name (window.name), local shared object (LSO) of Flash, ActiveX, etc. Can be used.

In one embodiment, the storage space in the client 1 may be a window name (window.name) among the properties of the window object of the document object model (DOM) of the web browser. Here, the document object model refers to an object-based document model for interworking an extensible generation language (XML) document through a web browser. It is a platform- and language-neutral interface that allows programs and scripts to dynamically access and change the content, structure, and type of documents, and links web pages to scripts or programming languages. The properties, methods, and events used to manipulate and create web pages make up objects, which can be accessed through scripting languages in most web browsers.

The original purpose of the window name (window.name) was to give each browser (or tab) a name and make it accessible between browsers. Since the name of the browser does not change even if the page in the browser is changed, it is recently used to transfer data between pages. The name of the window is not fixed, and the advantage is that you can store the data you want without limiting its size.

In another embodiment, the storage space at the client 1 may be a Local Shared Object (LSO) in Flash. Local shared objects are cookie-like data entities used in Flash Player. Applications running on Flash Player can store and retrieve data consisting of basic data types, such as strings or numbers, or of more complex objects. Flash's local shared objects are available if you have a flash plug-in installed. Unlike the embodiment in which the variable name is designated as the window name (window.name), the security name can be alleviated to some extent because the variable name can be set as desired and data can be managed for each domain such as a cookie. The default size of a local shared object is 100 kB.

In another embodiment, the client 1 may store the shared key K using ActiveX. ActiveX is a plug-in that can be used in Explorer, which has the advantage of installing a compiled program on the user's computer to make more use of the client's resources. With ActiveX, you can save and read data in the location set by the author. ActiveX-related technologies can serve as storage spaces, such as ActiveX documents and ActiveX scripting. ActiveX documents are written without regard to HTML, meaning MS Word or Excel files. Active scripting is a scripting language that can be included in ActiveX controls or Java applets, such as JScript or VBScript.

In the case where the shared key, which is a secret key, is stored in such a storage space, it may be difficult to secure session management when the secret key is exposed to the outside. For example, the window name has the advantage of being able to store the desired data without any size limit because the window name is not fixed, but the value does not change even when moving to another service. Can be. The solution to this security problem is to store the modified or encrypted version of the private key without storing it, so that the private key is not directly exposed even if the value stored in the window name is exposed.

In the above description with reference to FIG. 3, the case where the secret key and the shared key are the same will be described below in detail with reference to FIG. 4.

4 is a diagram illustrating another secure user session management method and a sender authentication protocol of an HTTP request in key protection mode.

That is, the key protection mode means that the secret key is not exposed even if the shared key is exposed, so that the sender authentication of the HTTP request is possible. Unlike the description with reference to FIG. 3, the shared key has a different value.

The client 1 and the server 2 share K, which is a shared key between the client 1 and the server 2 (step S50). The shared key K can be shared during the user login process of the web service via the client 1 to the server 2 using a secure key exchange protocol (e.g., PAKE, etc.).

The shared key K must be stored in the web browser until it is exchanged and logged out at the login stage of the client 1. And even if the web page changes, it must be maintained.

In this case, when the shared key is stored in a cookie, the cookie is included in the HTTP request from the client 1 and transmitted to the network, thereby exposing the shared key as it is.

Therefore, the client 1 stores the shared key K in a separate storage space rather than a cookie. Among the properties of the window object of the document object model (DOM) of the web browser, a storage space such as a window name (window.name), a local shared object (LSO) of Flash, ActiveX, or the like may be used. As described above, the detailed description will be omitted.

Here, the shared key K has the characteristics as shown in Equation 1 below to apply to the key protection mode.

K = ① Func1 (K1, K2) or ② K1

Func2 (K, K2) = K '

K '= ① K1 or ② K3

Here, K is a shared key, K 'is a secret key, Func1 is a key modification function that modifies a key using the key modification factor K2 so that the secret key is not directly exposed through a value stored in the client 1, and Func2 is shared. Secret key generation function that generates secret key K2 from key K using key transformation argument K2.

The client 1 stores only the shared key K, and the server 2 stores the shared key K and the key modification factor K2. In this case, even if the shared key K and / or key modification factor K2 stored in the client 1 is exposed to the outside, the client secret key K 'is generated using the shared key K and the key modification factor K2, so that the secret key can be protected. Done.

According to the first embodiment (1), K1 is a secret key.

The client 1 and the server 2 share the modified shared key K using the key modification function Func1 and the key modification factor K2 so that the secret key K1 is not exposed. Here, the secret key generation function Func2 is a function for recovering the secret key K1 from the modified key K through the key transformation function Func1.

Accordingly, the client 1 calculates the client secret key K ', ie, K1, which is the result of calculating the shared key K and the key modification factor K2 by the secret key generation function Func2, and generates the client side session maintenance information for sender authentication. We use for. The server 2 calculates the server secret key K ', ie, K1, which is the result of calculating the shared key K and the key modification factor K2 by the secret key generation function Func2, and generates the server side session maintenance information for the sender authentication. I use it.

According to the second embodiment (2), K1 is the shared key.

When the shared key K is K1, the secret key generation function Func2 generates a new result, K3, as a secret key using K1 and the key modification factor K2 as arguments. Accordingly, the client 1 calculates the client secret key K ', that is, K3, which is the result of calculating the shared key K1 and the key modification factor K2 by the secret key generation function Func2, and generates the client side session maintenance information for sender authentication. We use for. The server 2 calculates the server secret key K ', that is, K3, which is the result of calculating the shared key K1 and the key modification factor K2 by the secret key generation function Func2, and generates the server side session maintenance information for sender authentication. I use it.

In step S50, it is assumed that the server 2 and the client 1 share the shared key K through a secure key exchange protocol, and the sender authentication method will be described below.

The server 2 receives the HTTP request (step S51) from the client 1, and the server 2 generates a random number R (step S52). The pseudo code related to this is as follows.

R = random ()

The server 2 calculates the server authentication value S, which is a result calculated by the predetermined function using the random number R and the server secret key K '(step S58). Here, the server secret key K 'is a result of the server 2 previously calculating the secret key generation function Func2 using the shared key K and the key modification factor K2 as arguments.

Here, ID, which is user identification information, may be further included as an argument of a predetermined function. The pseudo code related to this is as follows.

S = Func (K ', R, ID,…)

Here, the predetermined function is preferably a one-way function. Such one-way functions include hash functions and pseudorandom functions.

The server 2 stores the shared key K, the key modification factor K2, the random number R, and the server authentication value S in a session or database provided by the web application. The pseudo code related to this is as follows.

Session = {K, K2, R, S}

It is sufficient that step S58 described above is performed at the server 2 at any point in time after step S52 and before step S59 described later.

The server 2 transmits the random number R and the key modification factor K2 generated in step S52 to the client 1 through the HTTP response (step S53). The random number R and the key modification factor K2 correspond to session information. Here, the session information refers to information that the server 2 provides to the client 1 for user session authentication.

In this case, in the HTTP response, the client 1 calculates the client secret key K 'using the shared key K and the key modification factor K2, and calculates the client authentication value C, which is client-side session maintenance information, using the client secret key K'. In addition, execution code (for example, JavaScript) may be further included to store the calculated client authentication value C in a cookie.

The client 1 calculates the client secret key K 'calculated by the secret key generation function Func2 using the received key modification factor K2 and the shared key K stored in the predetermined storage space (step S54).

After that, the client 1 calculates a result calculated by a predetermined function using the received random number R and the client secret key K 'calculated in step S54, that is, the client authentication value C which is client-side session maintenance information (step S54). S55). Here, ID, which is user identification information, may be further included as an argument of a predetermined function. Here, the predetermined function must be the same as the one-way function used by the server 2 in step S58.

The client 1 then stores the calculated client authentication value C in a cookie (step S56). The pseudo code related to this is as follows.

setCookie (C = Func (K ', R, ID,…))

Here, immediately after storing the client authentication value C in the cookie, all but the shared key K is deleted to prevent exposure to the outside.

When the client 1 makes an HTTP request requiring authentication, new client side session maintenance information is included and transmitted to the server 2. That is, the cookie storing the client authentication value C is automatically included and transmitted to the server 2 (step S57).

The server 2 compares the client authentication value C included in the cookie with the server authentication value S calculated in step S58 (step S59). The comparison proceeds to step S60 if the two authentication values are different, and if so, to step S61.

In step S60, if the two authentication values are different, the server secret key and the client secret key are different, the server 2 considers the sender authentication of the client 1 to have failed and server-side session maintenance information (random number R, shared). Key K, key modification factor K2, etc.) and delete the session. The pseudo code related to this is as follows.

Session destroy ()

Then, the client-side script, flash, or ActiveX is transmitted to the client 1 so that all client-side session maintenance information (shared key K, key modification factor K2, random number R, cookie, etc.) stored in the client 1 is set to NULL. do. In this process, the user is logged out.

In step S61, if the two authentication values are the same, the server secret key and the client secret key are the same, the server 2 considers the sender authentication of the client 1 to be successful, and generates a new random number R (step S62). ). Then, the client 1 attaches the newly generated random number R and the key modification factor K2 to the HTTP response to the service requested by the HTTP request to the client 1 (step S63). Thereafter, when the server 2 receives another HTTP request, the server 2 repeats the process of step S59 or below.

Using the above-described user session management method, the user's session itself can be protected, but the contents of HTTP which are still transmitted and received can be intercepted. In order to protect the contents transmitted and received from eavesdropping, important contents of HTTP contents (for example, account number in Internet banking service) are encrypted and transmitted using a secret key shared by the client 1 and the server 2. . Here, the encryption uses an encryption routine of the advanced encryption standard (AES).

When the server 2 makes an HTTP response, it encrypts the important content using the secret key, and transmits a client-side script, flash, or ActiveX together with the client 1 to enable the client 1 to decrypt it.

When the client 1 makes an HTTP request, the server 2 transmits the encryption routine included in the HTTP response so that the important content can be encrypted with the secret key. In this case, when the client 1 generates an HTTP request, important contents of the HTTP contents can be encrypted using a secret key according to an encryption routine.

Since the client 1 and the server 2 share a secret key or a shared key for generating a secret key, those skilled in the art will understand that it is not difficult to decrypt the encrypted contents.

The encryption of some of these HTTP contents is different from that of the conventional secure sockets layer (SSL) as follows. In case of using SSL, SSL is a transport layer, and the entire HTTP content is encrypted and session management between domains is not possible. However, as described above, the encryption using the secret key shared by the client 1 and the server 2 is performed in the application layer, and it is possible to selectively encrypt only some of the HTTP contents and manage sessions between domains. There is a possible advantage.

In the present invention, when using a window name as a storage space for the shared key, when using a child window, the shared key stored in the parent window is shared in the child window through a method such as window.name = opener.name. . Where opener.name is the window name of the parent window.

Even in the above-described secure user session management method, due to the asynchronousization of session information (random number in FIG. 3, random number and key transformation factor in FIG. 4) according to a user's behavior pattern or network situation, the server 2 may execute the client 1. ), It is difficult to verify whether the shared key is saved.

FIG. 5A is a diagram illustrating a secure user session management method according to an embodiment of the present invention, and FIG. 5B is pseudo code executed in the server of FIG. 5A.

The client 1 and the server 2 share the shared key K using a secure key exchange protocol (for example, PAKE, etc.) (step S70). This is applied during the user login process of the web service.

Here, the client 1 stores the shared key K in a predetermined storage space (WLA: window.name, local shared object (LSO) of Flash, ActiveX, etc.).

In addition to the shared key K, the server 2 includes constants of a maximum threshold time MAXt, a maximum threshold counter MAXc, a maximum verification threshold time MAXv, a counter, a timestamp (TS), Stores the variables of the verification timestamp (TV).

The initial value of each variable is as follows.

counter = 0, TS = ctime (), TV = 0

Here, ctime () is a function representing the current time.

Here, the first server authentication value S1 is initialized to an arbitrary value. When the second server authentication value S2 is updated, the second server authentication value S2 is copied to the first server authentication value S1.

Upon receiving the HTTP request from the client 1 (step S71), the server 2 generates a random number R and uses the generated random number R and the shared key K stored in the server 2 to generate a second function with a predetermined function. Compute the server authentication value S2. Preferably, the predetermined function is a one-way function. The user identification information ID may be further included as an argument of a predetermined function.

The server 2 transmits an HTTP response including the random number R generated in step S71 to the client 1 (step S72).

The server 2 stores a random number R corresponding to the first server authentication value S1, the second server authentication value S2, and the second server authentication value S2 in a session or database provided by the web application.

The client 1 receives the HTTP response sent in step S72. The client 1 uses the random number R included in the received HTTP response and the shared key K stored in the client 1 only if the random number R included in the received HTTP response is different from the random number already stored in the predetermined storage space. The client authentication value C is calculated using a predetermined function. The predetermined function is preferably the same as the one-way function used in the server 2. The user identification information ID may be further included as an argument of a predetermined function. The random number R included in the HTTP response is overwritten in a predetermined storage space.

The client authentication value C is stored in a cookie. The cookie is automatically included in the header of the HTTP request of the client 1 and transmitted to the server 2 (step S73).

The server 2 is a pseudo-code which is a time flexible routine if the client authentication value C contained in the cookie is equal to the first server authentication value S1 possessed by the server 2 and ctime ()-TS is within the maximum threshold time MAXt. Perform module T1. Here, the maximum threshold time MAXt is a time for grouping successive HTTP responses into one concurrent HTTP response group.

In the time smoothing routine T1, the current time ctime () is stored in the time stamp TS. This is then a criterion for determining whether successive HTTP responses arrive within the maximum threshold time. The counter is initialized to zero. The counter will be described in the revalidation routine T3. Then, the client 1 transmits the random number R stored in the server 2 in the HTTP response (step S76).

It is assumed that HTTP request # 1 (S73), HTTP request # 2 (S74), HTTP request # 3 (S75), and HTTP request # 4 (S77) are one simultaneous HTTP response group.

In this case, the server 2 simultaneously bundles the HTTP request # 2 arriving from the HR1, which is the point at which the HTTP request # 1 arrives at the server 2, to the HR1 'which is within the maximum threshold time MAXt, by the time flexible routine T1. One HTTP response group.

In addition, the server 2 simultaneously generates an HTTP request # 3 arriving at the HR2 'within the maximum threshold time MAXt from HR2, which is the point at which the HTTP request # 2 arrives at the server 2, by the time-flexible routine T1. Determined as one HTTP response group.

However, the server 2 does not arrive from HR3 when the HTTP request # 3 arrives at the server 2 to HR3 'within the maximum threshold time MAXt. The HTTP request # 4 is a group of simultaneous HTTP responses. I can't judge. HTTP request # 4 is revalidated later through the revalidation routine (T3).

If the client authentication value C included in the cookie is the same as the second server authentication value S2 owned by the server 2, the server 2 performs a pseudo code module T2 which is an update routine. Since the random number corresponding to the second server authentication value S2 has been stored in the client 1, the server 2 generates a new random number. Then, the second server authentication value S2 is copied to the first server authentication value S1. The second server authentication value S2 stores a function value calculated by a predetermined function using the new random number and the shared key K. The timestamp stores the current time and the counter resets to zero. Then, the server 1 transmits the newly generated random number R included in the HTTP response to the client 1.

If all of the above conditions are not satisfied, the server 2 performs the pseudo code module T3 which is a revalidation routine. The revalidation routine T3 includes an iteration routine F1, a time routine F2, and a deletion routine F3.

In the iterative routine F1, the server 2 increases the counter by one, using the random number R stored in the server 2, and the client 1 using the random number R and the shared key K stored in the client 1; An HTTP response including the execution code (for example, client-side script, flash, ActiveX, etc.) for immediately HTTP requesting the calculated new client authentication value C is transmitted to the client 1 (step S78). This HTTP response is defined as a CFA response. The verification timestamp (TV) stores the current time.

The client 1 transmits the new client authentication value C calculated using the random number R received in step S78 according to the received CFA response to the server 2 by storing it in a cookie or attaching it in a get or post format to an HTTP request. (Step S79).

The repetition routine F1 repeats a predetermined number of times until the sender authentication. Here, the predetermined number is a value stored in the maximum threshold counter MAXc.

Even if the predetermined number is exceeded, the server 2 executes the time routine F2, so that if the ctime ()-verification timestamp TV is within the maximum verification threshold time MAXv, the server 2 stores the random number R stored in the server 2; Execution code (eg, client-side script, Flash, ActiveX, etc.) that causes the client 1 to immediately request an HTTP request for a new client authentication value C calculated using the random number R and the shared key K stored in the client 1. Send an HTTP response to the client (1).

If the sender authentication fails even by the repetition routine F1 and the time routine F2, the sender authentication is finally considered to have failed and the user session is deleted (delete routine F3). The user is logged out.

When the user logs out or logs out, the server 2 maintains user session maintenance information (shared key K, various constants (MAXt, MAXc, MAXv), various variables (counter, TS, TV), random number R, server authentication. Delete the values (S1, S2). Then, the client side script, flash, or ActiveX is transmitted to the client 1 to set the shared key K, the random number R, the cookie, and the like stored in the predetermined storage space of the client 2 all to NULL.

FIG. 6A is a diagram for describing a secure user session management method according to another embodiment of the present invention, and FIG. 6B is pseudo code executed in the server of FIG. 6A.

5A and 5B show the use of the shared key K in generating the client authentication value and the server authentication value, whereas the other embodiment shown in FIGS. 6A and 6B uses the shared key K and the key modification factor K2. There is a difference in generating a secret key K 'by using the secret key K' and generating a client authentication value and a server authentication value by using the secret key K '. Using the key modification factor has been described in detail with reference to FIG. 4, and thus the detailed description thereof will be omitted.

On the other hand, the user session management method described above can be created by a computer program. Codes and code segments constituting the program can be easily inferred by a computer programmer in the art. In addition, the program is stored in a computer readable media, and read and executed by a computer to implement a method for providing a document search service. The information storage medium includes a magnetic recording medium, an optical recording medium, and a carrier wave medium.

In the above, the present invention has been described based on the embodiments, but those skilled in the art may vary the present invention without departing from the spirit and scope of the present invention as set forth in the claims below. It will be understood that modifications and changes can be made.

1 illustrates an authentication method of a challenge-response protocol applied to the present invention.

2 is a block diagram of a session management module included in a server according to an embodiment of the present invention.

3 illustrates a method for secure user session management and a sender authentication protocol for HTTP requests.

4 illustrates another secure user session management method, a sender authentication protocol of an HTTP request in key protected mode.

5A is a diagram for explaining a secure user session management method according to one embodiment of the present invention;

FIG. 5B is pseudo code executed on the server of FIG. 5A. FIG.

6A is a diagram illustrating a secure user session management method according to another embodiment of the present invention.

FIG. 6B is pseudo code executed on the server of FIG. 6A. FIG.

<Description of the symbols for the main parts of the drawings>

1: client

2: server

Claims (22)

A method of managing a user session with a client in a server connected to a client through a network in a web environment, the method comprising: calculating a first server authentication value using a random number previously generated by the server and a shared key stored in the server step; Generating a new random number; Calculating a second server authentication value using the random number and the shared key stored in the server; Sending an HTTP response including the random number to the client; Receiving an HTTP request including a cookie from the client, wherein the cookie includes a client authentication value, wherein the client authentication value is a shared key stored in the client and the client received Calculated using a random number included in the HTTP response; And Comparing the client authentication value with any one of the first server authentication value and the second server authentication value to determine success or failure of sender authentication of the client. The method of claim 1, And the server shares the shared key with the client during a user login process from the client. The method of claim 1, The determining step, And determining that the sender authentication succeeds when the client authentication value and the first server authentication value are the same and the arrival time of the HTTP request is a predetermined time elapsed from the arrival time of the previous HTTP request. . The method of claim 3, And if the sender authentication succeeds, including the random number used to calculate the second server authentication value in an HTTP response and transmitting the same to the client. The method of claim 1, The determining step, If the client authentication value and the second server authentication value is the same, it is determined that the sender authentication is successful, Generating a new random number; Copying the second server authentication value to the first server authentication value; Updating the second server authentication value using the newly generated random number and the shared key stored in the server; And And including the newly generated random number in an HTTP response and transmitting it to the client. The method of claim 1, The determining step, And if the client authentication value is not the same as the first server authentication value and the second server authentication value, determine that the sender authentication has failed. The method of claim 6, And transmitting the HTTP response to the client, the HTTP response including the random number and execution code for allowing the client to immediately request a new client authentication value calculated using the random number and the shared key stored in the client. Session management method. The method of claim 7, wherein And transmitting the HTTP response including the random number and the execution code repeats for a predetermined number of times. The method of claim 8, And transmitting the HTTP response including the random number and the execution code for a predetermined time after repeating the predetermined number of times. The method of claim 9, And deleting the user session after the predetermined time has elapsed. The method of claim 1, Wherein the first server authentication value and the second server authentication value are calculated as a one-way function using the server secret key and the random number generated using the shared key and the key modification factor stored in the server. How to manage. The method of claim 11, And transmitting the HTTP response to the client further includes the key modification factor in the HTTP response. The method of claim 12, And the client authentication value is calculated using a shared secret stored in the client, a client secret key generated by using the key modification factor, and a one-way function having the random number as an argument. In a web environment, a method for managing a user session from a client connected to a server via a network, Sharing, by the client, a shared key with the server; The shared key may be assigned to a window name (window.name), a local shared object (LSO) or ActiveX of a window object of a document object model (DOM) of a web browser. Storing; Receiving an HTTP response from the server, wherein the HTTP response includes session information generated at the server; Calculating a client authentication value using the session information and the shared key; And Storing the client authentication value in a cookie; And the session information is stored in a storage space storing the shared key. The method of claim 14, Further comprising the step of receiving a plurality of HTTP responses from the server, If the session information included in the plurality of HTTP responses and the session information stored in the storage space are the same, the cookie already generated is reused. And in other cases, update session information stored in the storage space, newly calculate the client authentication value using the updated session information, and generate the cookie. The method of claim 14, In the case of a plurality of HTTP requests requiring sender authentication within a predetermined time, each HTTP request further includes a step of transmitting to the server including a cookie including a client authentication value generated using the session information stored in the storage space in common. User session management method, characterized in that. The method of claim 14, The client authentication value is calculated using a one-way function using the session information and the shared key. The method of claim 14, And the session information is a random number. The method of claim 14, The session information includes a random number and a key modification factor. The method of claim 19, The client authentication value is calculated as a one-way function that takes a client secret key calculated using the shared key and the key modification factor stored in the client, and the random number included in the HTTP response. How to manage. A computer-readable recording medium for recording a program for executing the method of any one of claims 1 to 13 on a computer. A computer-readable recording medium for recording a program for executing the method of any one of claims 14 to 20 on a computer.

Images