Abstract: Methods and systems for authenticating a client device using entropy provided by a server and/or a device paired with the client device are described herein. The client device may receive a first user credential. The client device may receive first entropy from a wireless device. The client device may decrypt, using the first entropy, second entropy generated by a server. The client device may decrypt, using the second entropy, a second user credential that was stored in the client device. Based on a comparison of the first user credential with the second user credential, the client device may grant a user of the client device access to one or more resources.

Abstract: Methods and systems for authenticating a client device using entropy provided by a server and/or a device paired with the client device are described herein. The client dvice may receive a first user credential. The client device may receive first entropy from a wireless device. The client device may decrypt, using the first entropy, second entropy generated by a server. The client device may decrypt, using the second entropy, a second user credential that was stored in the client device. Based on a comparison of the first user credential with the second user credential, the client device may grant a user of the client device access to one or more resources.

Abstract: Methods and systems for authenticating a client device using entropy provided by a server and/or a device paired with the client device are described herein. The system may generate static entropy and time-limited entropy based on data from the server and/or the paired device. The static and time-limited entropy may be used to authenticate the client device (application or a user of the client device) in addition to authentication credentials or entropy such as a PIN or password provided by the user. The time-limited entropy may have an expiration time. If the time-limited entropy is expired, the system may request the user to perform a hard authentication with the server, such as by providing a username, password, and/or optionally a two-factor authentication code, among other information.

Abstract: Methods and systems for authenticating a client device using entropy provided by a server and/or a device paired with the client device are described herein. The system may generate static entropy and time-limited entropy based on data from the server and/or the paired device. The static and time-limited entropy may be used to authenticate the client device (application or a user of the client device) in addition to authentication credentials or entropy such as a PIN or password provided by the user. The time-limited entropy may have an expiration time. If the time-limited entropy is expired, the system may request the user to perform a hard authentication with the server, such as by providing a username, password, and/or optionally a two-factor authentication code, among other information.

Abstract: Encryption-based data access management may include a variety of processes. In one example, a device may transmit a user authentication request for decrypting encrypted data to a data storage server storing the encrypted data. The computing device may then receive a validation token associated with the user's authentication request, the validation token indicating that the user is authenticated to a domain. Subsequently, the computing device may transmit the validation token to a first key server different from the data storage server. Then, in response to transmitting the validation token the computing device may receive, from the first key server, a key required for decrypting the encrypted data. The device may then decrypt at least a portion of the encrypted data using the key.

Abstract: Methods and systems for authenticating a client device using entropy provided by a server and/or a device paired with the client device are described herein. The system may generate static entropy and time-limited entropy based on data from the server and/or the paired device. The static and time-limited entropy may be used to authenticate the client device (application or a user of the client device) in addition to authentication credentials or entropy such as a PIN or password provided by the user. The time-limited entropy may have an expiration time. If the time-limited entropy is expired, the system may request the user to perform a hard authentication with the server, such as by providing a username, password, and/or optionally a two-factor authentication code, among other information.

Abstract: Securing encrypted virtual hard disks may include a variety of processes. In one example, a virtual hard disk is created for a user and encrypted with a volume key, and the volume key placed in an administrator header. The administrator header may be encrypted with a protection key, the protection key created from a user identifier corresponding to the user, a volume identifier corresponding to the virtual hard disk, and two cryptographic secrets. The protection key may then destroyed after encrypting the administrator header and therefore, might never leave the encryption engine. The two cryptographic secrets may be stored in separate storage locations, one accessible to the user and the other accessible to administrators. Accordingly, the protection key might never transmitted or can be intercepted, and no single entity may be compromised to gain access to all of the information needed to recreate the protection key.

Abstract: Methods and systems for authenticating a client device using entropy provided by a server and/or a device paired with the client device are described herein. The system may generate static entropy and time-limited entropy based on data from the server and/or the paired device. The static and time-limited entropy may be used to authenticate the client device (application or a user of the client device) in addition to authentication credentials or entropy such as a PIN or password provided by the user. The time-limited entropy may have an expiration time. If the time-limited entropy is expired, the system may request the user to perform a hard authentication with the server, such as by providing a username, password, and/or optionally a two-factor authentication code, among other information.

Abstract: Securing encrypted virtual hard disks may include a variety of processes. In one example, a virtual hard disk is created for a user and encrypted with a volume key, and the volume key placed in an administrator header. The administrator header may be encrypted with a protection key, the protection key created from a user identifier corresponding to the user, a volume identifier corresponding to the virtual hard disk, and two cryptographic secrets. The protection key may then destroyed after encrypting the administrator header and therefore, might never leave the encryption engine. The two cryptographic secrets may be stored in separate storage locations, one accessible to the user and the other accessible to administrators. Accordingly, the protection key might never transmitted or can be intercepted, and no single entity may be compromised to gain access to all of the information needed to recreate the protection key.

