Decoy vaults

jdelmanjdelman Junior Member

I just read an article about having decoy vaults with fake passwords that would make it difficult for anyone attempting to crack the master password to know if they had done it successfully. Would be an interesting optional feature in 1Password...
http://www.itworld.com/article/2921395/the-best-way-to-protect-passwords-may-be-creating-fake-ones.html

Comments

  • Available evidence (c.f., [4]) suggests that most master passwords selected by users are weak in the sense that even a modestly resourced attacker can feasibly crack them in a matter of minutes or hours.

    In general, yes. I would take a guess that people that choose to use a password manager are choosing stronger master passwords than the average. Certain the advice that Agilebits gives out is to use a properly randomised password.
    https://blog.agilebits.com/2011/06/21/toward-better-master-passwords/
    https://blog.agilebits.com/2011/08/10/better-master-passwords-the-geek-edition/

    Another possibility would be to auto-correct the password if it is just slightly off, he said.

    LOL. Just LOL.

    The fundamental problem I see with this whole thing is, how does the actual app or service distinguish between the right and wrong master password? I think that 1Password has a little piece of known data that the 1Password apps can look for to verify that the correct MP has been entered. There is nothing to stop an attacker doing the exact same thing and thereby bypassing the entire "fake vault" concept.
    It is telling that:

    The user and/or the browser is responsible to distinguish the domains where the user has an account

    so basically if this "password manager" were asked to display the user's logins to them, it would display all of the fake accounts as well as the real ones.

    Any comment @jpgoldberg

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member

    Hi, @jdelman!

    I'm really pleased that someone brought this up. I actually talked with the authors of the paper back at the Usenix conferences last summer about this project. And so I was excited to see the paper (PDF) come out a few days ago.

    I think that what they've done particularly in terms of combining honey encryption **(HE) with **probabilistic context-free grammars (PCFG) is phenomenally cool. As a once PhD student in Linguistics, this really is right up my alley.

    It's not really fake vaults

    NoCrack isn't based on fake vaults. The paper outlines what is wrong with actually having a number of fake vaults in the sense that you actually store multiple encrypted vaults, each encrypted with its own Master Password. Indeed, the paper starts with a rather scathing (all in academic politeness, of course) review of one full fake vault scheme.

    Instead it is a scheme where there is only one data store, but it will decrypt as "plausible" under incorrect master passwords. That is, suppose that a genuine password for some site is Tr0ub4dor&4 but that when using the wrong master password the ciphertext actually decrypts to 2bon2btitq.

    This way you don't have to store thousands of copies of fake data. It's that given the wrong key, the one copy of the data will decrypt as something that kinda looks like a password that someone might create. The stuff that they put together to achieve this is just fantastic.

    I really do want to see that cleverness put to use, but when it comes to actually being useful for password management, it has one big problem and lots of smaller ones.

    Password data must be the only thing encrypted

    The scheme works by making an incorrect key decrypt the passwords as plausible passwords. That is, there should be no specific way for the attacker to tell whether the passwords that she got are real or fake without having to go an try to use them. This is fine for password, but it doesn't work for anything else that is encrypted, for example, a username, notes, or all of the other information that people may want encrypted along with the password.

    It's one thing to make an incorrect decryption produce a plausible password, but it is another all together to produce plausible (but incorrect) other data. So the attacker will be able to look at the other data and see whether they have a correct decrypt.

    So to use this scheme in 1Password, we would have to either leave everything that isn't a password unencrypted or have two Master Passwords, one for the password data and one for the non-password data.

    Other issues

    The scheme assumes that each user's password data will have the same statistical properties of aggregate password data. Now this can probably be fixed, but because only those who actually crack password manager databases know what that data really looks like, it is going to be hard develop spoof data that fools the crackers.

    It also throws out any ability to use authenticated encryption, and so makes it much harder to achieve CCA (Chosen Ciphertext Attack) security.

    For what it is worth, you can see some of my tweets in response to

  • jdelmanjdelman Junior Member

    Thanks for the clarification. It's definitely an interesting idea, but the issues you bring up make sense and don't seem to have any simple solutions...

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member

    What they have might be more useful for situations in which a server might store encrypted (instead of hashed) copies of a passwords. But servers really shouldn't be doing that.

  • Check out this great article about NoVault. Some researchers found that by presenting a FAKE vault when an incorrect password is entered (instead of saying "Invalid password") is more effective at slowing attackers down. This sounds like a great feature for 1Password!

    http://www.networkworld.com/article/2921393/security/the-best-way-to-protect-passwords-may-be-creating-fake-ones.html

  • Drew_AGDrew_AG 1Password Alumni

    Hi @captbrando,

    Thanks for taking the time to contact us about this! Someone actually asked us about that article just a few days ago, so I've merged your message into the existing discussion. Our security guru had some interesting things to say about that idea, so make sure you take a look at his post from earlier this week.

    If you have more questions or thoughts about that, please let us know! :)

This discussion has been closed.