I don't have any experience or scientific knowledge in security, I just wanted to ask if this is possible because I am interested in it.

What if I encrypt data and every password decrypts it, but only the right one does not create pointless data clutter? Same could be done with a login: false login data leads to fake, dummy accounts and only the right login details get you to the right accounts.

Wouldn't this be a way better method of encryption because you couldn't just try out passwords but had to look at the outcome to see if it was the right one?

  • 12
    Sounds like a one-time pad. Commented Jul 12, 2016 at 23:56
  • 47
    A honeypot or a spamtrap is a system whose purpose is to waste the bot's time. Commented Jul 13, 2016 at 5:23
  • 6
    it would only work online, and you shouldn't be able to brute-force online passwords in the 1st place...
    – dandavis
    Commented Jul 13, 2016 at 8:45
  • 13
    Well, when trying to brute-force encrypted text that's what you have to do. There's no magic bell that tells you when you got the deciphering right, you have to look at the output and check. If someone encrypts a zipped file and you only check if your attempt produces plain text you'll never be able to decipher the text even trying out all possible keys.
    – Bakuriu
    Commented Jul 13, 2016 at 9:32
  • 6
    @Bakuriu: most practical encryption system includes a hash, which tells you when you've got the decryption right. Also, some encryption schemes, e.g. full disk encryption, are designed so you can do random access efficiently, so you don't need to decrypt the entire volume to know you've got the right decryption key.
    – Lie Ryan
    Commented Jul 13, 2016 at 12:26

9 Answers 9


The answer always depends on your threat model. Security is always woven into a balance between security and usability. Your approach inconveniences the hackers trying to break into the account, but also inconveniences a user who merely mistypes their password. If the fake account is believable enough to fool an attacker, it may also be believable enough to fool a valid user. That could be very bad.

This may be desirable in extremely high risk environments. If you had to store nuclear secrets out in the open on the internet, having every failed password lead you to an account that has access to fake documents which don't actually reveal national secrets could be quite powerful. However, for most cases it is unnecessary.

You also have to consider the alternatives. A very popular approach is to lock the account out after N attempts, which basically stops all brute force attempts cold, and has usability behaviors that most users are willing to accept.

  • 7
    When it comes to possibility, the only limit woudl be the question of how realistic of a dummy account are you interested in taking the time to create. An interesting place to look for data on that is deniable encryption. In deniable encryption, you create a dummy partition, and make it impossible for the attacker to prove any other partition exists mathematically. That community has shown a great deal of interest in how to make the dummy partition look legitimate.
    – Cort Ammon
    Commented Jul 12, 2016 at 21:39
  • 13
    Such an account can also be used as a honeypot that trips security sensors when someone logs in there so you can detect an attacker early.
    – Johnny
    Commented Jul 13, 2016 at 1:05
  • 5
    The problem with honeypotting a login attempt is the valid user won't realize these aren't real plans so they build nukes that don't work right. I hope your fake plans don't break the safety checks. Most effective method I've seen is to force users to wait longer and longer between login attempts. Force them to slow down and think about what they're typing. That way when they hit the N attempt limit it's not a surprise. Commented Jul 13, 2016 at 11:24
  • 2
    A combination, where after a few failed attempts (3?) rather than locking you out of your account brings you to a fake account would certainly be interesting. As a side note, I once worked at a place where the user table PK was user+password. Commented Jul 13, 2016 at 22:00
  • 3
    @DamianYerrick That is very true. The DOS issues are one of the main reasons I only listed it as a popular alternative, not a solution. In some environments that risk is low enough to accept. In other environments, it's completely unacceptable.
    – Cort Ammon
    Commented Jul 14, 2016 at 3:22

Fooling an attacker with false positives isn't a bad idea, and it's not new. The following may interest you.

Cryptographic Camouflage

CA technologies has patented a technology known as Cryptographic Camouflage.

A sensitive point in public key cryptography is how to protect the private key. We outline a method of protecting private keys using cryptographic camouflage. Specifically, we do not encrypt the private key with a password that is too long for exhaustive attack. Instead, we encrypt it so that only one password will decrypt it correctly, but many passwords will decrypt it to produce a key that looks valid enough to fool an attacker. For certain applications, this method protects a private key against dictionary attack, as a smart card does, but entirely in software.

This isn't exactly what you are talking about (they're protecting a key, not access) but the concept is the same. You foil a brute force attack by making it difficult or impossible to determine if you've actually cracked the code.


In 1984, Michael Crichton (author of Andromeda Strain and many others) wrote a short story centered around a hacker who thought he was stealing top secret files. He had guessed the right password, but unbeknownst to him, the computer was actually authenticating him not by looking at his password but at the speed and manner in which he used the keyboard and mouse-- sort of a biometric authentication mechanism. He failed authentication. But the computer didn't tell him he failed-- instead, it presented him with a false copy of the secret documents, which he then downloaded and attempted to sell on the black market.

