dB Self Destruct Sequence

Logged In: NO

What purpose could these features possibly serve????

Logged In: NO

In regards to these features I can see where this is going.

Option #1 (practical in many users environments)
You could give someone the on time use password so they
can get into the file and get a password out. However to
improve on this thought I would also have the database open
with the disable unsafe operations preventing printing,
copying etc. This would allow someone emergency access to
the dB. Say you are on vacation and that co-worker just
needs quick access for a piece of hardware password (i.e.
router). Fine here is the one time use password that will
allow them read-only quick access then they are locked out
from going back in again for a quick snoop of the rest of
the passwords.

Also great for plausible deniability I gave you the
password you opened the password database now what did you
do to it? What do you mean I gave you the password you
saw it worked

Option #2 (Pure paranoia)
This is easy, again plausible deniability I think the
password is this and wham the database is destroyed.
Perfect if you find yourself in a situation of being forced
to give up your master password. Nothing better than a
corrupt database.

Say you keep all of your encrypted file passwords in keepass
and you are asked by someone (law enforcement, mafia,
ex-place of work, al qaeda, terrorist, dilbert, ex-wife) to
give up the password to your password database, you can give
them the corrupt that database password instead making the
copy they have trash. This put keepass into the realm of a
true users security tool that protects the data at all
costs. Once more the scramble the database password could
be made easy so that some moron trying to guess your
passwords will kill the copy of the file they have obtained.

Comments:
Some people do have multiple copied of the keepass dB and
keep backups at work on other places they probably should
not so why not build in a purposeful obsolescence into the
program. For that matter even a simple warning and reset
flag to kill a database after a specified time period would
be nice.

Again, this is basic to most security token/pass devices.
For instance GEM security cards self destruct after so many
invalid attempts. I would not suggest this for keepass but a
basic (user settable) password that kills the database would
have the same effect and take longer to get at and prevent a
denial of service attack while still protecting the
underlying data.

Logged In: NO

I.E. What the rest of the world is doing with security
devices... SIMILAR TO THE SMART CARD IDEA ....

...some article snips...

"Smart cards can be programmed to self-destruct when an
unauthorized party probes it. "

"He added that the chip in the card is designed to
self-destruct if tampered with. "It's never been cracked to
anybody's knowledge," Vanderhoof said."

"Security One of the primary security risks pertaining to an
enterprise smart card program stems from lost cards. If a
card is lost and not reported as such immediately, there is
potential for an unscrupulous person to find that card and
use it to gain unauthorized access to enterprise physical or
digital resources. There are measures that can be taken to
mitigate this risk, though. First, cards that have a PIN
require that the cardholder enter the correct PIN to gain
access to the services on that card. Additionally, some
cards can be set to self-destruct if the user makes a
certain number of failed attempts to enter the correct PIN.
There must also be policies and procedures in place that
address how to handle the situation when a card is lost. For
example, administrators should modify accounts to block
access from cards that have been reported as missing or stolen."

Logged In: NO

Ah yes very much like current security devices i.e. Smart
Cards that destruct when tampered with... article snip below...

"smart cards can be programmed to self-destruct when an
unauthorized party probes it."

Logged In: YES
user_id=999143

Keepass is open source. An attacker who knows the
software would compile the app for his needs. Self
destruction does not work.

Logged In: NO

I say another wall of defense is still worth it to protect
all that is behind it.

Further, as the programming code would be so small compared
to the weight of the threat it would harden Keepass to those
idle minds that use commercial software to steal passwords.
Lord knows that half of security is the-know-how and many
just DO NOT know and use someone elses solution to gain
entry rather than making up their own. Thus, open source or
not having a self-destruct, scramble the dB, stumble upon
basic password trip-wire or something along these lines
would thwart those feeble minded.

Logged In: YES
user_id=589094

