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

Abstract

A method for safely managing a session of a user and a recording medium recording a program by using an authentication algorithm are provided to protect a user session by applying the authentication algorithm to an HTTP(HyperText Transfer Protocol) and use the other storage space for storing a secret key on a web browser. A random number generator(21) produces a client and a shared random number. An authenticator output unit(22) produces s server authenticator. The server authenticator is a result value stored with the generated random number. An authenticator comparison unit(23) is transmitted from a server authenticator and a client. An authentication management unit(24) determines whether to success of transmitter authentication of the client according to a comparison result. In case authentication succeeds in, it is determined as the HTTP request from the suitable client and session is maintained.

Description

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

The present invention relates to a method and system 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 and system capable of protecting a user's session by applying a challenge-response authentication algorithm to the HTTP protocol, and a recording medium having recorded thereon a program for performing the same.

In addition, the present invention is a method and system for managing a user session that overcomes the shortcomings of conventional cookies that are automatically transmitted in plain text by using a storage space other than a cookie for storing a secret key in a web browser, and a program for performing the same. Provide a record carrier.

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, the server receiving a first HTTP request (HTTP request) including a cookie from the client, wherein the cookie includes a client authentication value, the client authentication value is the Calculated using a shared key stored in a client and session information included in a first HTTP response received immediately before the client; Comparing the client authentication value and the server authentication value included in the cookie, wherein the server authentication value is calculated using the session information generated by the server and included in the first HTTP response and the shared key stored in the server; ; And determining success or failure of sender authentication of the client according to the comparison result.

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

Meanwhile, the first HTTP request may require sender authentication.

In the determining of whether the sender authentication succeeds or fails, if the server authentication value and the client authentication value are the same, the sender authentication is regarded as valid and the session information is updated, and the server authentication value corresponding to the updated session information is updated. May be calculated and include the updated session information in a second HTTP response to the first HTTP request and transmit it to the client. Here, when the user session is regarded as valid, the second HTTP response calculates the client authentication value using a one-way function by using the shared key stored by the client and the session information included in the second HTTP response. And executable code for including the client authentication value in the cookie. The server authentication value may be calculated using the same function as the one-way function for calculating the client authentication value.

Meanwhile, in the authentication success or failure determination step, when the server authentication value and the client authentication value are different, the server may consider the user session invalid and delete the user session. If the user session is considered invalid, the server may generate at least one of the client's shared key, the session information, the client authentication value, and the cookie to NULL. Flash) or ActiveX can be sent to the client.

The server may also share the shared key with the client; Receiving a second HTTP request from the client; Generating the session information; And including the session information in the first HTTP response to the second HTTP request and transmitting the session information to the client.

The server may store the shared key, the session information, and the server authentication value in a session or database provided by a web application.

The server may further include encrypting a part of the HTTP content by using the shared key in the first HTTP response, and transmitting the same to the client, including a client-side script, flash, or ActiveX, which can decrypt the content. Can be.

On the other hand, the server further comprises the step of transmitting to the client including a cryptographic routine that allows the client to encrypt some of the HTTP content in the first HTTP response, wherein the client is the shared according to the cryptographic routine The first HTTP request in which a portion of the HTTP content is encrypted may be transmitted to the server using a key.

The session information may be a random number.

Alternatively, the session information may include a random number and a key modification factor. The server authentication value may be calculated as a server secret key calculated using the shared key and the key modification factor stored in the server, and a one-way function having the random number as an argument. The client authentication value is included in the first HTTP response and the client secret key calculated using the shared key stored in the client and the key modification factor included in the first HTTP response received by the client from the server. It can be calculated as a one-way function taking the random number.

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 the steps of: 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.

The method may further include transmitting the cookie to the server in response to an HTTP request requiring sender authentication.

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

The HTTP response is sent to the client including a cryptographic routine that allows the client to encrypt some of the HTTP content, wherein the client encrypts a portion of the HTTP content using the shared key according to the cryptographic routine. The method may further include transmitting an HTTP request to the server.

The session information may be a random number.

Alternatively, 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.

According to another aspect of the present invention, in a system for managing a user session between a client and a server connected via a network in a web environment, the client and the server share a shared key, from the client while the user session is valid A user of an HTTP request corresponding to a challenge process among a challenge-response protocol, and an HTTP response from the server corresponds to a challenge process among the challenge-response protocols A session management system is provided.

Here, the server is server-side session maintenance information generated using the shared key, and the client-side session maintenance information generated by the client using the shared key, wherein the client-side session maintenance information is the HTTP request Included in-may be compared to determine whether the user session is valid.

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

A method and system for 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 a challenge-response authentication algorithm 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.

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 of the client 1 is different from the shared key K of the server 2, and thus the authentication of the client 1 fails. (Step S17), 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 S18), the user session is maintained valid. Then, a new random number R2 is generated (step S19). The authentication of the client 1 is repeated according to the challenge-response process described in the above-described steps S12 to S16.

The present invention provides a method and system for secure user session management in a web environment by applying the above-described challenge-response protocol to the HTTP protocol.

2 is a block diagram illustrating a session management module included in a server according to an embodiment of the present invention, and FIG. 3 is a diagram illustrating a secure user session management method and a sender authentication protocol of an HTTP request according to an embodiment of the present invention. to be.

2, a session management module 20, a random number generator 21, an authentication value calculator 22, an authentication value comparison unit 23, and an authentication manager 24 are illustrated.

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.

The authentication value comparison unit 23 takes a server authentication value calculated by the authentication value calculation unit 22 and a client authentication value transmitted from the client 1 (the predetermined function using the random number and the shared key in the client 1 as an argument). Compare the result calculated with).

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.

Hereinafter, the operation of the above-described session management module 20 and the flow of HTTP requests and HTTP responses in the user session management system according to the present invention including a client 1 and a server 2 connected to a network in a web environment. It will be described in detail with reference to 3. For convenience of understanding and explanation of the present invention, the session management module 20 will be referred to as a server 2.

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, cookie, etc.) stored in the client 1 is set to NULL. do. 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 a secure user session management method and a sender authentication protocol of an HTTP request in key protection mode according to another embodiment of the present invention.

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.

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 is a diagram illustrating a secure user session management method and a sender authentication protocol of an HTTP request according to an embodiment of the present invention.

4 is a diagram illustrating a secure user session management method and a sender authentication protocol of an HTTP request in key protected mode according to another embodiment of the present invention.

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

1: client

2: server

Claims (27)

In the web environment, a method for managing a user session with the client in a server connected to the client over a network, The server receiving a first HTTP request including a cookie from the client, wherein the cookie includes a client authentication value, the client authentication value being a shared key stored in the client; Calculated by using the session information included in the first HTTP response received by the client immediately before; Comparing a client authentication value and a server authentication value included in the cookie, wherein the server authentication value is calculated using the session information and a shared key stored in the server; And And determining success or failure of sender authentication of the client according to the comparison result. 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, And the first HTTP request requires sender authentication. The method of claim 1, The sender authentication success or failure determination step, If the server authentication value and the client authentication value are the same, the user session is regarded as valid and the session information is updated, a server authentication value corresponding to the updated session information is calculated, and 2. The method of claim 1, wherein the updated session information is included in an HTTP response and transmitted to the client. The method of claim 4, wherein If the user session is considered valid The second HTTP response calculates the client authentication value using a one-way function by using the shared key stored by the client and the session information included in the second HTTP response, and includes the client authentication value in the cookie. User session management method comprising the execution code to make. The method of claim 5, And the server authentication value is calculated using the same function as the one-way function that calculates the client authentication value. The method of claim 1, The authentication success or failure determination step, And if the server authentication value and the client authentication value are different, the server considers the user session invalid and deletes the user session. The method of claim 7, wherein If the user session is considered invalid The server may generate a client side script, flash, or ActiveX to make at least one of the shared key, the session information, the client authentication value, and the cookie of the client NULL. And transmitting to the user session management method. The method of claim 1, The server sharing the shared key with the client; Receiving a second HTTP request from the client; Generating the session information; And And transmitting the session information to the client by including the session information in the first HTTP response to the second HTTP request. The method of claim 1, And the server stores the shared key, the session information, and the server authentication value in a session or a database provided by a web application. The method of claim 1, The server further includes the step of encrypting a portion of the HTTP content in the first HTTP response using the shared key, and transmitting to the client, including a client-side script, Flash or ActiveX that can decrypt it Characterized by the user session management method. The method of claim 1, The server further includes the step of transmitting to the client, including a cryptographic routine that allows the client to encrypt some of the HTTP content in the first HTTP response, And the client transmits the first HTTP request in which a part of the HTTP content is encrypted using the shared key to the server according to the encryption routine. The method of claim 1, And the session information is a random number. The method of claim 1, And the session information includes a random number and a key transformation factor. The method of claim 14, And the server authentication value is calculated using a server secret key calculated using the shared key and the key modification factor stored in the server, and a one-way function taking the random number as an argument. The method of claim 15, The client authentication value is included in the first HTTP response and the client secret key calculated using the shared key stored in the client and the key modification factor included in the first HTTP response received by the client from the server. And calculating a one-way function using 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 And storing the client authentication value in a cookie. The method of claim 17, And transmitting the cookie to the server in response to an HTTP request requiring sender authentication. The method of claim 17, The client authentication value is calculated using a one-way function using the session information and the shared key. The method of claim 17, The HTTP response is sent to the client including a cryptographic routine that allows the client to encrypt some of the HTTP content. And transmitting, by the client, the HTTP request encrypted with a portion of the HTTP content to the server by using the shared key according to the encryption routine. The method of claim 17, And the session information is a random number. The method of claim 17, And the session information includes a random number and a key transformation factor. The method of claim 22, 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 16 on a computer. A computer-readable recording medium for recording a program for executing the method of any one of claims 17 to 23 on a computer. In a system for managing user sessions between a client and a server connected through a network in a web environment, The client and the server share a shared key, While the user session is valid, an HTTP request from the client corresponds to a response process of a challenge-response protocol, and an HTTP response from the server User session management system, characterized in that corresponding to the challenge (challenge) process of the response protocol. The method of claim 26, The server generates server-side session maintenance information generated by using the shared key and the client-side session maintenance information generated by the client by using the shared key, wherein the client-side session maintenance information is included in the HTTP request. And compare the-to determine whether the user session is valid.

Images