Again, this is not exactly the same as what you are asking, but it demonstrates (in fiction, anyway) the use of false positives to thwart an attack.


To give you a straight answer, yes, it is possible to reduce the effectiveness of brute-force attacks and it can be done the way you suggested, but shouldn't. You can get very similar results just by implementing timing delays between each failed attempt and the next guess. Also, (just for your knowledge) very sophisticated and similar technologies have already been designed and implemented for this exact thing. Products like Canary, Honey Pots and Honey Docs all deliver similar things like fake environments, devices, servers, accounts etc.

  • Ok, but what about encryted files. You cant put a delay between failed decryption tries, can you?
    – Tweakimp
    Commented Jul 13, 2016 at 4:50
  • 1
    I don't think you can really make enough fake sets of files in an encrypted container reliably fool an automated cracking tool either. If the attack has the possibility of an offline attack, you must rely on other hardening techniques like key derivation functions that are slow to limit the number of tries per unit of time. Commented Jul 13, 2016 at 8:32
  • 1
    @Tweakimp, you may be interested in "TrueCrypt hidden volume." That sounds like what you're describing. (But it only has two passwords, not infinite.)
    – Wildcard
    Commented Jul 15, 2016 at 3:45
  • @Wildcard Thank you, I will look at it. Two sounds way smaller than infinite though ;)
    – Tweakimp
    Commented Jul 15, 2016 at 6:21
  • @SimonLindgren that is until Quantum computing becomes a reality where the tries per second reach new heights. So then, the key derivation functions would also have to increase. Commented Jul 16, 2016 at 17:08

The effect is tiny

Let's suppose that your system transforms practical brute force from decrypting the first four bytes (realistically, the first much larger block, but whatever) to having to decrypt the full e.g. four gigabytes of encrypted data, making bruteforce attempts approximately billion times or 2^30 times slower.

Now, that might seem a big difference to you, but actually that effect is tiny compared to other alternatives. A scale of simply "billion times slower" is simply not that much in the world of cryptography. Why bother with added complexity that might fail to achieve the intended slowdown or introduce new bugs, if simply adding extra 30 bits to the encryption key length does the same thing, and increasing the key size from e.g. 128bit (if that's not already enough) to 256bit provides an incomparably much larger effect than that?


Most already has been said, I just want to offer another perspective.

Imagine you would try to secure a house with this technique. You would let the intruder give access to a cellar room if he tries to open the door for some time.

The question is, would you want an intruder even there? The intruder will most certainly realize that he didn't get what he wanted after some time and try to get further from there. And you would have to maintain the extra security for the cellar you prepared.

So in a way, you only increase the amount of work for yourself to fool (inexperienced) attackers for some time.

  • Because if I did it in a good way, the intruder wouldnt know (for some time) he was in the fake room and couldnt even be sure if he was in the right one when he gets in. Also, looking in the room takes time, so you cant just test the door for a key but have to look in the room every time which will take up way more time to brute force your way trough.
    – Tweakimp
    Commented Jul 13, 2016 at 11:36
  • 8
    Yes, I can see what you mean. My point is: Setting up and securing the fake room in a good way requires your time. Time you could better invest in securing the "front door" in the first place. :)
    – gpinkas
    Commented Jul 13, 2016 at 12:14
  • 1
    Proper access control for legitimate authenticated users is already a necessity anyway; I can't see how it would be any extra work for a fake account.
    – Michelle
    Commented Jul 14, 2016 at 13:11
  • That's right, but securing the whole access control is a lot harder than securing the login screen. It's a necessity, but it's nearly impossible to have perfect security in place. With this scheme you let a possible attacker one step closer into your system. In most attacks, gaining access to ANY account in a system is the first step to gaining root privileges.
    – gpinkas
    Commented Jul 14, 2016 at 13:41
  • 2
    This is a nice recent example for privilege escalation: theregister.co.uk/2015/07/22/os_x_root_hole
    – gpinkas
    Commented Jul 14, 2016 at 13:44

Sounds like you're talking about a form of "deniable encryption" or "plausible deniability" in the context of crypto; that is, an alternative secret that decrypts to plausible but non-authentic plaintext. See https://en.wikipedia.org/wiki/Deniable_encryption for details.

But strictly speaking, if someone has the capability to bruteforce your ciphertext, they will potentially discover all plausible plaintexts, and then, based on any knowledge they already have about the context, they will be able to decide which of the plaintexts is the authentic original one. The first part can be done by pseudo-AIs, but the second part still needs a human.

  • 2
    Using a one-time-pad every possible message is equally probable, you have no way of knowing what the original was without the original key. As an example, "Meet 3pm Wed" is equally as probable as "Meet 9am Tue" or "Done my task" - context doesn't always help
    – Dezza
    Commented Jul 14, 2016 at 11:03

