Abstract:
A system and method for preventing an administrator impersonating a user from accessing sensitive resources on a target system is provided. The method comprises receiving a first request from a user to change the user&#39;s password on a target system to be changed, sending a “change password” request for the user to the target system, storing the user&#39;s new password, receiving a second request from the target system on behalf of the user for access to a sensitive resource, wherein the second request contains information about the user&#39;s password, and denying the second request if the information about the user&#39;s password is not consistent with the user&#39;s stored new password.

Description:
RELATED APPLICATIONS 
       [0001]    This application is a continuation of U.S. patent application Ser. No. 12/451,847, filed Apr. 5, 2010, which claims priority to PCT Application No. PCT/SE2008/050704, filed Jun. 11, 2008, which in turn claims priority to U.S. Provisional Application No. 60/934,128, filed Jun. 11, 2007. U.S. patent application Ser. No. 12/451,847 also relates to, but does not claim priority to, U.S. patent application Ser. No. 09/725,005, filed Nov. 29, 2000 and published as U.S. Patent Publication No. 2002/0066038 on May 30, 2002, and U.S. patent application Ser. No. 11/374,341, filed Mar. 13, 2006 and published as U.S. Patent Publication No. 2007/0067637 on Mar. 22, 2007. All of the applications described herein are incorporated by reference in their entirety. 
     
    
     TECHNICAL FIELD 
       [0002]    The present invention relates to a method and a system for preventing an administrator of a computer system from impersonating a user. 
       BACKGROUND INFORMATION 
       [0003]    In order to protect information stored in a database, it is known to store sensitive data encrypted in the database. To access the encrypted data, the data must be decrypted, which can only be done by knowing the encryption algorithm and the specific decryption key being used. Access to the decryption keys can be limited to certain users of the database system, and further, different users could be given different access rights. 
         [0004]    Specifically, it is preferred to use a so-called granular security solution for the encryption of databases, instead of building walls around servers or hard drives. In such a solution, which is described in WIPO Publication No. WO 97/49211, published on Dec. 24, 1997, a protective layer of encryption is provided around specific sensitive data-items or objects. This prevents outside attacks as well as infiltration from within the server itself. This also allows the system administrator to define which data stored in databases are sensitive and thereby focusing the protection only on the sensitive data, which in turn minimizes the delays or burdens on the system that may occur from other bulk encryption methods. 
         [0005]    Most preferably, the encryption is made on such a basic level as in the column level of the databases. Encryption of whole files, tables or databases is not very granular, and thus encrypts both sensitive and non-sensitive data. It is further possible to assign different encryption keys of the same algorithm to different data columns. With multiple keys in place, intruders are prevented from gaining full access to any database since a different key could protect each column of encrypted data. 
         [0006]    Such a security solution provides separation of the duties of a security administrator (SA) from a database administrator (DBA). The DBA&#39;s role could for example be to perform usual DBA tasks, such as extending tablespaces etc., without being able to see (decrypt) sensitive data. The SA could then administer privileges and permissions, for instance add or delete users. 
         [0007]    For most commercial databases, the database administrator has privileges to access the database and perform most functions, such as changing password of the database users, independent of the settings by the system administrator. An administrator with root privileges could also have full access to the database. This is an opening for an attack where the DBA can steal all the protected data without any knowledge of the protection system above if the DBA impersonates another user by manipulating that user&#39;s password, even though the user&#39;s password is enciphered by a hash algorithm. 
         [0008]    An attack could proceed as follows. First the DBA logs in as himself, then the DBA reads the hash value of the user&#39;s password and stores this separately. Preferably the DBA also copies all other relevant user data. By these actions the DBA has created a snapshot of the user before any altering. Then the DBA executes the command “ALTER USER username IDENTIFIED BY newpassword”. The next step is to log in under the user name “username” with the password “newpassword” in a new session. The DBA then resets the user&#39;s password and other relevant user data with the previously stored hash value. 
         [0009]    The risk of a DBA attack is further exacerbated by the increased outsourcing of information technology administration. While a company may achieve cost savings by delegating routine management of databases, file systems, etc., a subcontractor is likely trusted less than an internal employee, especially where the subcontractor resides in an unfamiliar legal jurisdiction. Companies recognizing this risk are increasing focused on the separation of duties concept under which system administrators such as DBAs have the ability to perform routine maintenance tasks, while a Security Administrator (SA), often at a high management level, regulates access to sensitive resources. For at least these reasons, it is desirable to provide a system and method of limiting a DBA&#39;s ability to access sensitive resources, especially by impersonating a user in an attempt to gain access to the contents of the database. 
       SUMMARY OF THE INVENTION 
       [0010]    A first embodiment of the invention is directed to a method of changing a user password on a target system. The method comprises: receiving a first request from a user to change the user&#39;s password on a target system to be changed, sending a “change password” request for the user to the target system, storing the user&#39;s new password, receiving a second request from the target system on behalf of the user for access to a sensitive resource, and denying the second request if the information about the user&#39;s password is not consistent with the user&#39;s stored new password. The second request contains information about the user&#39;s password. 
         [0011]    The embodiment may include various features. For example, the method may include authenticating the first user. Information about the user&#39;s password may include the user&#39;s password in plain text, the user&#39;s password in encrypted text, and/or a hash value of the user&#39;s password. The sensitive resource may include encrypted data. The target system may be a database, a file system, an application, a network, and/or a data at rest system. 
         [0012]    Another embodiment of the invention is directed to a computer-readable medium whose contents cause a computer to perform a method of changing a user password on a target system by the steps of: receiving a first request from a user to change the user&#39;s password on a target system to be changed, sending a “change password” request for the user to the target system, storing the user&#39;s new password, receiving a second request from the target system on behalf of the user for access to a sensitive resource, and denying the second request if the information about the user&#39;s password is not consistent with the user&#39;s stored new password. The second request contains information about the user&#39;s password. 
         [0013]    Another embodiment of the invention is directed to a system for preventing an administrator from impersonating a user of a target system, the system comprising: an access control system comprising a computer readable medium comprising instructions to execute the method of claim  1 , and the target system comprising sensitive data. User requests to the target system for sensitive resources are sent to the access control system for authentication. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0014]      FIG. 1  is a schematic view of one of many systems in which the invention might be implemented. 
           [0015]      FIG. 2  is a sequence diagram depicting operation of the invention for authorized and unauthorized users. 
       
    
    
     DESCRIPTION 
       [0016]    Referring to  FIG. 1 , a schematic view  100  of the components in a granular protection system of a database are shown. In this example, the central repository of the data is a relational database  102 . An example of such a database is OracleBe, available from Oracle Int&#39;l Corp of Redwood City, Calif. The data is stored in tables, which are interrelated with each other and the tables comprise columns and rows. The database  102  can also hold other information such as information about the structure of the tables, data types of the data elements, constraints on contents in columns, user data such as password, etc. 
         [0017]    The database  102  is operated through a database management system (DBMS)  104 . A DBMS  104  is imposed upon the data to form a logical and structured organization of the data. A DBMS  104  lies between the physical storage of data and the users  106  and handles the interaction between the two. Examples of DBMSes  104  include DB2® and Informix® both available from IBM Corp. of Armonk, N.Y.; Microsoft Jet® and Microsoft SQL Server® both available from the Microsoft Corp. of Redmond, Wash.; MySQL® available from the MySQL Ltd. Co. of Stockholm, Sweden; Oracle® Database, available from Oracle Int&#39;l Corp of Redwood City, Calif.; and Sybase® available from Sybase, Inc. of Dublin, Calif. 
         [0018]    A user  106  normally does not operate the DBMS  104  directly. Rather, the user  106  uses an application  108  which in turn operates with the DBMS  104 . Maintenance work is performed by a database administrator (DBA)  110 , who has direct access to the DBMS  104 . An administrator  110  is a role with certain privileges given to a person, i.e. a special kind of user. For instance, the privileges can include permissions to add new users  106  or read data, and normally the administrator  110  is allowed to unrestricted use of the database  102 . Thus, an administrator  110  is allowed to manipulate data, and manage users  106  and other operating tasks of a database  102 . A user  106 , in contrast to an administrator  110 , is normally only allowed to manipulate the actual data in the database  102 , and often only some of the data. Which data a user  106  can manipulate is regulated by the user&#39;s  106  permissions, which are set by the administrator  110 . 
         [0019]    In order to protect the data in the database  102 , an access control system (ACS)  112  interacts with the DBMS  104  in order to protect data from being exposed to users lacking the necessary rights. The access control system  112  (e.g., a Secure.Data™ and/or a DEFIANCE™ DPS, available from Protegrity Corp. of Stamford, Conn.) provides encryption and decryption of data, authentication of users  106  and means for a security administrator (SA)  114  to provide different users  106  or user groups with different privileges to access data. The SA  114  has the role of defining which users  106  have access to which data. 
         [0020]    Thus, a user  106  accesses the database  102  through an application  108 , which in turn uses the DBMS  104  to access the database  102 . During the access, the ACS  112  interacts in real time with the DBMS  104  to permit or deny the access attempt. But, a DBA  110  will always have access to the database  102  and/or DBMS  104 . In order to protect sensitive information from the DBA  110 , sensitive data is encrypted by the ACS  112 . But, there is risk that the DBA  110  would impersonate a user  106  in order to gain access to decrypted data. The invention described herein prevents the DBA  110  from impersonating a user  106  in order to gain access to encrypted data. 
         [0021]    The invention herein prevents the DBA  110  or other administrator from accessing sensitive resources, such as encrypted data, by comparing a user&#39;s  106  DBMS  104  password information with a stored DBMS  104  password for the user maintained by the ACS  112 . While the DBA  110  still has the power to make unauthorized changes to user&#39;s  106  password, the DBA  110  cannot leverage the now-compromised password to access encrypted information because the DBMS  104  will send password information to the ACS  112  when requesting decryption of the encrypted data. The ACS  112  will detect that the password information does not match the password stored by the ACS  112  and reject the request. 
         [0022]    While the database architecture as described in  FIG. 1  will be used throughout the application as an example, the invention described herein is in no way limited to database architectures. Rather, the invention herein may be applied to secure a variety of target systems including, but not limited to, databases, file systems (including file servers, network attached storage (NAS) devices, and storage area networks (SAN)), applications, networks, and data at rest systems. A “data at rest system” is defined broadly to include any system or device for storing and providing access to data and/or information, persistently or otherwise, now known or later developed. 
         [0023]    Referring now to  FIG. 2 , a sequence diagram illustrates an embodiment of the invention described herein. Vertical bars represent a user  106 , a DBA  110 , a DBMS  104 , and an ACS  112 . All bars are abstractions of the entities depicted. For example, while a user  106  may initiate a password change, the actual communication to the ACS  112  will likely be facilitated an application  108  by the user&#39;s  106  computer. 
         [0024]    The top half of Fig,  2  shows how an authorized password change is processed according to the invention herein. In step S 201 , the user  106  sends a change password request to the ACS  112 . In some embodiments, the ACS  112  may require that the user  106  is authenticated and/or authorized before proceeding to step S 202 . 
         [0025]    Authentication can be accomplished by examining one or more credentials from the following categories: something the user/client is (e.g. fingerprint or retinal pattern, DNA sequence, signature recognition, other biometric identifiers, or Media Access Control (MAC) address), something the user/client has (e.g. ED card, security token, or software token), and something the user/client knows (e.g. password, pass phrase, or personal identification number (PIN)). Authorization is a process of determining whether the authenticated user/client is allowed to view information or perform actions. The concepts of authentication and authorization are well known and thus not further described herein. 
         [0026]    In step S 202 , the ACS  112  changes the password on the DBMS  104 . The mechanics of changing the password are system specific, but familiar to programmers of a particular DBMS  104  or other system. For example, the ACS may execute an ALTER USER command in a SQL DBMS  104 . As another example, if the target system is a Linux box, the ACS  112  may use the command passwd to change a user&#39;s password. The ACS maintains a record of the user&#39;s  106  new login information. 
         [0027]    At step S 203 , the user logs in to the DBMS with their new password. At step S 204 , the user  106  accesses a sensitive resource. In this example, the sensitive resource is encrypted data, which the user  106  requests with a SELECT query. At step S 205 , the DBMS  104  communicates with the ACS  112  to authenticate the user  106 . The DBMS  104  transmits information about the user&#39;s  106  password to the ACS. The ACS  112  compares this information about the user&#39;s password to the password stored for the user  106 . If the information is consistent with the stored password, the user is authenticated. 
         [0028]    The amount of information about the user&#39;s  106  password transmitted in step S 205  may vary in different embodiments of the invention. The entire password may be transmitted, either in plain text or encrypted. Alternatively, a hash of the password may be transmitted. A hash function is a function h: U→{0,1,2, . . . ,N−1}, wherein U is an input (in this case a password). The hash function computes an integer N for every password U. In an efficient hash function (also known as collision-free), h will produce hash values N such that the number of passwords which produce the same hash value Nis low, if not zero. Hash functions are well known and are described further in Giles Brassard and Paul Bratley,  Fundamentals of Algorithms  160-61 (1996), and Bruce Schneier,  Applied Cryptography  30-31, 351-54 (2d ed. 1996), the contents of which are hereby incorporated herein by reference. A simple hash involves XORing the password with a known string. More sophisticated methods exist and are describe in Schneier. 
         [0029]    To verify the password, the DBMS  104  may communicate information about the password other than a hash. For example, the DBMS  104  may communicate the character in the password with the highest and/or lowest ASCII value, the sum of the ASCII values for each character in the password, the average ASCII value of each character in the password, the character/ASCII value of a defined character position in the password, and/or the length of the password. 
         [0030]    The ACS  112  informs the DBMS that user  106  is authenticated in step S 206 . In some embodiments, the ACS  112  also communicates encryption keys or de-encrypted data to the DBMS. In other embodiments, the ACS may verify authentication and/or provide encryption keys to encryption/de-encryption means such as those described in U.S. patent application serial number 11/644,106, filed on Dec. 21, 2006, the contents of which are hereby incorporated by reference herein. In step S 207 , the user  106  receives access to the sensitive resource, in this case, the decrypted data. 
         [0031]    The bottom half of  FIG. 2  shows how the invention herein protects against attempts by a DBA  110  to impersonate a user  106 . Note that in the bottom half of  FIG. 2 , the left column represents the DBA  110 , who masquerades as a user  106  after step S 208 . In step S 208 , the DBA  110  modifies the user&#39;s  106  password. This step includes any command and/or script to alter a user&#39;s  106  password on a system such as ALTER USER on a SQL DBMS  104  and passwd on a Linux system. 
         [0032]    In step S 209 , the DBA  110  uses the now-changed password to login to the DBMS  104  as a user  106 . In step S 210 , the DBA  110 , masquerading as a user  106 , requests access to a sensitive resource, in this example, encrypted data. The DBA  110  has access to the encrypted data by nature of the compromised password. However, the data is of little use to the DBA  110  because it is encrypted. In order to decrypt the data, the DBMS  104  communicates with the ACS  112  to authenticate the user  106  (step S 211 ). The DBMS  104  sends the user&#39;s  106  DBMS login and password to the ACS  112 . The ACS  112  detects that the user&#39;s  106  password does not match the stored password for the user  106  and alerts the DBMS  104  that the user  106  is not authenticated (step S 212 ). The request is accordingly denied by the DBMS  104  (step S 213 ). 
         [0033]    Accordingly, systems and methods for preventing an administrator from impersonating a user are provided. By incorporating accepted software engineering principles such as high coherence and low coupling, see, e.g., Bernd Bruegge &amp; Allen H. Dutuoit,  Object - Oriented Software Engineering §  6.3 (2000), the invention can be easily implemented with minimal changes to the DBMS  104  or ACS  112 . Moreover, the invention does not require the use of triggers when implemented in a DBMS  104 , and therefore is not vulnerable to a DBA  110  disabling the triggers that detect intrusions. The DBA  110  does not have access to the ACS  112  and therefore cannot gain meaningful access to sensitive resources unless the DBA  110  is authorized. 
         [0034]    The functions of several elements may, in alternative embodiments, be carried out by fewer elements, or a single element. Similarly, in some embodiments, any functional element may perform fewer, or different, operations than those described with respect to the illustrated embodiment. Also, functional elements (e.g., modules, databases, computers, clients, servers and the like) shown as distinct for purposes of illustration may be incorporated within other functional elements, separated in different hardware or distributed in a particular implementation. 
         [0035]    While certain embodiments according to the invention have been described, the invention is not limited to just the described embodiments. Various changes and/or modifications can be made to any of the described embodiments without departing from the spirit or scope of the invention. Also, various combinations of elements, steps, features, and/or aspects of the described embodiments are possible and contemplated even if such combinations are not expressly identified herein.