Slashdot Mirror
The Best Way To Protect Real Passwords: Create Fake Ones
jfruh writes: Many security-savvy users have a password manager that stores their randomly-generated passwords — but if that manager is cracked, the gig is up. Some security researchers are suggesting a technique to stop this: a password manager that offers up fake passwords when an attacker tries and fails to crack it, which makes the process of figuring out if you've broken in much more difficult.
This just adds an extra step to automate: take the password and try to login. It's not like people are manually trying passwords...
We need a password managers manager!
We need a password managers manager!
... It's password managers all the way down.
Honestly this should be pretty simple. The default operating mode of a password manager should be generate a password from PRNG data.
Store the value encrypted with AES a key derived from a master password extended via PBKDF-2 or similar should be used for the cipher.
Next apply the necessary mixture bitwise rules applied bytewise to the 'clear text' to ensure the password will contain type-able characters and accommodate character restrictions. (Something like x = ((x % 126); x = x | 32 if x 32; for those of us using ascii and yes its not perfect and will produce some bias maybe a crypto expert could propose a better alternative ) Store which rules must be applied as well. That should not be an information leak as the attacker probably can research the target system and divine these requirements anyway.
That will mean most of your passwords are nearly random goblody gook. (Important). No matter what master password is used a key can be derived, the decipher operations and the rules can be applied the result will appear to be a legal password, but it will be incorrect. In the event you have stored a specific less random value it should 'decipher' as well but appear highly random given that is how all your other password appear to be it will not be a strong indicator the wrong key has been chosen either.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
P.S: company eventually got sold to a bigger player and the home grown license manager was retired for industry standard "FlexLm". Soon after, ALL software using Flex were cracked and sold on the warez sites. Pirates could have easily cracked the license manager of that small company, but it is too small to be worth the effort.
Moral of the story: Monoculture is bad, both for Irish potato farmers of the 18th century and license/password managers of the 21st century.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Possibly - but then the best way is just to let any password open the vault.
You cannot crack a password DB if every attempt to open it succeeds. If your means of validating the password you used is to read a stored password, close the vault, reopen it and re-read the password to ensure its still the same.. then you've just added one heap of time to your cracking attack.
Of course, a password vault could return the same set of fake passwords if you failed to supply the correct key (ie when you store a new password, the system generates a fake to store alongside it and returns the correct, or fake one depending on correct unlocking)
No need to re-gen when the vault has been opened incorrectly, just return the bad passwords and let the attacker try to use them. What's even worse than having to re-open your vault to check the passwords are the same, is having to take one of those passwords and use it to attempt login to a 3rd party site to validate whether they were the correct passwords or not!!
If you really want to be a bitch to attackers, you'll expose a few valid entries to honeypots (with passwords that work) so the attacker may think he's got the correct unlock :-)
What you're proposing sounds like Kamouflage (PDF link from TFA), with only 1 decoy password set (Kamouflage suggest 10,000); and suffers from the problem of generating plausible fake master passwords without revealing anything about the real master password, as mentioned by the authors of NoCrack.
What the NoCrack authors try to achieve is a solution where every incorrect guess at the master password still provides a set of (incorrect but at least sometimes plausible) passwords. A bit like a one-time pad, which is the only provably secure encryption, because brute-forcing the key yields all the possible plain texts (both the correct and all the incorrect ones). Of course, the problem with the one-time pad is that the key length matches the plain text length, which would completely eliminate the benefit of a password manager. Additionally, as noted in TFA, authorized users might not like the idea that making a typo when entering the master password yields (seemingly) correct passwords. :-)
I'm not convinced the NoCrack authors have actually succeeded, as they claim, but can nevertheless recommend the NoCrack paper (PDF), since it discusses pros of cons of the approach and alternatives.
Deception is a valid form of security, similar to obfuscation. It should not be relied upon, but it is merely another layer. In the early 90s me and some buddies ran a multi-node BBS. One of the admins used the same password on another BBS, and someone was able to log into our system using his admin account. So to prevent that from ever happening again, I wrote a script that, for the three site admins, would also ask for their birthdate every time they logged in. If an incorrect date was entered a single time, the account would be locked. Thing is, it wasn't our birthdates that we had to enter, but just another very short password that we could enter really easily. So an attacker, if they got to that point again (obtained the password), would give it their best guess (or perhaps even research to find) the admin's birthdate. If any date was entered at all (containing two slashes or hyphens) the account was immediately locked, because the expected password was just a couple letters is all, and anyone entering an actual date was not an admin.
Better known as 318230.
It's better to ask these questions now, before we do have things to hide, like ebanking info. It's been considered that chip-and-pin would eventually push the liability for lost funds onto the consumer on the assumption that the consumer was negligent in losing his PIN. Bitcoin is another example of a thing that if you lose it, it's gone. It's not mainstream now, but I have heard of the Canadian mint experimenting with encrypted digital copies of it's currency (to allow electronic transactions, but ostensibly to make sure the Canadian government is notified of transactions so they can take a tax cut). It's conceivable you would have little to no recourse in recovering these funds. It's better to have the tools before we need them.