Hi folks,
Here's a problem, and an idea to solve it.
Suppose I have a Keepass i want to pass down upon my death. If I store a
copy of my password with my will, it becomes almost impossible to change.
You should change your Keepass password every so often, if for example you
accidentally type it into the wrong system.
How should one ensure that the Keepass can be encrypted upon your death,
while also ensuring you can remain secure by periodically changing your
password.
Solution:
Allow the Keepass user to specify a second password. Either of the two
will decrypt the database, but the user could make this second password 50
characters long or more, and never use it, just store it with the will.
Since it is never used and never remembered, it need never be changed.
What do you think?
Vandervecken
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The KeePass design uses a cryptographic hash function to create an encryption key that is used to encrypt and decrypt the database. A property of this design is that it is infeasible to define two Master Keys (e.g. two passwords) that can open the same database.
However, in principal it is possible to encrypt the Master Key itself with different pass-phrases, each of which could be decrypted using the corresponding pass-phrase. In practice, management of multiple, differently encrypted copies of the same Master Key is likely to become unmanageable for a majority of users. This would lead to complaints that would damage KeePass' reputation in spite of the fact that mismanagement of the Master Key copies is user error. It is likely that even a simple 2 pass-phrase configuration would prove fragile over a long time period because the scheme requires that the Master Key remain constant over the life a given pass-phrase set.
In spite of these potential pitfalls I know of two plugins that use similar intermediate encryption schemes. I don't consider either to be particularly suitable for your purpose.
The one that is most likely to be suitable because it is the most usable is the KeeAutoExec plugin. This plugin allows you to create a dedicated KeePass 'auto-open' database containing a strong Master Key that can be opened using a reasonable Master Key. The KeeAutoExec plugin then opens the primary database using the Strong Master Key from the open 'auto-open' database. The difficulty for your purpose is that the strong Master Key is visible in the KeePass workspace while the 'auto-open' database is open and the 'auto-open' database must remain open whenever the other databases are open to retain good usability. Given the concerns you expressed it is likely that you would feel it necessary to change the Strong Master Key periodically defeating the value of this configuration for your purposes.
The second is the OtpKeyProv plugin. This plugin probably protects the database Master Key better, but it is considerably more difficult to use day to day because each time you want to open/unlock your database you would need to enter a minimum of three different, newly generated 6 digit numbers using an OTP generator such as google authenticator on a smart phone or a yubikey, . The actual Master Key would be the key you attach to your will and it could not be changed without reinitializing both the OTP generator and the OtpKeyProv plugin.
Last edit: wellread1 2014-04-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For the record, I have never thought about what happens to my KeePass data when I'm no longer around ;-) - I can't imagine anyone in my family having an interest in it ...
That said, your scenario - one full-strength, but fixed and rarely used "Über-key" vs shorter, but volatile "everyday" keys - is interesting anyway.
As far as I understand KeePass's cryptography however, this couldn't be done inside KeePass alone:
Every time you change your password for the KeePass database, the database get encrypted with a new raw AES key (derived from your password plus some "salt").
Nothing in the saved database gives any hint about this AES key - this is of course by design, and is as it should be.
That means that any password information you (or your heirs) had yesterday will be worthless today after changing your master password.
Set up the composite master key for your KeePass database to consist of either your "everyday" password, or a key file that you store in one place.
You probably don't want the keyfile alone to be sufficient for unlocking the database (eg, because you want to store it in some online web space, or your family has access to your file system even while you're alive ... :o).
You could - and should in this case - therefore encrypt the key file itself, again. And for this encryption you would use your fixed, long and strong 256-bit-entropy password (and write this one down in your will, along with a pointer where to find the encrypted key file, and the KeePass database, of course ;-).
To encrypt the key file, you could either use KeePass itself (ie place the key file content in a second "password" database which is protected by your long-term password, and does only contain the key file content). Or you could choose any other encryption software you trust (and your heirs could acquire and use ...!).
do come with source code which one could scrutinize (but I can't comment on them otherwise).
I'd like to add that it should certainly be possible to add a feature like this (a fixed, long-time, secure "super key", so to say) to KeePass, and I believe this could even be done without weakening the database's security.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As far as I understand KeePass's cryptography however, this couldn't be done inside KeePass alone
A scheme with functionality similar to that described for the the KeeAutoExec plugin can be implemented solely in triggers, but the KeeAutoExec plugin is easier to manage.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I see it, Martin has the right idea: Introduce one more level of indirection. But in my view, it makes no sense to encrypt the keyfile/master password. The whole idea of the keyfile/master password is that it's a relatively small secret that you want to occasionally change. By encrypting it, you're stuck with the same problem again: The encryption key that encrypts the keyfile/master password is just another small secret that you want to occasionally change. So doing a computerized indirection gains you nothing.
In my view, what you want to do is to keep a copy of the keyfile/master password in a secret place. (You can use a CDROM or USB flash drive, with a hardcopy backup just in case.) Then write down a description of the secret place, put copies of the description in sealed envelopes, and give the envelopes to people you trust, with instructions not to open the envelopes until your death. (Having more than one secret place provides useful redundancy.)
That way, you can change your keyfile/master password at any time without needing to communicate with your heirs. This same indirection scheme works not only for KeePass, but also for your will itself and other final instructions. You may want to keep many of these things secret until your death, and may need to change them occasionally without communicating with your heirs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think if a specific Keepass database can be unlocked using either a password or a key file, then I can make something work. I can use one form every day while the other is kept for special occasions.
Hell, I could put the encrypted key file anywhere I wanted, if it had an immense password to unencrypt the key file.
What do you suggest I use to encrypt the keyfile that is as generic as possible, as I would want the keyfile to be unencryptable 50 years from now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think if a specific Keepass database can be unlocked using either a password or a key file, then I can make something work.
That is not possible. A KeePass database has a one and only one Master Key that consists of all specified elements of the Master Key. A partial Master Key is invalid and will not decrypt the database.
Cutting through all the discussion, the best solution is the one you don't want: Place copy(s) of the database Master Key in secure location(s) that you can access conveniently if you need to change it, but that your heirs can also access. Bill provided various concrete examples of how this might be done.
Note: A KeePass key file is not encrypted, its contents are a secret which is why it should never be kept with the database. The database key file can be the one and only Master Key or it can be part of the one and only composite Master Key, but not both. The database can have one and only one Master Key, not two.
Last edit: wellread1 2014-04-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you have two people that you trust (and preferably do not regularly meet) then one simple way of managing a secret master password is to use a security principle of a "two person rule".
In principle this works as follows:
Create a relatively long password for your database.
Split this password into two parts.
Send the first half to one of the trusted people and the other half to the other.
In this way neither part of the password can unlock the database. Both parts would be required and this typically would require both people to be present. Each person types in their part of the full password. Neither ever needs to know the full password.
If the master password is changed then it would obviously be necessary to send out both parts again.
Last edit: steelej 2014-04-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another suggestion, along similar lines to the OTP/Yubikey idea, is to pregenerate your future passwords. The KeePass password generator built in to KeePass 2.x (I don't know if v1.x does this) can spit out a preview block of 17 passwords all based on the same entropy selections. Copy them all into a speadsheet, and add a column beside them for the date each password expires. You can generate as many previews and as many future dates for them as you like, with whatever interval you intend to be changing your password. Then simply print a copy of the spreadsheet off, seal it in an envelope and keep it with your Will. Then move the spreadsheet itself into your KeePass database as an attachment, and remember to change your database's Master Password to the next one in the spreadhseet by the due date. This way you don't even need to think of a new Master Password each month (or whatever period), as you just copy the next one off the spreadsheet. When you pass on to the great unknown, your family can open the envelope with your Will, find the last dated password change before your passing, and access your password database with it. Simple.
Also, as already mentioned above, don't forget to leave instructions in your Will for how to locate the actual password database itself. A particular USB key, CD/DVD, or wherever.
Last edit: Robert Frittmann 2014-06-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A simpler, but less secure solution is to have the location of your master password in your Will. Yes this does mean writing it down, but it could be relatively secure: a sealed unmarked envelop locked in a household safe or bank safety deposit box is relatively secure plus simple to update as needed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi folks,
Here's a problem, and an idea to solve it.
Suppose I have a Keepass i want to pass down upon my death. If I store a
copy of my password with my will, it becomes almost impossible to change.
You should change your Keepass password every so often, if for example you
accidentally type it into the wrong system.
How should one ensure that the Keepass can be encrypted upon your death,
while also ensuring you can remain secure by periodically changing your
password.
Solution:
Allow the Keepass user to specify a second password. Either of the two
will decrypt the database, but the user could make this second password 50
characters long or more, and never use it, just store it with the will.
Since it is never used and never remembered, it need never be changed.
What do you think?
Vandervecken
The KeePass design uses a cryptographic hash function to create an encryption key that is used to encrypt and decrypt the database. A property of this design is that it is infeasible to define two Master Keys (e.g. two passwords) that can open the same database.
However, in principal it is possible to encrypt the Master Key itself with different pass-phrases, each of which could be decrypted using the corresponding pass-phrase. In practice, management of multiple, differently encrypted copies of the same Master Key is likely to become unmanageable for a majority of users. This would lead to complaints that would damage KeePass' reputation in spite of the fact that mismanagement of the Master Key copies is user error. It is likely that even a simple 2 pass-phrase configuration would prove fragile over a long time period because the scheme requires that the Master Key remain constant over the life a given pass-phrase set.
In spite of these potential pitfalls I know of two plugins that use similar intermediate encryption schemes. I don't consider either to be particularly suitable for your purpose.
The one that is most likely to be suitable because it is the most usable is the KeeAutoExec plugin. This plugin allows you to create a dedicated KeePass 'auto-open' database containing a strong Master Key that can be opened using a reasonable Master Key. The KeeAutoExec plugin then opens the primary database using the Strong Master Key from the open 'auto-open' database. The difficulty for your purpose is that the strong Master Key is visible in the KeePass workspace while the 'auto-open' database is open and the 'auto-open' database must remain open whenever the other databases are open to retain good usability. Given the concerns you expressed it is likely that you would feel it necessary to change the Strong Master Key periodically defeating the value of this configuration for your purposes.
The second is the OtpKeyProv plugin. This plugin probably protects the database Master Key better, but it is considerably more difficult to use day to day because each time you want to open/unlock your database you would need to enter a minimum of three different, newly generated 6 digit numbers using an OTP generator such as google authenticator on a smart phone or a yubikey, . The actual Master Key would be the key you attach to your will and it could not be changed without reinitializing both the OTP generator and the OtpKeyProv plugin.
Last edit: wellread1 2014-04-20
For the record, I have never thought about what happens to my KeePass data when I'm no longer around ;-) - I can't imagine anyone in my family having an interest in it ...
That said, your scenario - one full-strength, but fixed and rarely used "Über-key" vs shorter, but volatile "everyday" keys - is interesting anyway.
As far as I understand KeePass's cryptography however, this couldn't be done inside KeePass alone:
Every time you change your password for the KeePass database, the database get encrypted with a new raw AES key (derived from your password plus some "salt").
Nothing in the saved database gives any hint about this AES key - this is of course by design, and is as it should be.
That means that any password information you (or your heirs) had yesterday will be worthless today after changing your master password.
But maybe you could use the following setup, however (solving your problem by "introducing another level of indirection"):
Set up the composite master key for your KeePass database to consist of either your "everyday" password, or a key file that you store in one place.
You probably don't want the keyfile alone to be sufficient for unlocking the database (eg, because you want to store it in some online web space, or your family has access to your file system even while you're alive ... :o).
You could - and should in this case - therefore encrypt the key file itself, again. And for this encryption you would use your fixed, long and strong 256-bit-entropy password (and write this one down in your will, along with a pointer where to find the encrypted key file, and the KeePass database, of course ;-).
To encrypt the key file, you could either use KeePass itself (ie place the key file content in a second "password" database which is protected by your long-term password, and does only contain the key file content). Or you could choose any other encryption software you trust (and your heirs could acquire and use ...!).
For example
https://panthema.net/2009/cryptote/
http://www.andromeda.com/people/ddyer/notepad/NotepadCrypt-technotes.html
do come with source code which one could scrutinize (but I can't comment on them otherwise).
I'd like to add that it should certainly be possible to add a feature like this (a fixed, long-time, secure "super key", so to say) to KeePass, and I believe this could even be done without weakening the database's security.
A scheme with functionality similar to that described for the the KeeAutoExec plugin can be implemented solely in triggers, but the KeeAutoExec plugin is easier to manage.
As I see it, Martin has the right idea: Introduce one more level of indirection. But in my view, it makes no sense to encrypt the keyfile/master password. The whole idea of the keyfile/master password is that it's a relatively small secret that you want to occasionally change. By encrypting it, you're stuck with the same problem again: The encryption key that encrypts the keyfile/master password is just another small secret that you want to occasionally change. So doing a computerized indirection gains you nothing.
In my view, what you want to do is to keep a copy of the keyfile/master password in a secret place. (You can use a CDROM or USB flash drive, with a hardcopy backup just in case.) Then write down a description of the secret place, put copies of the description in sealed envelopes, and give the envelopes to people you trust, with instructions not to open the envelopes until your death. (Having more than one secret place provides useful redundancy.)
That way, you can change your keyfile/master password at any time without needing to communicate with your heirs. This same indirection scheme works not only for KeePass, but also for your will itself and other final instructions. You may want to keep many of these things secret until your death, and may need to change them occasionally without communicating with your heirs.
I think if a specific Keepass database can be unlocked using either a password or a key file, then I can make something work. I can use one form every day while the other is kept for special occasions.
Hell, I could put the encrypted key file anywhere I wanted, if it had an immense password to unencrypt the key file.
What do you suggest I use to encrypt the keyfile that is as generic as possible, as I would want the keyfile to be unencryptable 50 years from now.
That is not possible. A KeePass database has a one and only one Master Key that consists of all specified elements of the Master Key. A partial Master Key is invalid and will not decrypt the database.
Cutting through all the discussion, the best solution is the one you don't want: Place copy(s) of the database Master Key in secure location(s) that you can access conveniently if you need to change it, but that your heirs can also access. Bill provided various concrete examples of how this might be done.
Note: A KeePass key file is not encrypted, its contents are a secret which is why it should never be kept with the database. The database key file can be the one and only Master Key or it can be part of the one and only composite Master Key, but not both. The database can have one and only one Master Key, not two.
Last edit: wellread1 2014-04-20
If you have two people that you trust (and preferably do not regularly meet) then one simple way of managing a secret master password is to use a security principle of a "two person rule".
In principle this works as follows:
In this way neither part of the password can unlock the database. Both parts would be required and this typically would require both people to be present. Each person types in their part of the full password. Neither ever needs to know the full password.
If the master password is changed then it would obviously be necessary to send out both parts again.
Last edit: steelej 2014-04-21
Another suggestion, along similar lines to the OTP/Yubikey idea, is to pregenerate your future passwords. The KeePass password generator built in to KeePass 2.x (I don't know if v1.x does this) can spit out a preview block of 17 passwords all based on the same entropy selections. Copy them all into a speadsheet, and add a column beside them for the date each password expires. You can generate as many previews and as many future dates for them as you like, with whatever interval you intend to be changing your password. Then simply print a copy of the spreadsheet off, seal it in an envelope and keep it with your Will. Then move the spreadsheet itself into your KeePass database as an attachment, and remember to change your database's Master Password to the next one in the spreadhseet by the due date. This way you don't even need to think of a new Master Password each month (or whatever period), as you just copy the next one off the spreadsheet. When you pass on to the great unknown, your family can open the envelope with your Will, find the last dated password change before your passing, and access your password database with it. Simple.
Also, as already mentioned above, don't forget to leave instructions in your Will for how to locate the actual password database itself. A particular USB key, CD/DVD, or wherever.
Last edit: Robert Frittmann 2014-06-09
Robert's suggestion is quite good.
A simpler, but less secure solution is to have the location of your master password in your Will. Yes this does mean writing it down, but it could be relatively secure: a sealed unmarked envelop locked in a household safe or bank safety deposit box is relatively secure plus simple to update as needed.