IP Library Granted Patent US 9,882,882
Granted Patent B2
US 9,882,882 · App. 15/268,454 · Granted Jan 30, 2018

Methods and systems of data security in browser storage

Inventor: Akhilesh Gupta (Mountain View, CA)
Assignee: salesforce.com, inc.
H04L63/0428G06F21/6227H04L9/0643H04L9/3213H04L63/08H04L63/083H04L63/0807H04L67/2814G06F2221/2107
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 9,882,882
App. No.
15/268,454
Granted
Jan 30, 2018
Kind
B2
Abstract

Mechanisms and methods are provided for managing OAuth access in a database network system, and extending the OAuth flow of authentication to securely store the OAuth encrypted refresh token in the storage available with current browsers or any other non-secure storage on user system.

Claims (39)

1. A non-transitory machine readable medium storing one or more machine instructions, which when invoked cause a processor to implement a method comprising:

at a server that includes at least a processor system having at least one processor and memory system, receiving a passcode and content, wherein the content comprises at least a refresh token;

in response to the receiving the passcode and the content, performing the following,

placing, by the server, the content and passcode into a file/blob;

creating, by the server, a unique encryption key;

encrypting, by the server, the file having the content and the passcode as a 1-way hash generated using a cryptographic hash function with the unique encryption key; and

sending from the server to the user system the encrypted data and a unique identifier for the encrypted file having the passcode and content.

2. The non-transitory machine readable medium of claim 1 , further comprising: storing the content and passcode that were encrypted in a local database at the server.

3. The non-transitory machine readable medium of claim 2 , the content being a token for refreshing an access to another server.

4. The non-transitory machine readable medium of claim 2 , the method further comprising:

sending the content from the server to another server; and

in response to the sending, receiving a token from the other server.

5. A non-transitory machine readable medium storing one or more machine instructions, which when invoked cause a processor to implement a method comprising:

receiving, at a server that includes at least a processor system having at least one processor and memory system, a passcode and encrypted content and a unique key identifier, wherein the content comprises at least a refresh token;

in response to the receiving, performing the following,

querying a local database for the encryption key based on the key identifier;

decrypting the encrypted content with the key;

determining whether the passcode stored previously within the content and the passcode provided by the user match one another; and

returning the decrypted content to the user if the passcode decrypted and the passcode provided by the user match one another;

wherein prior to the receiving of the encrypted passcode and encrypted content and the unique key identifier, receiving at the server, from a user device, the content and the passcode for encryption;

in response,

creating, by the server, a file;

placing, by the server, the passcode and content in the file,

generating, by the server, a unique encryption key and unique identifier of the key,

storing in a storage location of the memory system the unique encryption key in association with a unique identifier,

encrypting, by the server, the file in which the passcode and content were placed with the unique encryption key, therein creating the encrypted passcode and the encrypted content;

sending from the server to the user device the encrypted file and the unique key identifier for storage at the user device.

6. The non-transitory machine readable medium of claim 5 , the method further comprising creating a log of the receiving, of the encrypted passcode if the passcode decrypted and the passcode provided by the user do not match one another.

7. The non-transitory machine readable medium of claim 5 , the storing of the token and passcode, including at least storing the token and passcode, which were encrypted, in a database of a browser.

8. The non-transitory machine readable medium of claim 5 , the receiving of the token and the passcode including at least receiving an encrypted file containing the token and the passcode, the token and passcode being encrypted as a result of the file being encrypted.

9. The non-transitory machine readable medium of claim 5 , the method further comprising after sending the content and passcode for encryption, receiving a unique identifier identifying the encryption key and storing the unique identifier in a store area at the user device.

10. The non-transitory machine readable medium of claim 5 , the method further comprising after sending the content and passcode for encryption, receiving a unique identifier identifying the encryption key and storing the unique identifier in a store area associated with the browser at the user device.

11. The non-transitory machine readable medium of claim 5 , further comprising:

receiving at the user system the content prior to sending the content.

12. The non-transitory machine readable medium of claim 5 , the method further comprising:

after the user logs in and prior to sending the passcode and the content to the server, receiving at the user system a request to enter the passcode for the content.

13. The non-transitory machine readable medium of claim 5 , the method further comprising:

sending from the user device, to the server, an encrypted passcode, encrypted content, and a unique key identifier; and

in response, receiving at the user device, from the server, the decrypted content to the user if the passcode decrypted and the passcode provided by the user match one another.

Assignments (2)
CHANGE OF NAME Recorded Nov 21, 2024
From: SALESFORCE.COM, INC.
To: SALESFORCE, INC.
Reel/Frame 069431/0156 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Oct 11, 2016
From: GUPTA, AKHILESH
To: SALESFORCE.COM, INC.
Reel/Frame 039983/0781 →
Continuity (5)
Continuation 14856371 · Sep 16, 2015
Continuation 14622812 · Feb 13, 2015
Continuation 13433067 · Mar 28, 2012
Provisional Application 61528462 · Aug 29, 2011
Related Publication 20170005998A1 · Jan 5, 2017