The problem with keys is they exist as data and not as running code. Even with the CA and Crichton example, what happens is an out of band procedure occurs that provides you with reasonable responses for each decryption try. Mathematically this is impossible on the level of a ciphertext and brute force attempts.


For remote access, as others have said, simple lockouts and delays can work.

For passwords, what you have is a one-way hash. To validate the password, you re-hash it, and compare the two hashes. Having more than one simple password produce a valid match against a single hash is considered undesirable: it means the hash is weak, and has "collisions".

So it's lkely that you are interested in encrypted drives.

What you describe -- fake, "outer" drives filled with fake data protecting the encrypted "inner" drive -- is possible, and has been done in truecrypt (which sadly has since died).

The following is my own naive understanding, and some or all may be wrong. I never used this feature, but considered it interesting.

Truecrypt allowed you to specify a second password, which would unlock a "layer" of the encrypted drive (might've been limited to one outer container, I forget). This had clear problems; the outer drives were unaware of the inner ones, which were stored in the "empty space" of the encrypted outer drives. So changes in the outer ones could destroy the inner drives. Also, the datestamps on the inner drives were not automatically updated when you accessed the encrypted drive. So someone with access to your machine could tell when you'd last modified the encrypted drive's file, and could compare those datestamps to the last-modified times on the encrypted drive, and immediately tell that you'd been using it more recently, so there must be an inner drive.

But the idea was, you have the outer drive have an easy-to-guess password, like password123, put some vaguely secret stuff in there, and that would make your opponents think they had got into your encrypted drive.

Anything less - anything which just returned garbage (random noise equivalent to an unformatted drive) would have been trivial to get around by checking for a "magic string" on the decrypted drive that would be required on any real drive but unlikely in a garbage drive.

Same with encrypted documents: most filetypes have magic strings, so if you know what filetype is contained, then any scrambling that's done can be brute-forced to find all ways that produce the magic string.

That doesn't mean it's a bad idea, though - if the magic string is, say, "jfif", then only about one in about 16 million passwords will result in that magic string. But if the key length is, say, 2^1024, then they've only reduced that to 2^1000 - which, sure, is certainly 16 million times faster to crack, but will still take literally forever to crack.

Casual password typos wouldn't make someone think they'd decrypted the file, but simply looking for the magic string wouldn't be enough.

  • 2
    You're missing one point: To unlock the "outer" drive, you were supposed to type both keys. That way you could make changes without destroying the inner drive. But when an attacker threatened you with a wrench, you could just tell him the outer key and it would successfully open the drive, with no evidence that there was an inner drive—and hence, also, no way to protect the inner drive.
    – Wildcard
    Commented Jul 15, 2016 at 3:51
  • @wildcard Ah, OK. Though sadly, the timestamps on the "outer" drive will probably still make it fairly clear that you were actually only active on the inner, unless you're caferul to mount and access both, possibly with a script on the inner to manipulate the outer. Commented Jul 20, 2016 at 1:26

Something like this was actually done in some versions of the RAR compression software (in the early days, not sure if it still is like this). An encrypted archive would be decrypted by any password entered, but a wrong password would result in gibberish output. It was done to prevent brute-forcing of passwords which at the time was feasable for ZIP archives which immediately returned a "wrong password" error.

  • 1
    Actually, with zip not all passwords lead to the "wrong password" error. That quick reject happens for most of them (and thus a user mistype "always" encounter it), but if you are bruteforcing the passwords, you will get lots of false positives on the crc32 (it is based on a 1-byte or 2-byte crc check) that need to be verified by either fully extracting the file and then realising the extracted crc32 doesn't match or -if you are lucky- by looking at known plaintext at the beginning of the file to be extracted.
    – Ángel
    Commented Jul 16, 2016 at 0:13
  • Maybe this is new? I'm talking 20 years ago.
    – Tom
    Commented Jul 16, 2016 at 10:07
  • I am talking about traditional zip encryption, ie. the one that was available 20 years ago.
    – Ángel
    Commented Jul 16, 2016 at 23:00
  • I think I know precisely what you mean: I remember also trying to find back my password for an large archive, then WinRAR would first "extract" the whole archive before telling me that the password is wrong. I think this should be linked to an era where proper key stretching methods were not common, WinRAR used this method to slow down brute force attacks. Commented Jul 17, 2016 at 8:14
  • Such methods make brute force efficiency directly dependent on the archive size, which is not a good thing: small archives will be less protected, adding useless files to it would increase the security, it's just too hacky. Here come proper key stretching methods which allow to put a constant time for the password checking process, independently of the archive size: small archives are given the same level of protection against brute force than larger ones, level depending only on the chosen algorithm and parameters, which is obviously cleaner and therefore safer. Commented Jul 17, 2016 at 8:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .