#Reset encrypted data and password password#
You then encrypt that key with a key derived from their password and a key derived by some other piece of information. This is the idea of having a data key, typically unique to a record, or perhaps to all of a user's records, depending on security needs. Put a somewhat less descriptive, but more conceptual way, basically you want to provide two different means to get to the same key. Conversely, the much-hyped Mega site deliberately forgoes all kinds of escrow and lost password recovery precisely to ascertain, in a very legal way, that they have no way of accessing the data without the collaboration of the user. in an enterprise, when a user is struck by a bus, his successor must be able to read the stored business data, and the previous tenant can no longer give his password). This is good the user data is not really his own, and the user is unavailable (e.g.
Key escrow means that the server (with the help of the TTP) can theoretically unlock the user data without his consent or even knowledge. In a different situation, Microsoft's BitLocker drive encryption technology (included in recent/expensive versions of Windows) supports key escrow so that the sysadmin can save the data of users who forgot their password. Whether key escrow is applicable really depends on the context and, ultimately, how much you can make the user pay for the unlocking of his precious data. The escrow step can be performed without interacting with the TTP if asymmetric encryption is used: the TTP has a RSA key pair, the user's password is encrypted with the public key, and the TTP uses the private key to unlock the lost password. by coming in person showing and his driver's license). The TTP would have to be adequately protected, and agree to unlock escrowed secrets only as part of an official, controlled and audited ceremony where the data owner (the user who forgot his password) proves his identity through some physical mean (e.g. A copy of the user's password, or of an intermediate key K, could be stored by a "Trusted Third Party", to be unlocked in case of emergency. This kind of miracle (how will the user not forget a password he never uses, since he managed to forget the password he uses regularly ?) can be achieved in several ways: the backup password could be a long sequence of characters which the user writes down on a piece of paper, stored in a safe (or his wallet) the backup password could consist of answers to "security questions" (as suggests). In that scenario, the second password will be the "backup password" which the user will not forget. You actually want an intermediate key anyway, to support password changes without having to reencrypt all the data. To make that efficient, use an intermediate key: a data file is encrypted with a random file key K, and key K is encrypted twice: once with the first password, and once with the second password.
There are two ways out the "forgotten password" issue:Įncrypt the data not with one password, but with two passwords. The secret answers option is the easiest, but it's possible to do this with any secret value. When the user forgets their password, ask them for their secret answers and generate the secondary locking key, then use that to compute the surrogate key.Xor the surrogate key with the secondary locking key and store that as a backup key.Run that value through a KDF to create a secondary locking key. Convert the answers to uppercase and concatenate them.
0 kommentar(er)