Abstract: Securing encrypted virtual hard disks may include a variety of processes. In one example, a virtual hard disk is created for a user and encrypted with a volume key, and the volume key placed in an administrator header. The administrator header may be encrypted with a protection key, the protection key created from a user identifier corresponding to the user, a volume identifier corresponding to the virtual hard disk, and two cryptographic secrets. The protection key may then destroyed after encrypting the administrator header and therefore, might never leave the encryption engine. The two cryptographic secrets may be stored in separate storage locations, one accessible to the user and the other accessible to administrators. Accordingly, the protection key might never transmitted or can be intercepted, and no single entity may be compromised to gain access to all of the information needed to recreate the protection key.

Abstract: Encryption-based data access management may include a variety of processes. In one example, a device may transmit a user authentication request for decrypting encrypted data to a data storage server storing the encrypted data. The computing device may then receive a validation token associated with the user's authentication request, the validation token indicating that the user is authenticated to a domain. Subsequently, the computing device may transmit the validation token to a first key server different from the data storage server. Then, in response to transmitting the validation token the computing device may receive, from the first key server, a key required for decrypting the encrypted data. The device may then decrypt at least a portion of the encrypted data using the key.

Abstract: Encryption-based data access management may include a variety of processes. In one example, a device may transmit a user authentication request for decrypting encrypted data to a data storage server storing the encrypted data. The computing device may then receive a validation token associated with the user's authentication request, the validation token indicating that the user is authenticated to a domain. Subsequently, the computing device may transmit the validation token to a first key server different from the data storage server. Then, in response to transmitting the validation token the computing device may receive, from the first key server, a key required for decrypting the encrypted data. The device may then decrypt at least a portion of the encrypted data using the key.

Abstract: Encryption-based data access management may include a variety of processes. In one example, a device may transmit a user authentication request for decrypting encrypted data to a data storage server storing the encrypted data. The computing device may then receive a validation token associated with the user's authentication request, the validation token indicating that the user is authenticated to a domain. Subsequently, the computing device may transmit the validation token to a first key server different from the data storage server. Then, in response to transmitting the validation token the computing device may receive, from the first key server, a key required for decrypting the encrypted data. The device may then decrypt at least a portion of the encrypted data using the key.

Abstract: Securing encrypted virtual hard disks may include a variety of processes. In one example, a virtual hard disk is created for a user and encrypted with a volume key, and the volume key placed in an administrator header. The administrator header may be encrypted with a protection key, the protection key created from a user identifier corresponding to the user, a volume identifier corresponding to the virtual hard disk, and two cryptographic secrets. The protection key may then destroyed after encrypting the administrator header and therefore, might never leave the encryption engine. The two cryptographic secrets may be stored in separate storage locations, one accessible to the user and the other accessible to administrators. Accordingly, the protection key might never transmitted or can be intercepted, and no single entity may be compromised to gain access to all of the information needed to recreate the protection key.

Abstract: Securing encrypted virtual hard disks may include a variety of processes. In one example, a virtual hard disk is created for a user and encrypted with a volume key, and the volume key placed in an administrator header. The administrator header may be encrypted with a protection key, the protection key created from a user identifier corresponding to the user, a volume identifier corresponding to the virtual hard disk, and two cryptographic secrets. The protection key may then destroyed after encrypting the administrator header and therefore, might never leave the encryption engine. The two cryptographic secrets may be stored in separate storage locations, one accessible to the user and the other accessible to administrators. Accordingly, the protection key might never transmitted or can be intercepted, and no single entity may be compromised to gain access to all of the information needed to recreate the protection key.

Abstract: Securing encrypted virtual hard disks may include a variety of processes. In one example, a virtual hard disk is created for a user and encrypted with a volume key, and the volume key placed in an administrator header. The administrator header may be encrypted with a protection key, the protection key created from a user identifier corresponding to the user, a volume identifier corresponding to the virtual hard disk, and two cryptographic secrets. The protection key may then destroyed after encrypting the administrator header and therefore, might never leave the encryption engine. The two cryptographic secrets may be stored in separate storage locations, one accessible to the user and the other accessible to administrators. Accordingly, the protection key might never transmitted or can be intercepted, and no single entity may be compromised to gain access to all of the information needed to recreate the protection key.

Abstract: A secure mechanism for transparent key recovery for a user who has changed authentication information is disclosed. A password manager agent intercepts requests by a user to access secure resources that require user credentials. Upon detecting changed authentication information for the user, the password manager agent automatically regenerates the components of a cryptographic key associated with the user that was previously used to encrypt user credentials for the user and then destroyed. After regeneration of the original cryptographic key, the password manager agent uses the key to decrypt the user credentials necessary for the requested application. The regenerated key is then destroyed and the user credentials are re-encrypted by the password manager agent using a new cryptographic key associated with the user made up of multiple components.

Abstract: A mechanism for rapidly authenticating an interactive user in an operating system logon session based on a shared account by using a credential delivery application to enable permission-based access to a user's remote session from the shared account is disclosed. The present invention provides the ability to switch local interactive users, authenticate the new interactive user, and switch the remote session without requiring the client to first establish a new logon session tied to the new local interactive user. The present invention also alters the normal locking mechanism found in operating system logon sessions so as to restrict access to an interactive local user's applications (both local and remote) while still allowing the rapid switching of interactive users at the client device.