Decoy passwords, and why most of them do not work

"Enter a second password and see different contents" is not a new idea. Photo vault apps have shipped it for over a decade, and dozens on the App Store offer it today.

Most of them fail at the only moment they would ever matter. It is worth understanding why, because the failure is not about encryption strength. It is about something much more ordinary.

The test

Imagine the person you hand the passcode to has used this app before. They have it on their own phone, or they read about it, or they have seen one on somebody else's device.

They type the code you gave them. The app opens.

Does anything they can see tell them this is the decoy?

That is the whole test. Everything below is about the different ways an app fails it.

Failure one: the decoy is a different screen

The common implementation is a branch in the interface. The app stores two passwords, compares what you typed against both, and shows gallery A or gallery B.

This has two problems.

Both passwords exist on the device. They are in a database, a preferences file, or the keychain. Recover the storage and you recover both, and with them the knowledge that there were two. Encryption of the photos does not help, because the app has to be able to check a password it was given, which means it kept something to check against.

The database says there are two. A column called is_decoy, a vault_id of 2, a row count. An examiner reading the app's storage does not need to break anything. They just read it, and now they know to keep asking.

Failure two: the decoy is visibly a decoy

This one is subtler and, in practice, worse.

Many apps make the decoy a reduced version of the real thing. The real vault has settings for creating and managing the second password. The decoy does not, because why would a fake vault need to make fake vaults?

The result is that the decoy is missing a feature the real one has. Anyone who has seen the app before opens it, glances at the settings, sees a section that should be there and is not, and knows in one second exactly what they are looking at.

At that point the person who handed over the passcode is worse off than if they had never installed the app. They have not protected anything, and they have visibly tried to, which is a far more interesting fact than anything in the vault.

Failure three: the app announces itself

An icon with a padlock. A name with "Vault" or "Secret" in it. A listing that promises to hide things from people.

None of this is a cryptographic weakness. It is just a sign on the door. The app does not need to be found and broken if it can be pointed at and demanded.

What passing the test requires

Three properties, none of them exotic.

Nothing stored to compare against

The passcode must not be stored anywhere, in any form, including a hash. It should be typed, used to derive a key, and forgotten.

The consequence is severe and non-negotiable: a forgotten passcode cannot be recovered by anyone, including the developer. Any app offering you a recovery option is telling you it kept something, and whatever it kept can be taken.

Nothing on disk that counts the spaces

If the storage holds three encrypted blobs, an examiner knows there are three things. The fix is for the storage to look identical whether it holds one space, five, or none.

The usual approach is to allocate every slot at first launch, fill them all with random data, and pad every real one to exactly the same size. Encrypted data and random data from a good generator are drawn from the same distribution. Nothing separates them without the key.

This is why these apps cannot offer a "how much space am I using" figure that varies. Any number that moves is a number that leaks.

Every space identical

This is the one most implementations miss, and the one the test above is really about.

The decoy must not be a lesser version of the real thing. Same settings, same sections in the same order, same wording, same ability to create spaces of its own, same error messages. There must be no badge marking one as the original and no feature that only the original has.

The corollary is that there is no "top". A space should list the spaces it created and never the space it came from, so that somebody who opens one cannot tell whether they are at the first one or three levels down.

How to check an app yourself

You do not need to read anyone's source code. Four questions get you most of the way.

That last one deserves a word. Flash storage does not honestly overwrite in place, so scrubbing bytes is theatre. The stronger answer is that deleting discards the key, which makes the remaining bytes permanently unreadable and keeps the file count from dropping in a way that shows something was removed.

Where Vessum stands

Vessum was built around this test, and it is the reason for several design choices that look strange otherwise.

Every space has the same settings and can create spaces of its own, nested as deep as you like. There is no primary space and no flag marking one as original. The storage is twenty-four fixed-size slots, all written with random data at first launch and all full from that moment, so a slot holding a space and a slot holding nothing are the same number of bytes of high entropy data.

And there is no passcode recovery, because there is nothing stored to recover it from.

There is one limit we state plainly: that Vessum is installed is not hidden and cannot be. Anyone looking at the phone can see the app and can see that it holds encrypted data. What stays hidden is how many spaces exist and what is in them.

If you would like to try to tell an occupied slot from an empty one yourself, the home page runs the real cryptography in your browser and invites you to pick which slots hold something. Nobody does better than chance, which is the point.