Password Encryption Key
A password-encrypted key (PEK) is generated from a user-supplied password or other identifying data and then used to encrypt the user's password. The encrypted password is stored in a user record on a server. At login a would-be user's password is again used to make a key, which is then used to decrypt and compare the stored encrypted password with the would-be user's password to complete the login. The successful PEK is stored in a temporary session record and can be used to decrypt other sensitive user information previously encrypted and stored in the user record as well as to encrypt new information for storage in the user record. A public/private key system can also be used to maintain limited access for the host to certain information in the user record.
This application claims priority under 35 USC 119(e) to U.S. Patent Application Serial No. 60/421,284 filed on Oct. 25, 2002, the entire contents of which are hereby incorporated by reference.
TECHNICAL FIELDThis invention relates to eSecurity and more particularly to user authentication.
BACKGROUNDA frequently neglected aspect of the modem enterprise data storage is sensitive user information security. The most widespread approach used today is encryption of such user information as Social Security number, credit card numbers, e-mails, etc. with a single key and storage of the resulting encrypted data in the database. The logic behind such solution is that a malicious individual who gains access to the database will be unable to make use of the user's sensitive data because it is encrypted.
Unfortunately, this approach provides a false sense of security in most cases. The problem is that the encryption key used to encrypt all records still needs to be stored somewhere in the system. For example, as soon as the system is required to send e-mail to the user or submit user's credit card number to the merchant account, the server(s) responsible for fulfilling that requirement must use the key to decrypt user information retrieved from the database. Chances are that if a malicious individual manages to get access to the database, which is usually the most protected part of the system, he will then be able to gain access to the aforementioned server. As soon as this happens, such malicious individual will be able to obtain the key and decrypt every database record encrypted with this key.
SUMMARYA password-encrypted key (PEK) is generated from a user-supplied password, for example, and then used to encrypt the user's password. The encrypted password is stored in a user record on a server. At login, a would-be user's password is again used to make a key, which is then used to decrypt and compare the stored encrypted password with the would-be user's password to complete the login. The successful PEK is stored in a temporary session record and can be used to decrypt other sensitive user information previously encrypted and stored in the user record as well as to encrypt new information for storage in the user record. A public/private key system can also be used to maintain limited access for the host to certain information in the user record.
According to one aspect of the invention, a secure transaction process includes generating a key from a user-supplied unencrypted password or other identifying data, encrypting the user's password with the key, creating a user record and storing the encrypted password in the user record. In another aspect of the invention, upon user login, a key is made from a would-be user's password using the same algorithm used to generate the key from the originally supplied unencrypted password, then the encrypted password in the corresponding user record is retrieved and decrypted using the key and the decrypted password and the would-be user-supplied password are compared to see if they match.
In the preferred process, if the decrypted password and user-supplied password match, a temporary session record is created and the key is stored in the session record. In the absence of a match, the user login procedure for secure or user-authenticated transactions at least would preferably be aborted or terminated in some fashion.
The key may be used to encrypt other sensitive user data, which can be stored in the user record. During a session in which a session record has been created, the key stored in the session record can be used to decrypt the other encrypted information stored in the user record for use in carrying out some desired action.
Alternatively, a public/private key pair or other asymmetric cryptography can be employed. A public/private key pair is generated and the public key is stored on an application server and the mating private key only on another server, preferably a secure off-site server. The original user-supplied unencrypted password is then encrypted with the public key and stored on the application server. Subsequently, the private key can be fetched from the other server and used to decrypt selected information on the one server, for example, for a mass mailing. A single public/private key can support the entire site.
The password encryption key (PEK) system of the present invention eliminates one of the shortcomings of prior methods by using a unique encryption key for each user record. This key is based on at least one piece of data—user password. Optionally, user name (or user ID) can be used in conjunction with user password. User's password (and name) is obtained at each successful user login and is maintained by the system for the duration of that user's session.
The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims.
The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims.
PEK Integration into the System
The PEK system is illustrated as a sequence of processes as shown in
a. User registers by, at least, providing new username and an arbitrary password.
b. Generate a key from the password. (and optionally username/ID). A key can be generated by calculating an MD5 checksum of the source data.
c. Encrypt user password with the key obtained at step 1b. Note: other sensitive data provided during registration (i.e. e-mail address) should also be encrypted with the same key.
d. Create new user record (
a. User logs in providing username/password for authentication.
b. Generate a key from the password (and optionally username/ID). This key should be identical to the key obtained at step 1b.
c. Retrieve user record by username and decrypt user password using the key obtained at step 2b.
d. Compare the decrypted password to the one provided by user at step 2a.
e. Reject user login if passwords do not match. Abort login process.
f. If passwords match, create a temporary user session record (
g. Store resulting key in the session.
h. Communicate session ID back to the user (client application). Session ID is a number or string uniquely identifying the session. Once user (client application) receives the session ID from the system, user will always provide that ID with each subsequent request for the duration of the session. This enables the system to get access to user session data at each request.
3. Sensitive Information Storage (FIG. 5)a. User submits some sensitive data (i.e. Credit Card number).
b. Encrypt sensitive data with a key retrieved from user's session.
c. Store encrypted data in user's record if it is to be permanently maintained on the server. If it is only to be available for the session then the encrypted data would be stored only temporarily in the session record.
4. Sensitive Information Retrieval (FIG. 6)a. User requests some system action requiring use of the information stored at step 3. (i.e. user decides to make a purchase with the credit card that he/she previously submitted to the system).
b. Retrieve a key (i.e., the PEK) from the user's session record (
c. Decrypt the necessary data using the key obtained at step 4b.
d. Perform the required action with decrypted data (i.e. send it to the merchant account)
e. Discard decrypted data.
ImplicationsThe system, at user's request, can decrypt data stored in the database at step 3 (
Thus, a user's sensitive data will always be as secure as the user's password in this system. In the majority of cases, this should be acceptable since knowledge of password only gives access to sensitive user account information through the standard interface anyway.
Potential Vulnerabilities and SolutionsWhile PEK offers a secure way of protecting user data for users that are not currently logged in, in theory, it could be possible for a malicious individual to gain access to sensitive data for users that are currently logged in (i.e. have active sessions going). Such individual would have to obtain all of the encrypted user data and all of the active sessions data, extract a key from each session, and decrypt the active user's sensitive data by applying extracted keys to corresponding user records.
Logged in users, however, in most cases, represent only a small subset of all registered users and that alone greatly limits the scope of potential risks. In addition, the exposure can be further limited by making sure that the information linking session to a specific user, like username/ID, is not stored in session data. Instead, this information can be provided by the client application with each user's request. That alone would make it exceedingly difficult for a malicious individual to match a key, retrieved from any given session, to a specific user record.
Other ConsiderationsPEK makes it difficult to perform legitimate system functions that involve access to sensitive user data without an explicit user request. Bulk mailing to all system users is a good example. Suppose that user e-mails or at least e-mail addresses are encrypted using PEK. It will then be impossible for the system to decrypt user e-mails because each e-mail is encrypted with its owner's password and that password itself is also encrypted.
One solution to this problem is to utilize asymmetric cryptography, like PGP, and keep a copy of the user's password, encrypted with a public key, in the main database, as shown in
Another approach is to use the public key to directly encrypt only those user record fields that require bulk access. Distinct public/private key pairs can be used to encrypt different field types (i.e. e-mails and Credit Card numbers). This would allow, for a more refined access permissions control. For example, bulk mail server will only have a private key that decrypts e-mails, but not Credit Card numbers.
Finally, yet another approach could be to push unencrypted data to the off-site server at the time of its submission by user. This is the least secure approach but it allows the most flexibility.
A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. For example, instead of MD5 checksum, some other encryption algorithm or reproducible key-making methodology could be used. Accordingly, other embodiments are within the scope of the following claims.
Claims
1. A secure transaction process, comprising
- generating a key from a user-supplied unencrypted password,
- encrypting the user's password with the key,
- creating a user record,
- storing the encrypted password in the user record.
2. The process of claim 1, further comprising
- upon user login, generating a key from a would-be user's password using the same algorithm used to generate the key from the originally supplied unencrypted password,
- retrieving the corresponding user record,
- decrypting the encrypted password in the user record using the key,
- comparing the decrypted password with the would-be user-supplied password to see if they match.
3. The process of claim 2, further comprising
- if the decrypted password and user-supplied password match, creating a temporary session record and storing the key in the session record, otherwise aborting the user login.
4. The process of claim 3, further comprising
- encrypting other sensitive user data using the key and storing the encrypted data in the user record,
- during a session wherein a session record has been created, using the key stored in the session record to decrypt other encrypted information stored in the user record for use in carrying out some desired action.
5. The process of claim 1, further comprising
- generating a public/private key pair,
- storing the public key on an application server and the mating private key only another server,
- encrypting the original user-supplied unencrypted password with the public key and
- storing the public-key encrypted password on the application server,
- fetching the private key from the other server and using it to decrypt selected information on the one server.
6. The process of claim 5, further wherein the other server is a secure off-site server.
7. A secure transaction process, comprising
- generating an encryption key from user-supplied identification data,
- encrypting the user's identification data with the key,
- creating a user record,
- storing the encrypted identification data in the user record.
8. The process of claim 7, further comprising
- upon user login, generating a key from a would-be user's identification data supplied at login using the same algorithm used to generate the key from the originally supplied unencrypted identification data,
- retrieving the corresponding user record,
- decrypting the encrypted identification data in the user record using the key,
- comparing the decrypted identification data with the would-be user-supplied identification data to see if they match.
9. The process of claim 8, further comprising
- if the decrypted identification data and user-supplied identification data match, creating a temporary session record and storing the key in the session record, otherwise aborting the user login.
10. The process of claim 9, further comprising
- encrypting other sensitive user data using the key and storing the encrypted data in the user record,
- during a session wherein a session record has been created, using the key stored in the session record to decrypt other encrypted information stored in the user record for use in carrying out some desired action.
Type: Application
Filed: Mar 21, 2016
Publication Date: Jul 14, 2016
Inventor: Daniil Utin (Newton, MA)
Application Number: 15/075,548