Abstract:
Methods and apparatus for verifying the acceptability of a password proposed by a user of a secure system. The system stores a compressed version of a group of unacceptable passwords in a table of indicators. A mapper assigns indicators to passwords, such that more than one password may be mapped to a indicator. To initialize the system, an initializer applies the mapper to each unacceptable password of the group, and sets the indicators of the table that are assigned to each unacceptable password. Subsequently, a verifier applies the mapper to a proposed password and checks whether the indicator assigned to the proposed password is set. If the indicator is not set, it is determined without error that the proposed password is not in the group of unacceptable passwords, and may thus be assigned privileges in the secure system.

Description:
BACKGROUND OF THE INVENTION 
     The present invention relates to password security systems. 
     Many secure systems rely on the use of passwords to verify the identity or credentials of persons (or other objects such as computing processes) that request access to the system. An example of such a system is a multi-user computer system. 
     In those password-based security systems, security may be compromised if the passwords are easy to guess (common names are often good guesses for passwords), or if the passwords are written down so that they can be found by unauthorized users. 
     Passwords can be selected by the system management or by the users themselves. In either scheme there are strong possibilities for breaches of security. 
     System management may impose &#34;secure&#34; passwords that are not easy to guess (e.g., random sequences of nonsense syllables). However, the resulting passwords are often obscure and difficult to memorize. Typically, the users will write down such passwords rather than attempt to remember them. These written records can be found and misused by unauthorized persons. 
     In the alternative, the users may be allowed to select their own passwords. User-selected passwords are more likely to be memorizable, and thus the users will be less tempted to write them down. However, user-selected passwords are often easy to guess. 
     In one known scheme, the user chooses his or her password, but their &#34;security&#34; (or lack of obviousness) is verified by the system. In this way, all of the passwords used by the system are memorizable (at least to the user that chose them) but are also unobvious. Implementing such a scheme requires a method for checking the &#34;validity&#34; of passwords. One known method compares the password to a look-up table of invalid passwords (for example, the look-up table may include example passwords used in the software documentation). If a password is found in the table, the user is asked to change the password. 
     SUMMARY OF THE INVENTION 
     In general, the invention features verifying the acceptability of a password proposed by a user of a secure system. An approximate membership tester is used to test whether the proposed password is a member of a group of unacceptable passwords. When this approximate membership tester tests the membership of a proposed password in the group of unacceptable passwords, it may erroneously indicate membership of the proposed password in the group, but it cannot erroneously indicate non-membership of the proposed password in the group. Based upon the indication of the approximate membership tester, it can be determined without error if the proposed password is not in the group of unacceptable passwords and thus may be assigned privileges in the secure system. 
     Preferred embodiments include the following features. 
     The group of unacceptable passwords is stored in a table of indicators through the use of a mapping function that maps passwords to indicators. This mapping function may map more than one password to one indicator. To initialize the table, the mapping function is applied to each unacceptable password, and the indicators assigned to each of the unacceptable passwords are set. Subsequently, the mapping function is applied to the proposed password, and the indicator assigned to the proposed password is checked. If the indicator is not set, it is determined without error that the proposed password is not in the group of unacceptable passwords. 
     The indicators and group of unacceptable passwords are provided in a manner enabling a user to add further unacceptable passwords to the group and thereby vary which indicators are set. 
     When the proposed password is determined to be acceptable, the proposed password is added to the group of unacceptable passwords and the indicator assigned to the proposed password is set, so that the proposed password will not be accepted a second time. 
     From time to time, the privileges of a user&#39;s password are at least partially disabled, and the user is required to propose a new (acceptable) password to regain these privileges. This forces the users to change their passwords and (because passwords will not be accepted twice) also helps to &#34;weed out&#34; unacceptable passwords that were initially omitted from the group. 
     A common table of indicators is used by a network of secure systems to verify the acceptability of passwords, so that any one password may only be assigned privileges in one of the secure systems. In this embodiment, when a password is proposed by a user to one of the secure systems, that secure system checks the acceptability of the proposed password in the manner described above and using the common table of indicators. If the secure system finds the proposed password to be acceptable, it adds the proposed password to the group of unacceptable passwords and sets the corresponding indicator in the common table. Thereafter, if this password is again proposed to any of the secure systems, it will not be acceptable and will not be assigned privileges. 
     The indicators are bits in a hash table and the mapping function is a hash function. 
     The processing performed by the hash function includes normalizing the text string for a password to a predetermined length. The text string is normalized by: (1) appending to the text string a character related to the length of the text string, creating a modified text string; (2) if the length of the modified text string is even, adding a character to the modified text string, thus forcing the text string to have an odd length; and (3) appending the odd-length text string to itself until it exceeds a given length, and then truncating it to the given length. 
     The normalized text string is then divided into pieces, and one or more pieces are used as a key to encrypt a predetermined input. The encrypted output is then used to address bits in the hash table. In order that the bits in the hash table cannot be used to determine the passwords in the group of unacceptable passwords, the encryption is performed in accordance with a cryptographic technique secure against plain-text attack, such as the Data Encryption Standard. 
     To reduce the number of passwords that are incorrectly deemed unacceptable, the encrypting step is repeated N times on N of the pieces of the normalized text string to create N encrypted outputs. These N encrypted outputs are then split to generate final outputs, and one or more bit addresses in the hash table are computed from one or more final outputs as the modulo of the final output with the length of the hash table. 
     Other features and advantages of the invention will be appreciated from the following description of the preferred embodiment and from the claims. 
    
    
     BRIEF DESCRIPTION OF THE DRAWING 
     We first briefly describe the drawings: 
     FIG. 1 is a block diagram of a validity checker in practice of the present invention. 
     FIG. 2 is a detail of the hash table of FIG. 1. 
     FIG. 3 shows formation of values V 1-6 . 
     FIGS. 4 through 7 illustrate the normalization of a password and the formation of keys K 1-6 . 
     FIG. 8 shows formation of outputs H 1-6 . 
     FIG. 9 shows formation of outputs h 1-12 . 
     FIG. 10 shows formation of bit addresses. 
     FIG. 11 shows bits turned on in the hash table. 
     FIGS. 12-14 detail embodiments of controller 26, converter 14, and hash function units 13 of FIG. 1. 
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     Known password security systems compare passwords to a look-up table. This operation requires what is generally known as a membership tester. Membership testers fall into either of two general categories: exact or approximate testers. The exact tester is presumed to act without error, and is preferred when there are no limitations placed on use of system resources. In an approximate membership tester one presumes some degree of &#34;allowable error&#34; as the trade off for substantially reduced use of system resources. 
     Hashing is one known technique that may be used to create approximate membership testers. In this technique, a &#34;hash table&#34; stores a compressed representation of the members of the set that is to be tested. Each item in the set (represented by a numerical key, which may, for example, be the ASCII codes for a text string) is subjected to an arithmetic transformation (known as a &#34;hash function&#34;); the function output indicates a hash table address. A bit is turned on (e.g., raised to logic 1) in the hash table when it is addressed. (Note that a prerequisite of a good transformation function is that it distributes its outputs as evenly as possible over the entire table. While the transformation function output distribution is not bound by any pattern, it is usually desirable if the output appears random.) When all of the members of the set have been placed in the table, a candidate item (i.e., an item which may or may not be in the set, to be determined by the membership test) is subjected to the hash function (arithmetic transformation). Next, the resulting table address is checked. If the bit at that address is set, the candidate item is deemed to be a member of the set; otherwise, it is not. 
     When hashing is used to create an approximate membership tester, the mapping between items and addresses in the hash table is not unique. That is, the hash function does not map every possible item to a unique associated table address. This non-unique mapping is used because the number of possible items may be much larger than the number of items in the set that is to be tested. (Consider, for example, a membership tester being used as a spelling checker. The membership tester determines if a word being spell checked appears in a dictionary of correctly spelled words. The number of possible text strings that have a length of 20 characters or less is clearly much larger than the number of words that are listed in any dictionary.) Using a non-unique mapping, the number of bits in the hash table may be significantly less than the number of possible items, reducing storage requirements. As a result, however, two or more different items may &#34;hash&#34; to the same table address (i.e., they may result in the same hash function output). When this occurs, it is commonly referred to as a &#34;collision&#34;. 
     For example, in an approximate membership tester using a hash function that operates on the middle four characters of items identified by 8-character text strings, if two text strings have the same middle four characters (e.g., XXWORDOO and OOWORDXX), then a collision will occur. 
     Collisions in approximate membership testers generate some level of &#34;known&#34; or &#34;allowable&#34; error in the membership test. Consider the above example of a spelling checker. In this case, a collision between a misspelled word and a correctly spelled word results in an indication that the misspelled word is correctly spelled, which is clearly an error. 
     Carter, et al., in &#34;Exact and Approximate Membership Testers&#34;, Proceedings of 10th Annual ACM Symposium on Theory of Computing (STOC), May, 1978, at p. 62, describes the possibility of such errors in an approximate membership tester for a vocabulary V. The tester has an associated preprocessor that digests V and produces a compressed representation of a superset W of V. The input to the tester is the compressed representation W and a possible word s; the membership tester estimates whether s is in V by actually computing if s is in W. Under the assumption that all errors are equally likely, the undetected error probability is (w-v)/(u-v), where w is the size of W, v is the size of V, and u is the number of possible words. In this tester, the authors seek to achieve an undetected error probability of 2 -r  based upon the number v of vocabulary words and a reliability exponent r, for a given universe size u. 
     In the present invention, to reduce the amount of system resources required to store the password look-up table, an approximate membership tester is used to determine if a user password is one of the unacceptable passwords in the look-up table. Normally, the use of an approximate membership tester would be associated with &#34;allowable errors&#34;. However, as applied in the invention, the errors of the approximate membership tester do not compromise the security of the system. When the approximate membership tester erroneously indicates that a user&#39;s password is in the look-up table, the result is simply an inconvenience to the user, who must then choose another password. However, the approximate membership tester will never erroneously indicate that a user&#39;s password is not in the look-up table. Therefore, under no circumstances will unacceptable passwords that are in the look-up table will be used in the system. 
     In the invention, the approximate membership test is performed by hashing. This provides the added benefit that the look-up table is compressed and somewhat encrypted. The level of encryption provided by the invention depends upon the hash function used. A particularly secure method for hashing the passwords is described below. 
     Encrypting the list of unacceptable passwords is advantageous because, without access to the list, would-be invaders of the system do not know which passwords have been deemed &#34;insecure&#34;, and thus may spend time guessing obvious passwords that are not in use. Note that an encryption requirement precludes the possibility of simply re-using the spelling dictionary (or any other file already on the system) as the look-up table. One difficulty this may cause is that a comprehensive password look-up table would be about the same size as a spelling dictionary file, and would consume excessive system resources; however, in the invention, the use of hashing compresses the look-up table so that it has a reasonable size. 
     In a simplified embodiment of the present invention, one or more invalid (not secure) passwords (e.g., from the above example, the word XXWORDOO) are input to the system, and then numerical representatives of the passwords (such as derived from ASCII equivalents for the passwords) are submitted as a key K i  to a single hash function h(K). The output of the hash function indicates an address h(K i ) in a hash table, and a bit at that address can be thus turned on. Once a bit is turned on, it remains on. A turned on bit indicates that one or more passwords are no longer available for use. This is because any password which generates a table address of a turned on bit (e.g., from the above discussion, the word OOWORDXX) is rejected as not valid; any other password is declared to be valid. Hash table size, and thus the likelihood of collisions, is selected entirely at the programmer&#39;s discretion. 
     A more robust embodiment of the invention is shown in FIG. 1. In this embodiment, fewer collisions will occur resulting in a greater number of passwords being deemed valid by the tester. Two sample passwords, an invalid password XXWORDOO and a valid password OOWORDXX are shown as they are entered into the system at keyboard input 12 and are converted to a number by converter 14. In this embodiment, an ASCII number corresponding to the input passwords is output by converter 14 to three hash function units 16, 18, 20. (Each hash function is assumed to be different. Also, the number of hash function units used is an arbitrary design choice.) 
     To load the table with compressed representations of invalid passwords, the outputs of the hash function units are applied to, for example, a 26-bit table 22; controller 26 directs table 22 to turn on respective bits. In the figure, as the invalid password &#34;XXWORDOO&#34; is submitted to each of the three hash functions, respective addresses A, J, and Z are output by each respective hash function unit. As a result, bits A, J and Z are turned on in the hash table shown in FIG. 2. Further invalid passwords may be added by repeating these steps. Note that, during this process, two invalid passwords may have a collision, that is, the outputs of the hash function units may happen to address one or more common bits in the table. If this occurs, because the common bits are already set, they do not need to be set to add the later invalid password to the table. 
     Thereafter, candidate passwords proposed by a user may be checked by comparison with the hash table. If, when a candidate password is processed, the outputs of the three hash function units 16, 18 and 20 address bits in the table which are turned on (in the simple example of FIG. 1, the bits A, J, and Z), in any order, and even if based upon one or more collisions, verifier 24 (coupled to the hash table and hash function units) will indicate a &#34;match&#34;. This tells the privilege assigner 28 that the candidate password is not valid, i.e., not secure. 
     Thus each candidate password which is submitted to the system will be considered a valid password if it includes at least one hash function output indicating an address other than the turned-on addresses (in the simple example of FIG. 1, bits A, J, and Z). In other words, if at least one bit which is as of yet not turned on in the table is addressed, then the password is indicated as secure/valid, and privilege asssigner 28 will allow the user to retain it for secure use as a password. However, when no new bits are addressed, then a &#34;match&#34; is declared (by comparator 24) between the candidate password and the hashing table contents. When a match is declared, the candidate password is indicated to the user as invalid, and a new candidate password must be selected and tested. 
     For example, when a proposed password &#34;OOWORDXX&#34; is processed, the outputs of the three hash functions 16, 18, 20 address the three bits A, H and K in the hash table. Although bit A was turned on by the entry of the invalid password &#34;XXWORDOO&#34; in the hash table, because the bits H and K were not turned on, the password &#34;OOWORDXX&#34; is deemed valid. This illustrates the benefit of a more robust system using multiple hash functions, i.e., that with three hash functions it is possible to distinguish between the two sample passwords by comparing bit address combinations (AJZ and AHK) whereas a system with only the first hash function would have generated an indistinguishable collision with the identical addresses (A, A). This feature enables a finding of validity of a greater number of secure candidate passwords. 
     In practice of one embodiment of the invention, a user selects a candidate password, the password is submitted to the validity checking feature of the invention, and the candidate password is indicated as valid/invalid to the user. To initialize the table with invalid passwords, any of the following three options may be implemented. First, a vendor can preload a hash table with predetermined invalid (not secure) or common words. For security purposes, no external access is afforded to the table, and the pre-loaded table does not change over time. Candidate passwords are rejected if a match is declared; however, more than one user can select and use the same valid/secure password (i.e., not in the table), since the table is never updated. 
     In a second option, a security officer can be allowed to add invalid passwords to the table (for example, common words in the particular field of business of the users), but other than these modifications, the table is not changed. Therefore, more than one user could still select and use the same valid password. 
     The above two methods rely on a few persons to generate a comprehensive list of obvious passwords. As a result, there is a strong possibility that some obvious passwords may be omitted from the table. In the worst case, many users may choose one or more of these omitted obvious passwords, reducing security. 
     To reduce this possibility, a third option is preferred. In this option, each password that is deemed valid is added to the hash table, rendering that password invalid for future selection. Hence more than one user cannot select the same password. In addition, as above, a security officer can be allowed to add known invalid words to the table. 
     Referring to FIG. 12, in an embodiment of the third option, controller 26 of FIG. 1 includes an initializer 30 that sets bits in the hash table corresponding to invalid passwords (as described above), and a modifier 32 that sets the bits assigned to a password which verifier 24 determines to be valid. 
     In this third option, only one user may use a given password, if the table does not initially include all obvious passwords (even with the obvious words added by a knowledgeable security officer), some users will be able to use (different) obvious passwords. For this reason, it may be valuable to periodically force all users to change their passwords. To force a user to change, the system may simply prevent him or her from performing any activities on the system until he or she suggests an acceptable new password--for security reasons, this must be done after the user has already logged in with his or her old password. When forced to change, the users may not re-use their passwords (because they were added to the table when first deemed valid), and thus they must suggest new, previously unused passwords. Assuming some users may initially choose obvious passwords not in the table, this process will eventually &#34;weed out&#34; any obvious passwords that were omitted from the table and selected by the users, thus obtaining a higher degree of password security. 
     In a further extension of the third option, in a system with multiple computers, a central hash table prevents the user from choosing the same valid password on multiple computers. This prevents a local breach from becoming a general breach of security. 
     As discussed above, encryption of the look-up table is quite important to overall system security. The enhancements of the third option increase the importance of encryption because, in the third option, the table is constantly being updated, and the updates correspond exactly to the passwords have recently come into use. In a preferred embodiment of the invention, which is particularly effective at guaranteeing table security, cryptographically secure hash functions are used. These functions preferably incorporate the known DES (Data Encryption Standard) algorithm. In this embodiment, candidate passwords are encrypted as part of the hashing operation. The encryption is performed in accordance with the equation: 
     
         H=DES(K,V) 
    
     where the output H (which is a hash value) is the result of the DES algorithm applied with key K to the input value V. The respective lengths of the key K, the input value V, and the output H are selected to be 8 bytes in this example, subject to the restrictions of DES. 
     The encryption is performed as follows: the key K is derived from the password, and it is used to encrypt a predetermined input value V. Because the key is generated from the password and changes with every encryption, no information about a password can be determined as a practical matter from the encrypted hash value in the table. This is because, in encryption algorithms consistent with DES, even if an attacker knows the output H and input V for the encryption process, it is not possible to determine the key K that was used. An encryption algorithm that satisfies this requirement is secure against &#34;known plain text attack&#34;. 
     In one particular embodiment, the password is used to create six keys K 1-6  that encrypt six input values V 1-6  to create six outputs H 1-6 . 
     Referring to FIG. 3, the six input values V 1-6  are generated by selecting three arbitrary 16-character strings, which are dissected. Thus in one example, V 1  is &#34;JerroldS&#34;, and the bytes of V 1  are: the byte for &#34;J&#34;, followed by the byte for &#34;e&#34;, etc. V 2  is &#34;Leichter&#34;, and so on. In this example, six values V 1-6  have been created for use in the encryption process, although the invention is not limited to such number. 
     Prior to creating the six keys K 1-6 , the length of each password must be normalized. Referring to FIG. 4, for example, consider that the (obvious and therefore invalid) password P =&#34;Susan&#34;, which has a length of five bytes (i.e., five characters), is to be placed in the table. First, referring to FIG. 5, a character representing the length of the password (&#34;5&#34;) is pre-pended to the password, creating a 6-character password P&#39;=&#34;5Susan&#34;. 
     Next, referring to FIG. 6, if the length of P&#39; is even, a character, such as &#34;?&#34;, is appended to the password, thus creating a seven character password P&#39;&#39;. Referring to FIG. 13, in one embodiment these operations may be performed by an appender 34 in converter 14 of FIG. 1. Finally, referring to FIG. 7, password P&#39;&#39; is appended to itself as needed until its length reaches or exceeds 48 bytes. This operation is performed by repeater 36 (FIG. 13) of converter 14 (FIG. 1). The first 48 bytes are divided into six 8-byte segments to obtain six keys K 1-6  the first eight bytes are K 1 , the next eight are K 2 , and so on. This operation is performed by divider 38 (FIG. 13) of converter 14 (FIG. 1). (Forcing the length of password P&#39;&#39; to be odd and at least of a given length--perhaps at least six bytes--assures distinctness of the keys.) 
     The six keys K 1-6  and six predetermined input values V 1-6  are then input into six separate DES encryptions. Referring to FIG. 14, in one embodiment these encryptions may be performed by an encrypter 40 in each of the hash function units 16, 18, 20 of FIG. 1. More particularly, referring to FIG. 8, six outputs H 1-6  are generated by applying the conventional DES function to the previously computed keys K 1-6  and the predetermined values V 1-6 . In FIG. 9, the six outputs H 1-6  are split into twelve 32-bit values h 1-12 . Finally, referring to FIG. 10, bit addresses are computed as the modulo of the split values h 1-12  with the length N of the hash table. Some or all of the bit addresses (e.g., the first, second, sixth, and eleventh) may then be used to set bits in the hash table. These functions may be performed by an addresser 42 (FIG. 14) in each of the hash function units 16, 18, 20 (FIG. 1). In preferred embodiments, all bit addresses are used. Thus, for example, the password &#34;Susan&#34; may result in bits 1, 2, 6 and 11 being turned on in the hash table illustrated in FIG. 11. Any other password which would cause these same bits to be turned on will be rejected as not valid/secure. 
     One feature of the foregoing is that the list of passwords entered into the table cannot be reconstructed from the table alone. Thus the table can be transported without the need for extra security. A second feature is that knowing the changes made to the table as the result of adding a single password will not enable determination of the password. Thus the changes can be transported without the need for extra security. 
     Other embodiments are within the following claims.