Any law enforcement attempts to break in to the database
will be preceeded by a bit-for-bit copy. However, someone
less versed in security procedures might push you to tell
them a password which they then enter, not thinking to make
a DB backup. Destroying the contents of the file upon
entering the 'distress' password is a pretty neat idea.

I suppose one could hedge by having the concept of a
secondary password not known by the owner. IE, Alice asks
Bob to type in an 'emergency' password which she never looks
at. When Alice tells mafia man Fred to enter the distress
password, the database is automatically recoded to only be
readable by Bob's password. Obviously, Bob should be
concerned when Alice calls him asking for the password at
gunpoint.

Logged In: YES
user_id=589094

I suppose as a further measure, instead of destroying the
whole databsae, it could replace all the passwords with new
randomized passwords. Suddenly all of Alice's accounts have
been disabled...

Logged In: YES
user_id=1154212

I would imagine that implementation of these features would
bulk up the software... With as many people not using the
advanced features of keepass I wonder if it would be worth
the time, effort, and extra coding?

Hi Dominik,

thanks for developing this great program. How about this feature:

Feature description

When opening a database with KeePass a password is required, of course. KeePass should allow to set two different passwords for a database. One password that normally unlocks a database. And a second optional destruction/emergency password that destructs the database and it's contents.

The feature could function like this: On selecting a database file KeePass should open the password entry dialog just like it does now. When the user enters the regular unlocking password, the databse gets unlocked and can be used as usual. But when the user enters the destruction/emergency password, the database file and its contents are destroyed so that it is completely empty. Just like unlocking passwords are individual for each database file, the destruction/emergency password should also be individual for each database file.

Benefits

This would be a super security feature, because sometimes a user might be in a situation where he is forced/pressured to open his database. With this suggested feature he could just type in his destruction/emergency password and pretend that nothing is or ever was in there. And the people who pressure the user would never be able prove the opposite (concept of Plausible Deniability).

This feature would also help agains brute force attacks. A user could set a very simple destruction password like "password123" or "abc123". A brute force attacker who will try this combination for sure would destroy the database file pretty quickly. This way the user is protected even more.

Alternative implementations

Instead of destroying the database the destruction/emergency password could display a fake version of the database contents with only uncritical data that the user has saved inside this fake database portion of the database file. Basically it's a hidden database inside a database (like TrueCrypt does it with their concept of Plausible Deniability).

A database file could also offer the user to enter three different passwords:
1) regular unlock password (always required)
2) emergency password to open fake database content (optional)
3) destruction password to completely desctruct all contents of the database file (optional)

Concluding Thoughts

I think the benefits described above would make KeePass the most secure password manager in the world. Also it would add an outstanding characteristic to KeePass that would make your app unique.

Please consider implementing this feature.

Thanks
Marcos

This would be a super security feature, because sometimes a user might be in a situation where he is forced/pressured to open his database. With this suggested feature he could just type in his destruction/emergency password

Under duress we humans revert to habit, so the password we would recall would be the real one.

Instead of destroying the database the destruction/emergency password could display a fake version of the database contents with only uncritical data that the user has saved inside this fake database

If you are paranoid enough to add dummy data then you are prepared to put in time and effort. Veracrypt requires much less time and effort and provides the feature you desire, so why not use it instead?

cheers, Paul

Under duress we humans revert to habit, so the password we would recall would be the real one.

This does not apply to all people so this isn't a valid argument against the suggested security feature. It's like saying "We do not need door locks just because some people tend to give their keys away to strangers."

If you are paranoid enough to add dummy data then you are prepared to put in time and effort.

This requires an additional program like veracrypt and it's tedious to enter two different long passwords to open a database. Adding it into KeePass would make it more convenient and more secure.

And you haven't taken into account one bonus security feature: better protection against brute force attacks. A user could set a very simple destruction password like "password123" or "abc123". A brute force attacker who will try this combination for sure would destroy the database file pretty quickly. This way the user is protected even more.