Abstract:
A user authentication method and system which maintains reliable security using a low cost storage medium in place of cryptocards, wherein the system comprises control equipment and an operating section connected to the control equipment, and wherein the method comprises the steps of the operating section reading a storage medium that stores specific parameters, creating a user authenticaly code using a specific function from the specific parameters and other parameters provided by the control equipment, and supplying the created user authentication code to the control equipment, wherein the user authentication code sent from the operating section is compared with another code computed using a specific function generated by the control equipment, and when both codes are found to coincide, the control equipment causes information to be interchanged between the control equipment and the operating section. Advantageously, the invention method provides reliable security combined with low cost.

Description:
BACKGROUND OF THE INVENTION 
     1. Field of Invention 
     This invention relates to a user authentication method and system; and more particularly, to user authentication in the “intranet” or “extranett”. The invention may be used in a system that utilizes a one time password function and a storage medium, such as a floppy disk, as a physical key for authentication. 
     The term “intranet” as used herein is a system analogous to the internet, for example, constructed in a company, and “extranet” is a membership system intranet. Also, the term “one time password” as used herein means a password that varies with each use. 
     2. Description of the Prior Art 
     The following types of authentication systems are currently available in the art: 
     (1) Access function limitation in a web server. One of the functions of conventional web servers is the function of access limitation. This function has been used in systems where a user name and a password are inputted, such as in personal computer communication. 
     (2) Function of access limitation using cryptocards. The cryptocard is a type of electronic or smart card. If a user name is inputted, the host sends back an ID code. The prescribed computation is executed based on this ID code, and the code obtained as a result of the computation is transmitted to the host; which uses the code as the user authentication code. 
     There are many disadvantages and deficiencies with these prior art systems. For example, in the case of system (1), since the user name and password are inputted, it is possible for the user name and password to be stolen when passed through a transmission line. When stolen, it is very difficult to locate the source of the theft or the location of the destination of such theft. Also, if non-specific users are managed with this system, the resource provider may allow many non-specific users to access the user name and password. As another example, in the case of system (2), reliable security can be maintained by a challenge and response function (that is the user authentication code creation and notification of that code to the host). However, disadvantageously, such a system is expensive and the cryptocard itself is expensive, and furthermore the system is not economically effective for systems that do not require high grade security. 
     SUMMARY OF THE INVENTION 
     Accordingly, an object of the invention is to overcome the aforementioned and other disadvantages, problems, and deficiencies of the prior art. 
     Another object is to provide a user authentication method and system that can provide reliable security at low cost. 
     A further object is to provide such as system wherein a floppy disc is used as a storage medium, in place of the prior art use of cryptocards. 
     The foregoing and other features, advantages and objectives are attained in various aspects of the invention which encompasses a user authentication method and system, as set forth in greater detail hereinbelow. 
     A first aspect of the invention comprises a method using control equipment and an operating section connected to the control equipment and comprising the steps of 
     reading a storage medium that stores specific parameters and creating a user authentication code from the specific parameters and other parameters provided by the control equipment using a specific function on the operating section side; 
     sending the created user authentication code to the control equipment; 
     comparing the user authentication code sent from the operating section with another code computed using a specific function generated in the control equipment on the control equipment side; and 
     allowing the information to be inputted or outputted or otherwise interchanged between the control equipment and the operating section when both codes coincide as a result of the comparison. 
     According to a first configuration of the invention, information is inputted or outputted or otherwise interchanged between the control equipment and the operating section only when a user authentication code created in the operating section coincides with another code generated in the control equipment as a result of the comparison of the two codes. In this case, the user authentication code created in the operating section is prepared from a specific function using a storage medium storing specific parameters in advance, Consequently, reliable security is possible at low cost for users desiring access to the control equipment. 
     A floppy disk can be used as the storage medium, and the user name, last access client ID, last access date and time, sequential number and seed can be selected as the parameters to be record. With use of a floppy disk as the low cost storage medium, a low cost highly reliable authentication method and system are realized. 
     A second aspect of the invention encompases a user authentication system comprising control equipment; an operation system connected to the control equipment; means for reading a storage medium storing specific parameters and for creating in the operating section a user authentication code using a specific function from the specific parameters and from other parameters provided by the control equipment; an authentication manager means for generating a specific code based on parameters sent from the storage medium using a specific function; an authentication web server means for downloading an applet for authentication to a browser that accesses the server for authenticating a URL (home based address) with a key sent from the operating section; and means for displaying a targeted page in a display section by acquiring the targeted page from the linked web server, respectively, in the control equipment. 
     According to the second aspect, information is inputted or outputted or otherwise interchanged between the control equipment and operating section only when a user authentication code, created in the operating section, coincides with another code generated in the control equipment as a result of the comparison of the two codes. In this case, the user authentication code created in the operating section is prepared from a specific function using a storage medium which stores the specific parameters in advance. Consequently, reliable security is realized with use of a low cost storage medium when the user desires to access the control equipment. 
     As with the prior configuration, advantageously, a floppy disk can be used as the storage medium, and the user name, last access client ID, last access date and time, sequential number and seed can be selected as the parameters to be recorded. 
     A third aspect of the invention encompasses a method for use in an information transmission system comprising a host and at least one terminal connected thereto and comprising the following steps: 
     reading a storage medium in which are stored specific parameters at the at least one terminal; 
     creating a user authentication code from the specific parameters using a specific function at the at least one termnial; 
     sending the created user authentication code and user name to the host from the at least one terminal; 
     comparing the user authentication code sent from the at least one terminal with another code using a host generated specific function in the host; and 
     allowing the host to implement information transmission to the at least one terminal when the two codes coincide as a result of the comparision. 
     According to a third configuration of the invention, the information transmission is executed between the host and the at least one terminal only when the user authentication code created at the at least one terminal coincides with another code generated in the host as a result of the comparison of the two codes. In this case, the user authentication code created at the at least one terminal is prepared from a specific function using a storage medium which stores specific parameters in advance. Consequently, reliable security is maintained with a low cost storage medium when the user desires access to the host. 
     As with the previously discussed configuration, a floppy disk can be used as the storage medium and the user name, last access terminal ID, last access date and time sequential number and seed can be selected as the parameters to be recorded. Accordingly, for similar reasons, a low cost user authentication is realized having reliable security. 
     A fourth aspect of the invention encompasses an information transmission system comprising a host; at least one terminal connected to the host; means for reading a storage medium storing specific parameters and for creating a user authentication code from a specific function using the specific parameters in the at least one teminal; means for generating a user authentication code using a specific function based on parameters sent from the at least one terminal; and means for authenticating a user authentication code provided by the at least one terminal and for executing a specified user service when the two codes coincide as an authentication result. 
     According to a fourth configuration of the invention, information transmission is executed between the host and at least one terminal only when the user authentication code, created at the at least one terminal, coincides with another code generated in the host, as a result of the comparison of the two codes. In this case, the user authentication code created at the at least one terminal is prepared from a specific function using a storage medium which stores specific parameters in advance. Consequently, reliable security can be maintained using a low cost storage medium when the user desires to access the host. As with the other configurations, a floppy disk can be used as the storage medium and the user name, last access terminal ID, last access date and time, sequential number and seed can be selected as the parameters to be recorded. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a block diagram depicting an illustrative embodiment of the invention. 
     FIG. 2 is a flow chart depicting operation of the invention. 
     FIG. 3 is a flow chart depicting operation of another embodiment of the invention. 
     FIG. 4 is a flow chart depicting operation for preparing a floppy disk with a key. 
     FIG. 5 is a flow chart depicting authenticating action during operation. 
     FIG. 6 is a flow chart depicting access limiting operation by the invention. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     FIG. 1 shows a host  10 , an a plurality of browsers  20 ( 1 ) . . .  20 (n), as clients, connected to host  10 . A floppy disk  22 ( 1 ) . . .  22 (n) used as a physical key for authentication is mounted in each browser  20 ( 1 ) . . .  20 (n). The following parameters, for example, are stored in the floppy disks  22 ( 1 ) . . .  22 (n). (a) user name. (b) last access client IP. (c) last access date and time. (d) sequential number. (e) seed. Item (b) is the IP (i.e. identification number) of a client who accessed last. The client IP is a number that a client independently has and thus each client has only one unique number. The sequential number (d) is a number that shows the number of access times, i.e. how many times the client has accessed. Seed (e) is an initial value that becomes the base of computation of a specific function. 
     In browser  20 ( 1 ) . . .  20 (n), there is an authentication code creating means  21 ( 1 ) . . .  21 (n), which creates user authentication codes using parameters stored in floppy disk  22 ( 1 ) . . .  22 (n) and the hash function, a specific function, from the parameters sent from host  10 . 
     Host  10  comprises an Authentic Manager  11  which creates hash codes (e.g. authentication codes) using a hash function, a specific function, based on the parameters stored in a device contained therein. The manager  11  compares the hash code from a browser with the just mentioned prepared hash code and passes a key to the browser when both hash codes coincide as a result of the comparison. The host  10  also comprises an Authentication Web Manager  12  which sends an applet for authentication to the browser  20 ( 1 ) . . .  20 (n) that accesses the Authentication Web Manager  12 . The Web Manager  12  also authenticates a URL (i.e. home page address) with a key sent from a browser  20 ( 1 ) . . .  20 (n) and acquires a targeted page from the linked Web Server  1  and sends the targeted page out to the browser  20 (.) . . .  20 (n) when both user authentication codes coincide as an authentication result. 
     As used herein, the term “applet” is a JAVA program operated in a browser. Browsers  20 ( 1 ) . . .  20 (n) are connected to host  10  via authentication web manager  12 , as depicted in FIG.  1 . 
     An existing Web Server  1  is connected to Authentication Web Manager  12  via link  3 . A storage device  2  is connected to the Web Server  1  and stores, for example, home page information. The operation of the system shown in FIG. 1 is discussed hereinbelow. 
     SUMMARY OF OPERATION 
     (1) A client accesses authentication web manager  12  as if accessing an ordinary web page from browser  20 ( 1 ) . . .  20 (n). 
     (2) Authentication Web Manager  12  sends an applet for the Browser  20 ( 1 ) . . .  20 (n). 
     (3) Browser  20 ( 1 ) . . .  20 (n) reads user information from a floppy disk  22 ( 1 ) . . .  22 (n) of the client using the downloaded applet for authentication, and computes parameters stored in the floppy disk  22 ( 1 ) . . .  22 (n) using the hash function, and creates a user authentication code. 
     (4) The applet for authentication sends out the created user authentication code to Authentication Manager  11  via Authentication Web Manager  12 . 
     (5) Authentication Manager  11  executes computation using a hash function in host  10 , generates a code, and compares this code with the user authentication code sent from the browser  20 ( 1 ) . . .  20 (n). Authentication manager  11  then sends the authentication result to the applet for authentication in browser  20 ( 1 ) . . .  20 (n). 
     (6) The applet for authentication, when authentication is successfully completed, accesses the authentication web manager  12  with the URL with a key so that the targeted page is displayed. 
     FIG. 2 shows a flow chart showing operation of the embodiment of FIG.  1 . Browser  20 ( 1 ) . . .  20 (n) (labeled “CLIENT” in FIG. 2) accesses a targeted page through Authentication web Manager  12  (labeled “Authentication Web Server” in FIG. 2) (Step S 1  ). Receiving this access, Authentication Web Manager  12  sends an applet for authentication to the browser  20 ( 1 ) . . .  20 (n) (Step S 2 ). It is to be understood that even though a plurality of identifying numbers are listed, such as  20 ( 1 ) . . .  20 (n) for the browser, a particular one or more thereof is being used at a time. 
     The client runs the applet for authentication when the applet for authentication is downloaded (Step S 3 ). The applet for authentication reads the parameters from a floppy disk  22 ( 1 ) . . .  22 (n) (See the floppy disk symbol in FIG. 2) for authentication and creates a user authentication code (e.g. challenge code) using hash function. In this case the seed including parameters for computation of hash function is sent from Authentication Web Manager  12 . Thus, the applet for authentication creates a unique challenge code from the hash function using the seed and user name, last access date and time, and sequential number stored in the floppy disk  22 ( 1 ) . . .  22 (n). 
     Browser  20  reads the user information and the challenge code for authentication (Step S 4 ) and sends the user name and challenge code to Authentication Manager  11  (Step S 5 ). 
     Authentication Manager  11  creates a code from the hash function using the last access date and time and sequential number stored in the host  10  in advance based on the sent user name and challenge code, and compares the created code with the challenge code sent from browser  20 ( 1 ) . . .  20 (n). The result of the comparison is sent to the client from Authentication Manager  11  (Step S 7 ). At that time, since it is the authentication result that is sent and not the password, there is no possibility of the password being stolen. 
     On the client side that receives the authentication result, when browser  20 ( 1 ) . . .  20 (n) identifies the user from the authentication result, browser  20 ( 1 ) . . .  20 (n) creates a new URL to access the targeted URL (Step S 8 ). Next, browser  20 ( 1 ) . . .  20 (n) accesses the Authentication Web Manager  12  with the URL with the key created in Step S 8  (Step S 9 ). Browser  20 ( 1 ) . . .  20 (n) updates the contents of the floppy disk  22 ( 1 ) . . .  22 (n) at the same time. Authentication Web Manager  12  authenticates the contents of the key sent from browser  20 ( 1 ) . . .  20 (n) (Step S 10 ), acquires a targeted page from the linked Web Server  1 , and sends the targeted page out to the client (Step S 11 ). On the client side, the targeted page is indicated in the display of browser  20 ( 1 ) . . .  20 (n) (Step S 12 ). 
     As described, the information transmission is executed between host  10  and browser  20 ( 1 ) . . .  20 (n) only when the user authentication code (e.g. challenge code) created in the browser  20 ( 1 ) . . .  20 (n) coincides with another code generated in the host  10  as a result of comparison of the two codes. In this case, the user authentication code (eg challenge code) is created from a specific function (e.g. hash function) using a floppy disk  22 ( 1 ) . . .  22 (n) having stored therein in advance specific parameters. Consequently, reliable security is maintained using a low cost storage medium when the user desires to access the host  10 . 
     In addition, advantageously, since a floppy disk  22 ( 1 ) . . .  22 (n) can be used as a storage medium, there is realized by the invention, a low cost authentication method and system, wherein reliable security is maintained without necessity of using cryptocards. 
     FIG. 3 is a flow chart similar to FIG.  2  and represents operation of another embodiment of the invention, wherein omitted is use of the URL with a key. An arbitrary one of browsers  20 ( 1 ) . . .  20 (n) accesses a targeted page through Authentication Web Manager  12  (Step S 1  ). Receiving this access, Authentication Web Manager  12  sends an applet for authentication to browser  20 ( 1 ) . . .  20 (n). (Step S 2 ). 
     The client runs the applet for authentication when it is downloaded (Step S 3 ). The applet for authentication reads the parameters from a floppy disk  22 ( 1 ) . . .  22 (n) for authentication and creates a user authentication code (eg challenge code) using a hash function. In this case, the seed including parameters for computing the hash function is sent from the Authentication Web Manager  12 . Thus, the applet for authentication creates a unique challenge code from the hash function using the seed and user name, last access date and time, and sequential number stored in the floppy desk  22 ( 1 ) . . .  22 (n). 
     Browser  20 ( 1 ) . . .  20 (n) reads the user information and challenge code for authentication (Step S 4 ), and sends the user name and challenge code to Authentication Manager  11  (Step  55 ). 
     Authentication Manager  11  creates a code from the hash function using the last access date and time and sequential number stored in the host  10  in advance, based on the user name and challenge code sent from the browser  20 ( 1 ) . . .  20 (n) and compares the created code with the challenge code (Step S 6 ). The result of the comparison is sent to the client from Authentication Manager  11  (Step S 7 ). At that time, since it is the authentication result that is sent and not the password, there is no possibility of the password being stolen. 
     Next, Authentication Manager  11  creates a proxy for the authenticated client (i.e. proxy process for communicating with the targeted Web Server  1 ) and sends it to the Authentication Web Manager  12  (Step S 8 ). Concurrently, on the client side, browser  20 ( 1 ) . . .  20 (n) accesses the specified URL page again via Authentication Web Manager  12  upon identifying the user with the authentication result (Step S 9 ). Browser  20 ( 1 ) . . .  20 (n) updates the contents of the floppy disk  22 ( 1 ) . . .  22 (n) at the same time. 
     Authentication Web Manager  12  identifies the client using the proxy for the authenticated client (Step S 10 ). When the client is authenticated, the Manager  12  acquires the targeted page from the linked web server  1  and sends-it out to the client (Step S 11 ). On the client side, the targeted page is indicated in the display of the browser  20 ( 1 ) . . .  20 (n) (Step S 12 ). 
     Information transmission is executed between the host  10  and the browser  20 ( 1 ) . . .  20 (n) only when the user authentication code (eg challenge code) created in the browser  20 ( 1 ) . . .  20 (n) coincides with another code generated in the host  10  as a result of comparison of the two codes. In this case, the user authentication code is created from a specific function (eg hash function) using a floppy disk  22 ( 1 ) . . .  22 (n) which has stored previously therein the specific parameters. Consequently, reliable security is maintained at low cost when the user desires to access the host. 
     In addition, since a floppy disk can be used as the storage medium, a low cost user authentication method can be realized by the invention. 
     FIG. 4 shows a floppy disk preparation operation with a key, wherein from the client side, the user calls up a Server Administrator to request registration of himself or herself (Step S 1 ). On the server side, the Server Administrator registers the user as requested using a User Management Tool (Step S 2 ). The Server Administrator informs the user of his or her user name and the pass-phrase by telephone (Step S 3 ). 
     On the client side, the user opens a web page to create a key using a browser, sets the user name and the pass phrase to the applet to create a key, and clicks on [GO] (Step S 4 ). Next, the user sends the user name, pHc, and user&#39;s IP address to the Server (Step S 5 ). The Server authenticates the user with the received user name and pHc (i.e. the user authentication code created on the client side) and using the user name and pHs (i.e. authentication code crated on the Server side) managed by the Server (Step S 6 ). 
     When authentication is completed, the Server informs the client of the authentication result. The client receives the authentication result (Step S 7 ). Next, when authentication is successfully completed, the Server sends out a sequential number (Sq.No.) and the last access date and time (Step S 8 ). On the client&#39;s side, a key functioning floppy disk is created for writing the received authentication date and time and the sequential number when authentication is successfully completed (Step S 9 ). 
     FIG. 5 shows a flow chart representing authenticating actions during usual operation. First, on the client side, a user inserts a key functioning floppy disk  22 ( 1 ) . . .  22 (n) into a drive and accesses a targeted page using a browser  20 ( 1 ) . . .  20 (n) (Step S 1  ). Next, the browser  20 ( 1 ) . . .  20 (n) reads the user name, last authenticated date and time (i.e. last access date and time), and a sequential number from the key functioning floppy disk  22 ( 1 ) . . .  22 (n). (Step S 2 ). The browser  20 ( 1 ) . . .  20 (n) creates a challenge code Hc using the last access date and time and the sequential number and sends the Hc, the user name and user&#39;s IP address to the Server (Step S 3 ). 
     The Server creates an authentication code Hs using the last access date and time and the sequential number, compares the created Hs with the received Hc for authentication, and then sends the authentication result to the client side (Step S 4 ). 
     On the client side, the browser  20 ( 1 ) . . .  20 (n) receives the authentication result (Step  55 ). On the Server side, when the authentication is successfully completed, the Server sends out the sequential number and the last access date and time to the client (Step S 6 ). On the client side, when the authentication is successfully completed, the browser  20 ( 1 ) . . .  20 (n) updates the sequential number, the last authenticated date and time, and the last access client IP on the key functioning floppy disk  22 ( 1 ) . . .  22 (n) and then accesses the Authentication Web Manager  12  to indicate the targeted page (Step S 7 ). 
     FIG. 6 shows a flow chart representing the access limiting operation performed by the invention. When the browser  20 ( 1 ) . . .  20 (n) on the client side access a target page (Step S 1 ), since the web server  1  is waiting for connection by the browser  20 ( 1 ) . . .  20 (n), (Step S 2 ), the web server  1  checks whether or not the acquired file name is to be authenticated upon being accessed from the browser  20 ( 1 ) . . .  20 (n) (Step S 3 ). 
     If the file is to be authenticated, the web server  1  checks whether the file has a key (Step S 4 ). If it is a file with a key, the web server  1  checks the key&#39;s expiry date (Step S 5 ). If the expiry date is not yet reached, the web server checks who is the sender, that is whether or not the sending source of the key is the specified client (Step S 6 ). If the sending source of the key is the specified client, the web server sends out the data of the targeted page to the specified client (Step S 7 ). The specified client receives the sent page data (Step S 10 ). 
     If the acquired file is not/ requird to be authenticated in Step S 3 , the web server  1  sends out the data of the targeted page to the client (Step S 7 ) and the dent receives the data (Step S 10 ). 
     On the other hand, if the file is required to be authenticated, but not with a key in step S 4 , the web server  1  downloads a page of an applet for authentication to the browser  20 ( 1 ) . . .  20 (n) on the client side (Step S 8 ) and the client receives this page of the applet for authentication (Step S 10 ). If, in Step S 5 , the key&#39;s expiry date has been reached, the web server  1  sends an error message page to the client (Step S 9 ), and the client receives the error message page (Step S 10 ). 
     In addition, in Step S 6 , if the sending source of the key is other than the client who acquired the key, the web server  1  sends and error message to the client (Step S 9 ), and the client receives the error message page (Step S 10 ). 
     Data transmission between the host  10  and at least one browser  20 ( 1 ) . . .  20 (n) and the user authentication method according to the invention are not limited to the foregoing discussion. The invention can also be similarly applied where the user accesses an independent control equipment (eg personal computer )from an operating section (eg keyboard). Also, in this case, a low cost floppy disk can be used as the physical key. 
     According to the invention, advantageously, the information is inputted or outputted or otherwise interchanged between the control equipment and the operating section only when the user authetication code created in the operating section coincides with the code created or generated in the control equipment as a result of comparison of the two codes. In this case, the user authentication code created in the operating section is prepared from a specific function using a storage medium which stores specific parameters in advance. Consequently, the invention realizes reliable security with low cost whever the user desires to access the control equipment. 
     Also, advantageously, the invention uses floppy disks as the storage medium, and the parameters to be recorded therein are the user name, last access client IP, last access date and time, sequential number and seed. Such use of floppy disks enables the invention to provide reliable security of authentication at low cost, and without requirement of cryptocards, as done in the prior art. 
     The foregoing description is illustrative of the principles of the invention. Numerous extensions and modifications thereof would be apparent to the worker skilled in the art. All such extensions and modifications are to be construed to be within spirit and scope of the invention.