7Pass idea: destruct password

I have an idea for 7Pass that I need to put it here so I won’t forget: destruct password. Remember the UK police detained Glenn Greenward and forced him to provide them his passwords? That’s just ridiculous, yet the UK court even later decided that it’s legal for the UK police to do so.  This is a clear violation of human rights, but let’s not talk about politics here.

I’d want 7Pass to have a feature to allow user to enter a password that will destroy all databases already registered in 7Pass. The idea is simple: have a special password that if entered by user, 7Pass just pretend that it’s mad and delete the database plus any other preferences, cache, etc… everything. In order for this to not be suspicious, 7Pass certainly will have to have the feature after if user enters a password wrong, let’s say 5 times repeatedly, the database will be removed from the app. The destruct password (configured by user) will simply make 7Pass shows “wrong password too many time, database deleted” immediately. You can always blame the UK police for playing with your phone.

I’m not sure about the capability of file picking in Windows Phone 8.1, but I’d want 7Pass to first overwrite the local cache with random data first, before deleting it, to ensure no recovery attempt is possible, and, if possible, send a file with random data to the source of the database file, to ensure and 3rd party app, or your phone, or the SD card that provided 7Pass with the original database file will also overwrite it with the random data, effectively destroy every possible source for recovery of your passwords.

If my KeePass database is destroyed, I’ll lose almost everything as I never remember any password. KeePass generates my passwords, and you should be that “forgetful” too; otherwise, you’re not using KeePass to its usefulness. UK police can then hack into my brain and not able to find anything, because they toyed with my phone, damn it, don’t touch it.

Advertisement

10 thoughts on “7Pass idea: destruct password

  1. westernwombat says:

    I think this is potentially dangerous, for inexperienced people (or just if tired and unaware). Perhaps if you do implement it, it would be a settings option with ample warnings, and once switched on the user would be warned (an experienced user would be able to handle 2 separate “Are you sure?” type warnings, default button NO, etc – and still act within seconds to wipe the database.

    I would suggest a name change for 7Pass, too. It’s too suggestive of Windows Phone 7 (and I never had a WP until the Lumia 920). For a long time, I thought it was something still in development for WP7.8

    • I want 7Pass to always have a destruct password configured. However, the default password would be randomly generated to ensure user won’t enter it by mistake. Only users who understand the feature and intentionally set the destruct password that he’ll be able to use the destruction feature.

      Example: generated destruct password is “37044305-edbc-4a3d-9fb8-3ada3419a71d”, auto generated by 7Pass at first run. User can then set it to “007” if he want to use the destruction feature. From then on, entering “007” for any database will automatically make 7Pass show “too many wrong password attempts” and then destroy all databases.

      The destruction password will certainly be stored as a hash with 60000 rounds of transformation. Even if someone managed to take a snapshot of 7Pass app, it’s not possible for him to tell if destruct password is configured or not, since there’s always a destruct password, just not known to the user.

      7Pass: I knew there’s some confusion with the name, will consider it.

  2. If it is a optional feature, it would be great. Since I don’t trust our National Security Authority’s here in Germany, so it could be a great feature. But its a dangerous feature to. I have thousand’s of Passwords in my Database, all of them are generated. Additionally there are my binary Keys for some Programs i have buyed and some SSL private Keys (not only for my own Server) saved. If i loose this data, i loose also access to most of my business.

  3. Sladen says:

    Do you have something implemented to prevent a “fake” app(altered by some one and published in the store under your “name” in the same slot(same app but update), this would only work with microsofts support but i think they would do such a thing) from playing key logger. Or disabling security features. Maybe a list on the net with allowed hash keys for the app or such a thing. But then they could take that out too hmm any thought on that?

  4. If the phone is handled as evidence, they will not try entering the password directly in the phone, but make an image of the data and fiddle around with that, because else the data on the phone would be rejected as evidence by the court. The suggested feature would be useless in this case. Not trying to demotivate, just mentioning it.

  5. Sladen says:

    @Andreas That is only if you, apply the rules of a free democracy.
    But in countrys with secret courts(USA) there is no democracy. Because the public cannot check the court.

  6. john says:

    Its a great idea. I would also suggest to have a fake database. So that you type the fake password and a false database with fake data opens instead of the original one. This would also prevent people from saying that you destroyed you DB on purpose. My offer to be a beta tester still holds 😉

  7. Antinoüs says:

    No, just, no.
    Andreas is definitely right. The data must not be altered by a “destruction password”. Moreover, as the software is open source, anyone could put breakpoints and see that the provided password executes the “destruction” branch. You have now proven that you are deliberately hiding something. Good luck with that in court (especially if justice is really a concern for you).

    The only idea that makes sense is close to what john suggested : more than one database per kdbx file, each one having its own password. The executed code _must_ be the same regardless of which password is given. No notion of “main” or “fake database” in the code : all databases of a file _must be_ of equal value for the software. Then the owner can create his fake database(s) if he wishes to, and _no one_ (not even the owner) would then be able to tell whether or not a given password opens the database with useful/complete data.
    However AFAIK this feature is not supported in the kdbx file format, so you can’t implement that.

    But, please, forget about your idea of a “destruct password”. This is useless as is.

  8. Knobby says:

    I think it’s a great idea. Outside of the ‘James Bond’ situation, which most of us will never encounter, I don’t ever imagine getting arrested or being ‘forced’ by anyone to hand over my password, but having the ability to destroy my database appeals to me. “Sh*t I’ve entered the wrong password and the database has been deleted!” Sounds fair enough in ‘normal situations’ e.g. kids in the school playground being bullied etc. etc. It might result in a punch in the face or an extra dig in the ribs, but better than having all my database compromised. I think it’s well worth it. Nice idea. Go for it!

  9. Otto says:

    I don’t expect any police technical expert to be careless enough to try to open the password database on the actual seized evidence device using the software installed on it. Equipment seized as evidence is untrustworthy per say. Instead he would probably copy over the keepass database onto a police lab computer and open it there. So your only chance would be to enter the wipeout password before the authorities get their hands on the device. And not even then would you be really safe since the underlying operating system wont necessarily overwrite the actual data on the storage media. Somehow the software would have to be able to ensure the memory area gets wiped out on a filesystem level which might not be possible on the majority of devices. So while implementing this would have some use, there is also a risk that users are given false feeling of security.

    Its good to acknowledge that anything happening to the password database after being captured is no longer under control of your software and consider alternative approaches like physically destroying the device or to me more specific – its memory. I guess making a exact mark on the phone cover where the memory chips are located in the phone and driving a 9 inch nail through it using your shoe as a hammer would be a low-tech but fairly quick and effective approach. And it only requires you to carry a nail with you at all times.

    Unless of course your phone has been making backups into a cloud …

Comments are closed.