Abstract:
The present system and method allow for preemptive, self-healing computer security. The system includes a user device processor and a PSS server processor. The two processors perform an initial Data Structure &amp; Key Mutation (DSKM) method and an interval DSKM method at a given interval to protect secret information and prevent its exposure by attackers. When a user requests a site or service that is an attractive target for attackers, such as a bank site or monetary transfer service, the processors perform a Man in the Browser attack prevention method. When a packet is received or generated, the processors perform a Deep Protocol and Stateful Inspection and Prevention method to prevent receipt of malicious packets or the loss of sensitive information. Various forensics modules allow accurate forensic examination of the type, scope, and method of attack, as well as real-time protection of cloud-based services.

Description:
CROSS-REFERENCE TO RELATED APPLICATION(S) 
       [0001]    The present application claims priority of U.S. Provisional Patent Application No. 62/332,105, filed on May 5, 2016, the content of which is incorporated herein by reference in its entirety. 
     
    
     FIELD 
       [0002]    The present disclosure is directed to wireless communication networks, and more specifically to security arrangements for access and authorization security and fraud detection. 
       BACKGROUND 
       [0003]    As the world moves further into the mobile information age, the need to securely connect to wireless communication networks, which are the access networks to the Internet infrastructure, is increasing dramatically. More and more customers like to shop online, pay bills, and even manage their bank accounts using free, convenient public Wi-Fi. Public locations, such as stores and airports, make Wi-Fi available for customers and other members of the public as a matter of course. 
         [0004]    However, the current wireless media environment is not secure enough for sensitive information such as passwords. An attacker can easily set up Rogue Access Points (APs) to take advantage of public Wi-Fi. Rogue APs are critical threats in the information infrastructure. Once a user&#39;s devices connect to Rogue APs, the attacker can exploit the Rogue AP as a bridgehead to launch multiple stage attacks. 
         [0005]    For example, the attacker can use Domain Name System Spoofing to redirect a user to some malicious website, and then download malware to that user&#39;s device. Such malware can include keyloggers that record the user&#39;s keystrokes. Attackers can steal cookies or authentication tokens from a user&#39;s browser. Man in the Browser (MitB) attacks can modify an authentic login page to require the user to provide more identifying information, such as a social security number, which is then forwarded to the attacker. Man in the Middle (MitM) attacks can capture sensitive data, such as passwords, in transit. MitM attacks may extend to a wired environment such as wired access networks (e.g., cable modems.) 
         [0006]    Traditional defense methods such as signature- and statistics-based intrusion detection and prevention systems are inadequate in defending against Rogue APs. There is an unmet need for a system capable of protecting against Rogue APs and conducting forensic reviews of attempted attacks to strengthen system protection. 
       SUMMARY 
       [0007]    An exemplary embodiment of the present application is a method for preemptive, self-healing computer security. The method performs an initial Data Structure &amp; Key Mutation (DSKM) method, then performs an interval DSKM method at a given interval. The method performs a Man in the Browser (MitB) attack prevention method when a user requests a predetermined site and performs a Deep Protocol and Stateful Inspection and Prevention (DPSI) method when a packet is received or generated. 
         [0008]    Another exemplary embodiment of the present application is a method for preemptive, self-healing computer security. In addition to the above-mentioned method, this method performs a forensics method and performs the interval DSKM method if the forensics method declares any secrets compromised. 
         [0009]    Another exemplary embodiment of the present application is a system for preemptive, self-healing computer security. The system includes a user device processor and a PSS server processor. The system also includes a non-transient computer readable medium operatively connected to the user device processor and the PSS server processor. This medium is programmed with computer readable code that upon execution by the user device processor and the PSS server processor causes the user device processor and the PSS server processor to execute the above-mentioned method for preemptive, self-healing computer security. The system also includes a relational database stored on a PSS server. The relational database includes a user pseudo-ID (PID) table, a user device PID table, a login table, a state table, and a tab log table. 
         [0010]    The objects and advantages will appear more fully from the following detailed description made in conjunction with the accompanying drawings. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWING(S) 
         [0011]      FIG. 1  is a flowchart depicting an exemplary embodiment of a method for preemptive, self-healing computer security. 
           [0012]      FIG. 2  is a flowchart depicting an exemplary embodiment of a method for initial Data Structure &amp; Key Mutation (DSKM). 
           [0013]      FIG. 3  is a flowchart depicting an exemplary embodiment of a method for interval DSKM. 
           [0014]      FIG. 4  is a flowchart depicting an exemplary embodiment of a method for Man in the Browser (MitB) attack prevention. 
           [0015]      FIG. 5  is a flowchart depicting an exemplary embodiment of a method for Deep Protocol and Stateful Inspection and Prevention (DPSI). 
           [0016]      FIG. 6  is a flowchart depicting an exemplary embodiment of a method for logging a state. 
           [0017]      FIGS. 7 a  and 7 b    are a flowchart depicting an exemplary embodiment of a method for keylogger prevention. 
           [0018]      FIG. 8  is a flowchart depicting an exemplary embodiment of a method for MitM attack detection. 
           [0019]      FIG. 9  is a flowchart depicting an exemplary embodiment of a method for MitB attack detection. 
           [0020]      FIG. 10  is a flowchart depicting an exemplary embodiment of a method for primary checking of a packet. 
           [0021]      FIG. 11  is a flowchart depicting an exemplary embodiment of a method for further checking of a packet. 
           [0022]      FIG. 12  is a flowchart depicting an exemplary embodiment of a method for keylogger forensics. 
           [0023]      FIG. 13 a    is a system flowchart depicting the movement of information during an exemplary embodiment of a method for retrieving a cookie. 
           [0024]      FIG. 13 b    is a flowchart depicting an exemplary embodiment of a method for cookie forensics. 
           [0025]      FIG. 14  is a flowchart depicting an exemplary embodiment of a method for retrieving a third PSS table AES-GCM key K PT3DG . 
           [0026]      FIG. 15  is a system diagram of an exemplary embodiment of a system for preemptive, self-healing computer security. 
           [0027]      FIG. 16  is a flowchart depicting an exemplary embodiment of a method for memory scraping forensics. 
           [0028]      FIG. 17  is a flowchart depicting an exemplary embodiment of a method for real-time forensics. 
           [0029]      FIGS. 18 a  and 18 b    depict the log table and the state table, respectively, for a sample CSRF attack. 
       
    
    
     DETAILED DESCRIPTION 
       [0030]    In the present description, certain terms have been used for brevity, clearness and understanding. No unnecessary limitations are to be applied therefrom beyond the requirement of the prior art because such terms are used for descriptive purposes only and are intended to be broadly construed. The different systems and methods described herein may be used alone or in combination with other systems and methods. Various equivalents, alternatives and modifications are possible within the scope of the appended claims. Each limitation in the appended claims is intended to invoke interpretation under 35 U.S.C. §112, sixth paragraph, only if the terms “means for” or “step for” are explicitly recited in the respective limitation. 
         [0031]      FIG. 1  is a flowchart depicting an exemplary embodiment of method  100  for preemptive, self-healing computer security. 
         [0032]    In step  102 , method  100  performs an initial Data Structure &amp; Key Mutation (DSKM) method  200 . 
         [0033]    In step  104 , method  100  performs an interval DSKM method  300  at a given interval. The given interval may be a predetermined interval or an interval between a previous instance of performing interval DSKM method  300  and the user logging in. This ensures that not only is interval DSKM method  300  performed every time a user logs in, interval DSKM method  300  is also performed periodically without user login, ensuring that if an attacker somehow manages to penetrate security, they will not be able to exploit the breach for long. 
         [0034]    In step  106 , method  100  performs a Man in the Browser (MitB) attack prevention method  400 . Step  106  is performed when a user requests a predetermined site. This predetermined site is selected from a list of “important” sites, sites for which a security breach can cause significant financial or security hardship, such as banking or account payment sites. 
         [0035]    In step  108 , method  100  performs a Deep Protocol and Stateful Inspection and Prevention (DPSI) method  500 . Step  108  is performed when a packet is received or generated to prevent the receipt of altered or potentially malicious packets, or to prevent the transmission of secret information. 
         [0036]      FIG. 2  is a flowchart depicting an exemplary embodiment of method  200  for initial Data Structure &amp; Key Mutation (DSKM). DSKM constantly mutates not only the data structures (tables), but also the keys used to encrypt the tables. In this way, DSKM method  200  provides extremely security storage for critical secrets, regardless of whether any partial table or single device is compromised. Mutual support of different tables allows identification of lost or stolen credentials. Separation of authentication secrets in multiple tables also allows different strategies for protection of different tables. 
         [0037]    In step  202 , method  200  stores multiple client secrets on at least one of a plurality of user device tables. The user device tables include at least a first user device table, a second user device table, a third user device table, and a fourth user device table. 
         [0038]    In the exemplary embodiment, the first user device table stores a user PID, a user device pseudo-ID (PID), a PSS server PID, a user ID, a user device ID, a user device salt, a server pseudo-random number string, a login trial number, a user device DoS secret, and a PSS server DoS secret. The user PID is a 256-bit string generated for the user every session. The user device PID is a 256-bit string generated for the user device every session. The PSS server PID is a 256-bit string generated in the PSS server for each user device every session. The user ID is a unique 64-bit string generated for the user during registration. The user device ID is a unique 64-bit string generated for the user device during registration. The user device salt is a 256-bit random string generated for the user device during registration. The server pseudo-random number string is generated from a server salt. The login trial number is a 32-bit string started from a nonce and increased by 1 after each login. The user device denial-of-service (DoS) secret is generated by the user device to provide distributed denial-of-service (DDoS) prevention for the PSS server and is updated every session. The PSS server DoS secret is generated by the PSS server to provide DDoS prevention for the user device and is updated every session. 
         [0039]    In the exemplary embodiment, the second user device table stores a user device next session key, a PSS server next session key, a user device nonce, a key seed for the user device, a user device index, a session number, a user secret, a user device authenticator, and a secondary PSS server authenticator. The user device next session key is generated by the user device and used to encrypt some variable in the packet for session login. The PSS server next session key is generated by the PSS server and used to encrypt some variable in the packet for session login. The user device nonce is generated by the user device and updated every session. The key seed for the user device is used to generate the user device next session key and updated every session. The user device index is a searching key of the third PSS server table, generated by the user device and updated every session. The session number is a 64-bit string, started from a nonce and increased by 1 after each session login. The user secret is a 256-bit string generated by the user device during registration. The user device authenticator is generated by the user device and used to authenticate the user device. The secondary PSS server authenticator is generated by the PSS server from a PSS server authenticator, sent to the user device, and used to authenticate the PSS server. 
         [0040]    In the exemplary embodiment, the third user device table stores the cookie PID and an encrypted cookie. The cookie PID is a 256-bit string generated in the PSS server for each cookie. The cookie PID is a pseudo-random number generated from the domain name of the URL, the cookie name, and the cookie nonce. 
         [0041]    In the exemplary embodiment, the fourth user device table stores a state PID, a domain name, a cookie, an actor&#39;s role, whether the packet contains sensitive information, whether there is an Adobe cross-domain policy file, the current state, the tab ID, and the cookie PID. The state PID is generated by the user PID, the user device PID, and the tab ID. The domain name includes the requesting domain name and the destination domain name. The cookie includes a cookie name and a cookie nonce, a random string generated by the user device for each cookie and used to retrieve the cookie from the third user device table. The actor&#39;s role includes the domain name of the URL entered on the user device, and presents the current website&#39;s role in the communication such as relying party, identity provider, client, and server. The type of sensitive information present can include, but is not limited to, password, financial, transactional, or identifying information. The current state is the current state of the corresponding session. The tab ID is the hash index of the log table. 
         [0042]    In step  204 , method  200  stores multiple network secrets on at least one of a plurality of PSS tables. The PSS tables include at least a first PSS table, a second PSS table, a third PSS table, and a fourth PSS table. 
         [0043]    In the exemplary embodiment, the first PSS server table stores the PSS server PID, a PSS server ID, the user PID, the user device PID, a PSS server salt, a device pseudo-random number string, a PSS server nonce, a key seed, the login trial number, a user device DoS secret, a PSS server DoS secret, and a server device index. The PSS server ID is a unique 64-bit string generated for the PSS server during establishment. The PSS server salt is a 256-bit random string, generated for the PSS server during registration. The device pseudo-random number string is generated from a user device salt. The PSS server nonce is generated by the PSS server and updated every session. The key seed for the PSS server is generated by the PSS server and updated every session. The server device index is a searching key of the second PSS server table, generated by the PSS server and updated every session. 
         [0044]    In the exemplary embodiment, the second PSS server table stores the server device index, a PSS secret for the user device, the user device next session key, a map for K PT3DG , and the user ID. The server secret for the user device is a 256-bit string generated by the PSS server for the user device during registration. The map for K PT3DG  contains the pointers to each piece of encrypted K PT3DG  and is updated every session. 
         [0045]    In the exemplary embodiment, the third PSS server table stores the user device index, the session number, the secondary user device authenticator, and the PSS server authenticator. The secondary user device authenticator is generated by the user device from the user device authenticator, sent to the PSS server, and used to authenticate the user device. The PSS server authenticator is generated by the PSS server and used to authenticate the PSS server. In the exemplary embodiment, the fourth PSS server table stores the same information as the fourth user device table. 
         [0046]    In step  206 , method  200  encrypts the first user device table with a first device table Advanced Encryption Standard Galois/Counter Mode (AES-GCM) key K DT1 . 
         [0047]    In step  208 , method  200  encrypts the second user device table with a second device table AES-GCM key K DT2 . 
         [0048]    In step  210 , method  200  encrypts the third user device table with a third device table AES-GCM key K DT3 . 
         [0049]    In step  212 , method  200  encrypts the fourth user device table with a user device high-speed cipher key. In the certain embodiments, the user device high-speed cipher key is a ChaCha key. In the exemplary embodiment, the user device high-speed cipher key is a self-evolving ChaCha key, i.e. a ChaCha key generated using a previously generated ChaCha key. 
         [0050]    In step  214 , method  200  divides network secrets on the first PSS table, the third PSS table, and the fourth PSS table into multiple groups in each table based on at least one secret stored in the PSS tables. By way of non-limiting example, such a secret may be the user PID. 
         [0051]    In step  216 , method  200  encrypts the i groups in the first PSS table with 1-i first PSS table AES-GCM keys K PT1DGi . Each K PT1DGi  encrypts one group in the first PSS table. In certain embodiments, each AES-GCM key for each group in each table is encrypted by a two-layer high-speed cipher key, wherein each layer of the two-layer high-speed cipher key alternately updates. In the certain embodiments, the two-layer high-speed cipher key is a ChaCha key. 
         [0052]    In step  218 , method  200  encrypts the first part of the second PSS table with a first partial second PSS table AES-GCM key K PT2D . In the exemplary embodiment, the first part of the second PSS server table includes the PSS secret for the user device and the user ID. 
         [0053]    In step  220 , method  200  encrypts the second part of the second PSS table with a second partial second PSS table AES-GCM key K PT2SD . In the exemplary embodiment, the second part of the second PSS server table includes the user device next session key and the map for K PT3DG . 
         [0054]    In step  222 , method  200  encrypts the k groups in the third PSS table with 1-k third PSS table AES-GCM keys K PT3DGk . Each K PT3DGk  encrypts one group in the first PSS table. 
         [0055]    In step  224 , method  200  encrypts the fourth PSS table with a PSS high-speed cipher key. In the certain embodiments, the PSS high-speed cipher key is a ChaCha key. In the exemplary embodiment, the PSS high-speed cipher key is a self-evolving ChaCha key. 
         [0056]      FIG. 3  is a flowchart depicting an exemplary embodiment of method  300  for interval DSKM. Interval DSKM method  300  varies from initial DSKM method  200  in that method  300  is performed periodically without user login, through a simulated login. This simulated login causes a mutation of the tables and keys at periodic intervals, ensuring that if an attacker somehow manages to penetrate security, they will not be able to exploit the breach for long. If a forensics method discovers any compromised secrets, performing interval DSKM method  300  will alter multiple secrets and change the locations of certain secrets, healing the breach and preventing an attacker from exploiting the compromised secret for long. 
         [0057]    In step  302 , method  300  shuffles at least one cookie to a random location in the third user device table. 
         [0058]    In step  304 , method  300  updates the at least one secret stored in the PSS tables. 
         [0059]    In step  306 , method  300  divides the network secrets on the first PSS table, the third PSS table, and the fourth PSS table into multiple groups in each table based on the user PID currently in the first PSS table. The groups and positions within groups that secrets are assigned to may be different from those assigned in step  214  of method  200 . 
         [0060]    In step  308 , method  300  generates a new K PT2D , and a new K PT2SD . 
         [0061]    In step  310 , method  300  reencrypts the i groups in the first PSS table with the 1-i K PT1DGi , reencrypts the first part of the second PSS table with the new K PT2D , reencrypts the second part of the second PSS table with the new K PT2SD , and reencrypts the k groups in the third PSS table with the 1-k K PT3DGk . 
         [0062]      FIG. 4  is a flowchart depicting an exemplary embodiment of method  400  for Man in the Browser (MitB) attack prevention. 
         [0063]    In step  402 , method  400  updates an encryption box key K EB . 
         [0064]    In step  404 , method  400  updates a Hyper Text Transfer Protocol Secure (HTTPS) session key K HS . 
         [0065]    In step  406 , method  400  transmits the K HS  from a user device to a PSS server. 
         [0066]    In step  408 , method  400  transmits a request encrypted by the K HS  from the user device to a third-party website. 
         [0067]    In step  410 , method  400  transmits a response including multiple input boxes from the third-party website to the PSS server. 
         [0068]    In step  412 , method  400  encrypts each of the input boxes with the K EB . 
         [0069]    In step  414 , method  400  transmits each of the input boxes from the PSS server to the user device. 
         [0070]    In step  416 , method  400  verifies and displays one of the input boxes on the user device. 
         [0071]    In step  418 , method  400  receives user input in one of the input boxes. 
         [0072]    In step  420 , method  400  encrypts the user input with the K EB . 
         [0073]    In step  422 , method  400  repeats steps  416  through  420  until each of the plurality of input boxes has received user input. 
         [0074]    In step  424 , method  400  transmits the encrypted user input from the user device to the PSS server. 
         [0075]    In step  426 , method  400  decrypts and verifies the user input. 
         [0076]    In step  428 , method  400  transmits the user input to the third-party website. 
         [0077]      FIG. 5  is a flowchart depicting an exemplary embodiment of method  500  for DPSI. 
         [0078]    In step  502 , method  500  receives the packet. 
         [0079]    In step  504 , method  500  performs packet log method  600 . 
         [0080]    In step  506 , method  500  performs keylogger prevention method  700 . 
         [0081]    In step  508 , method  500  performs MitM attack detection method  800  if the packet passes the keylogger prevention method  700  in step  506 . 
         [0082]    In step  510 , method  500  performs MitB attack detection method  900  if the packet passes the MitM attack detection method  800  in step  508 . 
         [0083]    In step  512 , method  500  performs primary check method  1000  if the packet passes the MitB attack detection method  900  in step  510 . 
         [0084]    In optional step  514 , method  500  performs further check method  1100  if the packet does not pass primary check method  1000  in step  512 . 
         [0085]    In optional step  516 , method  500  passes the packet if the packet passes methods  700 ,  800 ,  900 , and  1000 . 
         [0086]    In optional step  518 , method  500  performs real-time forensics method  1700  and enters a warning state if the packet does not pass even one of methods  700 ,  800 ,  900 , or  1000 . 
         [0087]    In optional step  520 , method  500  requests additional information in the warning state. 
         [0088]    In optional step  522 , method  500  passes the packet if the packet passes the warning state. 
         [0089]    In optional step  524 , method  500  performs a forensics method (keylogger forensics method  1200 , cookie forensics method  1350 , memory scraping forensics  1600 , or real-time forensics  1700 ) if the packet does not pass the warning state. 
         [0090]    In optional step  526 , method  500  blocks and drops the packet. 
         [0091]      FIG. 6  is a flowchart depicting an exemplary embodiment of method  600  for logging a packet. 
         [0092]    In step  602 , method  600  logs the packet information as a new entry in a tab log table of a relational database. 
         [0093]    In optional step  604 , method  600  logs if the packet is generated without at least one open browser tab. 
         [0094]    In optional step  606 , method  600  logs if the packet contains a link from an email or a website. 
         [0095]    In optional step  608 , method  600  logs if the packet is generated by or a response to an external source. External sources may include, but are not limited to, an iframe or an image. 
         [0096]    In optional step  610 , method  600  logs if the packet is a request generated by a JavaScript or a related response. 
         [0097]    In optional step  612 , method  600  logs if the packet is generated by an invisible form or a hidden element in a visible form. 
         [0098]      FIGS. 7 a  and 7 b    are a flowchart depicting an exemplary embodiment of method  700  for keylogger prevention. Method  700  describes the backend procedure executed by a processor in a system. From the frontend, that is, a user&#39;s perspective, once a user moves their cursor to a protected input box displayed on the user device and inputs part of their password, the user device shows part of the one-time password (OTP) as an image for a limited time. The user inputs the visible portion of the OTP and begins to enter their password again. The user device continues to show parts of the OTP and require their input until the user has entered the entire OTP and their password. The OTP is shown as image and only displays for a few seconds for security. In this way, even if malware on the user device can take screenshots, it is extremely hard to capture all parts of the OTP, since the timing of OTP part appearances is random and only lasts for a brief time. 
         [0099]    In step  702 , method  700  requests a OTP from a third-party website. 
         [0100]    In step  704 , method  700  generates a keylogger prevention key K KL  and a shuffle key K SF  on a PSS server. 
         [0101]    In step  706 , method  700  stores a hash-encrypted K KL  on the PSS server. 
         [0102]    In step  708 , method  700  sends an encrypted K KL  and an encrypted K SF  from the PSS server to the user device. 
         [0103]    In step  710 , method  700  decrypts and verifies the K KL  and the K SF  on the user device. 
         [0104]    In step  712 , method  700  reencrypts the K KL  with a new logger prevention key the K KLC  on the user device. 
         [0105]    In step  714 , method  700  splits the K KLC  into a plurality of OTPs on the user device. 
         [0106]    In step  716 , method  700  displays the plurality of OTPs as a plurality of images on the user device. 
         [0107]    In step  718 , method  700  receives the plurality of OTPs and a password (PW) on the user device. 
         [0108]    In step  720 , method  700  generates a half of the PW shuffled with the K KLC , a half of the PW shuffled with half of the K SF , and the K KLC  shuffled with half of the K SF  on the user device. 
         [0109]    In step  722 , method  700  recovers half of the PW using the half of the PW shuffled with the K KLC  on the user device. 
         [0110]    In step  724 , method  700  transmits the recovered half PW, the half of the PW shuffled with half of the K SF , the K KLC  shuffled with half of the K SF , and the K KL  encrypted with the K KLC  from the user device to the PSS server. 
         [0111]    In step  726 , method  700  recovers another half of the PW using the half of the PW shuffled with half of the K SF  on the PSS server. 
         [0112]    In step  728 , method  700  retrieves the K KLC  using the K KLC  shuffled with half of the K SF  on the PSS server. 
         [0113]    In step  730 , method  700  decrypts the K KL  encrypted with the K KLC  using the K KLC  on the PSS server. 
         [0114]    In step  732 , method  700  verifies the K KL  with the hash-encrypted K KL  on the PSS server. 
         [0115]    In step  734 , method  700  generates a hash-encoded PW based on the received half of the PW and the recovered half of the PW on the PSS server. 
         [0116]    In step  736 , method  700  transmits the hash-encoded PW from the PSS server to the third-party website. 
         [0117]      FIG. 8  is a flowchart depicting an exemplary embodiment of method  800  for MitM attack detection. 
         [0118]    In step  802 , method  800  determines whether a destination address for a packet matches a destination domain on a PSS server. 
         [0119]    In optional step  804 , method  800  enters a warning state if the destination address does not match the destination domain. 
         [0120]      FIG. 9  is a flowchart depicting an exemplary embodiment of method  900  for MitB attack detection. 
         [0121]    In step  902 , method  900  updates a HTTP session key K HS . 
         [0122]    In step  904 , method  900  transmits the K HS  from a user device to a PSS server. 
         [0123]    In step  906 , method  900  transmits a request encrypted by the K HS  from a user device to a third-party website. 
         [0124]    In step  908 , method  900  transmits a packet from the third-party website to the PSS server. 
         [0125]    In step  910 , method  900  generates a first server keyed-hash message authentication code HMAC_S1 value for the packet. 
         [0126]    In step  912 , method  900  transmits the packet to the user device. 
         [0127]    In step  914 , method  900  displays the third-party website on the user device. 
         [0128]    In step  916 , method  900  generates a first client keyed-hash message authentication code HMAC_C1 for a packet without user input. 
         [0129]    In step  918 , method  900  generates a second client keyed-hash message authentication code HMAC_C2 for a packet containing user input. 
         [0130]    In step  920 , method  900  transmits the packet without user input and the packet containing user input to the PSS server. 
         [0131]    In optional step  922 , method  900  compares the HMAC_S1 to the HMAC_C1 and declares a web injection MitB attack if the HMAC_S1 does not match the HMAC_C1. As used in the present application, “declare” refers to the generation of an alert, the update of a state, the making of a record, or the providing of some other notification of an attack or compromise. Such alerts, updates, records, and notifications may be recorded or transmitted to the user, an administrator, or another third-party. 
         [0132]    In step  924 , method  900  generates a second server keyed-hash message authentication code HMAC_S2 for the packet containing user input. 
         [0133]    In optional step  926 , method  900  compares the HMAC_S2 to the HMAC_C2 and declares a packet modification MitB attack if the HMAC_S2 does not match the HMAC_C2. 
         [0134]    In optional step  928 , method  900  passes the packet containing user input to the third-party website if neither a web injection MitB attack nor a packet modification MitB attack are declared. 
         [0135]      FIG. 10  is a flowchart depicting an exemplary embodiment of method  1000  for primary checking of a packet. Method  1000  utilizes a relational database stored on the PSS server to efficiently access a state table and log relevant information extracted from packet header and content, thereby recording the state of each communication with a given URL. 
         [0136]    In optional step  1002 , method  1000  passes the packet if the requesting and destination domain match a session access control white list (SAC-WL). Domains on the SAC-WL are approved pairs of requesting and destination domains and may automatically bypass certain security and/or detection steps. The SACL-WL may include the requesting domain name, the destination domain name, the protocol, the port, the IP address, and a SACL-WL duration detailing how long the entry of the SACL-WL may last. 
         [0137]    In optional step  1004 , method  1000  enters a warning state if the requesting domain or destination domain match a session access control black list (SAC-BL). Domains on the SAC-BL are domains linked to known attacks or attackers and may be intercepted and/or blocked automatically by the PSS server. The SACL-BL may include the domain name, the protocol, the port, and the IP address. 
         [0138]    In optional step  1006 , method  1000  passes the packet if the requesting site and target site fall under the same-origin policy. 
         [0139]    In optional step  1008 , method  1000  passes the packet if the packet does not include sensitive information. Sensitive information may include, but is not limited to, password, financial, transactional, or identifying information. 
         [0140]      FIG. 11  is a flowchart depicting an exemplary embodiment of method  1100  for further checking of a packet. 
         [0141]    In optional step  1102 , method  1100  passes the packet if user device follows a valid single sign-on policy. 
         [0142]    In optional step  1104 , method  1100  passes the packet if user device uses an Adobe cross-domain policy. 
         [0143]    In optional step  1106 , method  1100  declares a cross-site scripting (XSS) attack and enters a warning state if the requesting domain is in a session access control white list. 
         [0144]    In optional step  1108 , method  1100  declares a cross-site request forgery (CSRF) attack and enters a warning state if the requesting domain is not in a session access control white list. 
         [0145]      FIG. 12  is a flowchart depicting an exemplary embodiment of a method for keylogger forensics. 
         [0146]    In optional step  1202 , method  1200  declares that a OTP and a K KL  are compromised if K KL  verification in a PSS server is correct and decryption of a half of the hash-encoded PW in a user device is incorrect. 
         [0147]    In optional step  1204 , method  1200  declares that a half of a PW shuffled with a half of the K SF  and a half of the PW shuffled with the K KLC  are compromised if K KL  verification in the PSS server is incorrect and decryption of the half of the hash-encoded PW in a user device is correct. 
         [0148]    In optional step  1206 , method  1200  declares that the PW shuffled with the K KLC  is compromised if K KL  verification in the PSS server and decryption of the half of the hash-encoded PW in the PSS server and the user device are all incorrect. 
         [0149]    In optional step  1208 , method  1200  declares that the half of the PW shuffled with the K KLC , the OTP, and the K KL  are compromised if K KL  verification in the PSS server and decryption of the half of the hash-encoded PW in the user device are both correct and decryption of the half of the hash-encoded PW in the PSS server is incorrect. 
         [0150]    In optional step  1210 , method  1200  declares that the half of the PW shuffled with the half of the K SF , the OTP, and the K KL  are compromised if K KL  verification in the PSS server and decryption of the half of the hash-encoded PW in the PSS server are both correct and decryption of the half of the hash-encoded PW in the user device is incorrect. 
         [0151]    In optional step  1212 , method  1200  declares that the PW shuffled with the K KLC , the OTP, and the K KL  are compromised if decryption of the half of the hash-encoded PW in the PSS server and the user device are both incorrect, but K KL  verification in the PSS server is correct. 
         [0152]      FIG. 13 a    is a system flowchart depicting the movement of information during an exemplary embodiment of method  1300  for retrieving a cookie. Certain embodiments require interaction between multiple tables or secrets in order to retrieve other secrets. For example, retrieving a cookie from the third user device table requires secrets from all other user device tables and PSS server tables, as shown in  FIG. 13 a   . Some of these secrets are input for pseudo-random number generators (PRNG), with the PRNG output being used to retrieve secrets from other tables. 
         [0153]    If steps of the method are bypassed during cookie retrieval, this may indicate that secrets are compromised.  FIG. 13 b    is a flowchart depicting an exemplary embodiment of method  1350  for cookie forensics. 
         [0154]    In step  1351 , method  1350  declares that the K DT3  is compromised if all steps on the PSS server side requiring the PSS server tables are bypassed. 
         [0155]    In step  1352 , method  1350  declares that the K ST2D  is compromised if the user device nonce is not retrieved from the second user device table, the secondary user device authenticator is not retrieved from the third PSS server table, and the server device index is not retrieved from the first PSS server table. 
         [0156]    In step  1353 , method  1350  declares that the PSS secret for the user device is compromised if the user device nonce is not retrieved from the second user device table, the secondary user device authenticator is not retrieved from the third PSS server table, the server device index is not retrieved from the first PSS server table, and the PSS secret for the user device is not retrieved from the second PSS server table. 
         [0157]    In step  1354 , method  1350  declares that the cookie nonce is compromised if the user PID and user device PID are not retrieved from the first PSS server table. 
         [0158]    In step  1355 , method  1350  declares that the cookie PID is compromised if the user PID and the user device PID are not retrieved from the first user device table. 
         [0159]      FIG. 14  is a flowchart depicting an exemplary embodiment of method  1400  for retrieving a third PSS table AES-GCM key K PT3DG . All segments of K PT3DG  are broken into multiple pieces, which are stored mixed together and protected by the two-layer high-speed cipher key. Method  1400  decrypts and recovers one segment of a K PT3DG  (K PT3DGn ) and is performed iteratively for n iterations, wherein n is the number of segments. 
         [0160]    In step  1402 , method  1400  decrypts the second PSS server table and retrieves the map for K PT3DG . 
         [0161]    In step  1404 , method  1400  extracts the encrypted pieces that make up K PT3DGn . 
         [0162]    In step  1406 , method  1400  recovers the current secrets for the two-layer high-speed cipher key needed to decrypt K PT3DGn . 
         [0163]    In step  1408 , method  1400  decrypts K PT3DGn . 
         [0164]    In step  1410 , method  1400  repeats steps  1402  through  1408  until all segments of K PT3DG  are recovered. 
         [0165]      FIG. 15  is a system diagram of an exemplary embodiment of system  1500  for preemptive, self-healing computer security. System  1500  includes a user device processor  1515  on a user device  1510 , a PSS server processor  1525  on a PSS server  1520 , and a non-transient computer readable medium  1530  operatively connected to user device processor  1515  and PSS server processor  1525 . Medium  1530  is programmed with computer readable code that upon execution by user device processor  1515  and PSS server processor  1525  causes user device processor  1515  and PSS server processor  1525  to execute method  100  or specific portions thereof. Possible media include random access memory, read only memory, magnetic discs, optical discs, flash memory, virtual memory, and non-virtual memory, magnetic sets, magnetic tape, magnetic disc storage or other magnetic storage devices, or any other non-transient computer readable medium that can be used to storage the desired information and that may be accessed by an instruction execution system, as well as any combination or variation thereof, or any other type of storage medium. 
         [0166]    A relational database  1540  stored on PSS server  1520  is used in method  1000 . Relational database  1540  stores all relevant information extracted from a packet header and content. Relational database  1540  stores tables of the user PID and the user device PID as a B-tree index. Relational database  1540  also stores a login table, a state table and a log table. Information stored on these tables can be extracted to update SAC-WL and SAC-BL, and to trace attackers. The login table, state table and log table are encrypted with relational database key K RD . K RD  is a pseudo-random number generated using the PSS server PID, the user PID, and the user device nonce; thus, the K RD  is updated every session. The state table stores the same information as the fourth user device table, with state PID as a B-tree index. 
         [0167]    The login table includes verification results (i.e., whether the correct secret value was provided during login) for the user device authenticator encrypted by the PSS server next session key, the user device index, device nonce, and user PID encrypted by the user device next session key, the user device PID, the login trial number, a pseudo-random number generated using the user device DoS secret and login trial number, a pseudo-random number generated using the PSS server DoS secret and login trial number, the PSS server authenticator encrypted by the user device next session key, the PSS server authenticator, and the next session number and server PID encrypted by the PSS server next session key. If all of the correct secrets are provided during login, then the login succeeds; otherwise, forensics methods are used to determine which login secret is compromised. 
         [0168]    The login table stores not only each secret&#39;s verification result but also the login results of previous two sessions. Since the first and third PSS server tables are protected as groups in the PSS server, the login table also records a first server table group ID and a third server table group ID, logging which K PT1DG  and K PT3DG  groups the user belongs to and allowing evaluation of whether the K PT1DG  or the K PT3DG  has been compromised. With the login table, forensics can detect multiple users&#39; abnormal actions in the same protected group in order to determine the compromised secrets on server side. This detection can occur over time. For example, if different users in the same K PT3DG  group had abnormal logins over two sessions, but none of the users in the same K PT1DG  group had abnormal logins over three sessions, forensics can conclude that the K PT3DG  was compromised. 
         [0169]    When multiple users in the same group suffer similar attacks because of the same compromised secrets, a “shortcut” check procedure can be established to check the compromised secrets for other users in this group in order to reduce the time required for evaluation. Defending multiple stage attacks is based on the DSKM group relationship and the shortcut check procedure. The DSKM group relationship of compromised users and their devices can detect the time of first compromise and corresponding compromised secrets using any of the forensics methods. The shortcut check procedure can be dynamically established based on correlated events and thus multiple stage attacks can be identified using both DSKM and the shortcut check. 
         [0170]    The log table includes the tab IDs of browser tabs as a hash index and also contains tab log tables for each browser tab opened on user device  1510 . Each tab ID is a randomly generated unique ID for each open browser tab. The tab log table related to a particular browser tab will be terminated (or stop growing) when the user closes the tab or inputs new URL in this particular browser tab. If a packet has no relation to any open browser tab, it will be stored in a specific tab log table with an identifier. Since all logs with same tab ID are stored in one table, system  1500  only needs a single search to retrieve the tab log table for the tab desired to be analyzed. 
         [0171]    Each tab log table contains a list of log items corresponding to packets received and/or sent by a particular browser tab. The tab log table includes the log IDs of logged packets as a B-tree index, the URL the packet was sent or received from, the time the packet was sent or received, the requesting and delivery domain name and IP address, any reference URL, a flag to indicate if a mouse event, such as click, is happened in the transit to the current URL, and whether the packet is an HTTPS or Hyper Text Transfer Protocol (HTTP) packet. If the packet is an HTTP packet, the tab log table also stores a flag to indicate whether the content is encrypted. The tab log table also stores the state before the current state in order to record the reason the packet is logged, as well as the reference tab ID, the parent of the current tab ID which provides the relationship between different tabs. 
         [0172]    Because the relational database stores information in various related tables, instead of a single B-tree database, queries are limited to information logs from each open tab. This allows rapid searching and increases the ability of system  1500  to respond to attacks in real time. Querying correlated logs across multiple tabs is also more efficient because of the parent tab ID stored in the tab log table. The relational database is scalable, allowing the addition of more columns into the tab log table to connect not only other correlated tab log tables but also a specific log ID to further reduce the time required of real-time forensics. Real-time forensics method  1700  correlates the events based on information in relational database  1540  in order to rapidly track and trace the source of the attacks in real-time. 
         [0173]      FIG. 16  is a flowchart depicting an exemplary embodiment of method  1600  for memory scraping forensics. 
         [0174]    In step  1602 , method  1600  declares that a K DT1  was compromised by memory scraping if a user device authenticator encrypted by a PSS server next session key for the current session, and a user device index, device nonce, and user PID encrypted by a user device next session key for the current session cannot be decrypted correctly by a PSS server. 
         [0175]    In step  1604 , method  1600  declares that a K DT2  was compromised by memory scraping if a user device PID for the current session, a login trial number, and a pseudo-random number generated using a user device DoS secret for the current session and the login trial number are verified incorrectly by the PSS server. 
         [0176]    In step  1606 , method  1600  declares that the user device DoS secret was compromised by accessing a first PSS server table on the PSS server if a DoS attack was launched with a correct login trial number, pseudo-random number generated using the user device DoS secret, and login trial number to the PSS server. 
         [0177]    In step  1608 , method  1600  declares that a K PT1DG  is compromised by memory scraping if multiple user devices report that: a pseudo-random number generated using a PSS server DoS secret for the current session and login trial number is correct; a PSS server authenticator encrypted by the user device next session key for the current session could be decrypted successfully, but the PSS server authenticator for the current session is incorrect; and a next session number and PSS server PID encrypted by the PSS server next session key for the current session is correct. 
         [0178]    In step  1610 , method  1600  declares that a K PT2D  and a K PT2SD  are compromised by memory scraping if a single user device reports that: the pseudo-random number generated using the PSS server DoS secret for the current session and login trial number is incorrect; the PSS server authenticator encrypted by the user device next session key for the current session could be decrypted successfully, but PSS server authenticator for the current session is incorrect; and the next session number and PSS server PID encrypted by the PSS server next session key for the current session is incorrect. 
         [0179]    In step  1612 , method  1600  declares that a K PT3DG  is compromised by memory scraping if multiple user devices report that: the pseudo-random number generated using the PSS server DoS secret for the current session and login trial number is incorrect; and the PSS server authenticator encrypted by the user device next session key for the current session, and the next session number and PSS server PID encrypted by the PSS server next session key for the current session cannot be decrypted correctly. 
         [0180]    In step  1614 , method  1600  declares that the PSS server DoS secret is compromised if a DoS attack was launched with the correct login trial number and pseudo-random number generated using the PSS server DoS secret and login trial number to the user device. 
         [0181]    In step  1616 , method  1600  declares that the user device next session key, the PSS server next session key, and the user device PID for the next session are compromised by memory scraping if the next session login is successful, but in the subsequent session, the user device PID for the subsequent session is verified incorrectly in the PSS server. 
         [0182]    In step  1618 , method  1600  declares that the user device next session key, the PSS server next session key, and a PSS server PID for the next session are compromised by memory scraping if the next session login is successful, but in the subsequent session, the PSS server PID for the subsequent session is verified incorrectly in the user device. 
         [0183]    In step  1620 , method  1600  declares that K PT1DG  and K PT3DG  are compromised by memory scraping if multiple user devices in a K PT1DG  group report that: the pseudo-random number generated using the PSS server DoS secret for the current session and login trial number is correct; the PSS server authenticator encrypted by the user device next session key for the current session could be decrypted successfully, but PSS server authenticator for the current session is incorrect; and the next session number and PSS server PID encrypted by the PSS server next session key for the current session is correct; and multiple user devices in a K PT3DG  group report that: the pseudo-random number generated using the PSS server DoS secret for the current session and login trial number is incorrect; and the PSS server authenticator encrypted by the user device next session key for the current session, and the next session number and PSS server PID encrypted by the PSS server next session key for the current session cannot be decrypted correctly. This step is important because user devices in both K PT1DG  and K PT3DG  groups have a probability of connecting with an attacker&#39;s server without knowing. PSS server policies should force these users to re-register in a secure environment. 
         [0184]    In step  1622 , method  1600  declares that K PT1DG , K PT2D  and K PT2SD  are compromised by memory scraping if multiple user devices report that: the pseudo-random number generated using the PSS server DoS secret for the current session and login trial number is correct; the PSS server authenticator encrypted by the user device next session key for the current session could be decrypted successfully, but PSS server authenticator for the current session is incorrect; and the next session number and PSS server PID encrypted by the PSS server next session key for the current session is correct. 
         [0185]    In step  1624 , method  1600  declares that K PT3DG , K PT2D  and K PT2SD  are compromised by memory scraping if multiple user devices in a K PT3DG  group report that: the pseudo-random number generated using the PSS server DoS secret for the current session and login trial number is incorrect; and the PSS server authenticator encrypted by the user device next session key for the current session, and the next session number and PSS server PID encrypted by the PSS server next session key for the current session cannot be decrypted correctly; and one user device protected by the compromised K PT3DG  group, K PT2D  and K PT2SD  reports that: the pseudo-random number generated using the PSS server DoS secret for the current session and login trial number is incorrect; the PSS server authenticator encrypted by the user device next session key for the current session is correct; and the next session number and PSS server PID encrypted by the PSS server next session key for the current session cannot be decrypted correctly. 
         [0186]    In step  1626 , method  1600  declares that K DT1  and corresponding K PT1DG  are compromised by memory scraping if multiple user devices report that: the pseudo-random number generated using the PSS server DoS secret for the current session and login trial number is correct; the PSS server authenticator encrypted by the user device next session key for the current session could be decrypted successfully, but PSS server authenticator for the current session is incorrect; and the next session number and PSS server PID encrypted by the PSS server next session key for the current session is correct; and one PSS server reports that: the pseudo-random number generated using the user device DoS secret for the current session and login trial number is correct; the user device authenticator encrypted by the PSS server next session key for the current session could be decrypted successfully, but user device authenticator for the current session is incorrect; and the user device index, device nonce, and user PID encrypted by the user device next session key for the current session cannot be decrypted correctly. 
         [0187]      FIG. 17  is a flowchart depicting an exemplary embodiment of method  1700  for real-time forensics. 
         [0188]    In step  1702 , method  1700  extracting current packet information from a packet. The packet information extract may be, but is not limited to, a log ID, a URL the packet was sent or received from, a time the packet was sent or received, a requesting and delivery domain name and IP address, a reference URL, a flag to indicate a mouse event, whether the packet is an HTTPS or HTTP packet, a flag to indicate whether content of the packet is encrypted, a state before the current state, and/or a reference tab ID. 
         [0189]    In step  1704 , method  1700  logs the current packet information in a tab log table of a relational database. 
         [0190]    In step  1706 , method  1700  comparing the current packet information with information in the relational database according to a list of previously defined rules to determine common information. These rules may include relational rules to allow method  1700  to rapidly correlate information in the relational database from multiple sessions, users, browser tabs, and tab logs. Such shortcut check procedures allow rapid assessments for information obtained from other users&#39; sessions, browser tabs, and tab logs in order to reduce the time required for evaluation. Shortcut check procedures build index tables that point to types of state transitions (a series of previous and current states). This mimics a tab ID to correlate events during logging and expedite information retrieval during attack prevention. 
         [0191]    In step  1708 , method  1700  reports any common information. This report may take the form of an alert, updating a state or a portion of a database, making a record, or providing some other notification. Such alerts, updates, records, and notifications may be recorded or transmitted to the user, an administrator, or another third-party. The report may include the attack method, source, target, or any other relevant information. 
         [0192]      FIG. 18 a    depicts the log table for a sample CSRF attack.  FIG. 18 b    depicts the state table for the sample CSRF attack. 
         [0193]    For the first log table entry of the sample CSRF attack, when a user&#39;s browser sends a silent request for the malicious form, it will be logged as suspicious since, by way of non-limiting example, this request is caused by an iframe (per step  608  of method  600 ). For the second log table entry of the sample CSRF attack, when the attacker site sends a malicious form to the user, it will be logged as suspicious because it is the corresponding response of the suspicious request from the first log table entry (per step  608  of method  600 ). For the third log table entry of the sample CSRF attack, when the user&#39;s browser sends a silent malicious form to the legitimate third-party site, it will be logged as suspicious because it sends an invisible form (per step  612  of method  600 ) and a CSRF attack is declared (per step  1102  of method  1100 ). The packet will also be blocked by method  500 , leading to the state table shown in  FIG. 18   b.    
         [0194]    Information extracted from the state and log tables could lead to new forensics results. By way of non-limiting example, the SAC-BL may be updated with the attacker site&#39;s domain name and IP address to subject packets to or from that site to additional scrutiny, per step  1004  or method  1000 . The list of predetermined sites may be updated with the legitimate third-party site domain name and IP address to ensure that MitB attack prevention method  400  is always employed when accessing that site. The type of target data and type of attack may be used to employ specific additional security measures. 
         [0195]    In the foregoing description, certain terms have been used for brevity, clearness, and understanding. No unnecessary limitations are to be inferred therefrom beyond the requirement of the prior art because such terms are used for descriptive purposes and are intended to be broadly construed. The different configurations, systems, and method steps described herein may be used alone or in combination with other configurations, systems and method steps. It is to be expected that various equivalents, alternatives and modifications are possible within the scope of the appended claims.