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...
I have a pile of post-its. One contains the passwords. The other contain also all kinds of notes, as well as old passwords and shopping lists. Main difference with the proposed method in TFA is that hackers may still have access to the digital fake passwords, but will never get my post-its.
Obviously, these can get stolen too. But only a trusted select few people have physical access to this, and even they don't know which post-it to take. And no hacker is going to physically break into my place to look for post-its. I'm just not important enough for that. Burglars would steal the computer (which has only unimportant passwords stored on it), not post-its with random notes.
In other words, I'll stick to my "system".
We need a password managers manager!
We need a password managers manager!
... It's password managers all the way down.
Honestly I would be much happier with users writing down their password and putting it in a locked cabinet under the desk then picking "Password123" for their accounts. For anything serious users should be demanding multi-factor authentication.
Ceci n'est pas un password.
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
I've always heard that SSH keys are better than passwords. So I use them even with websites that don't use SSH.
Here's what I do:
1) I generate a new keypair using ssh-keygen.
2) I put the public key in my GitHub repo, because the public key is meant to be shared.
3) I use the private key as the password when I sign up for a new account on a web site. I copy and paste it into the password input since it's too big for me to type in.
4) When I have to log in to the web site I copy and paste the private key into the password input since it's too big for me to type in.
5) I live my life knowing that I'm using the most secure password possible: an unbreakable SSH key.
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
As the maker of a password manager, I'm curious how this is supposed to work. The article is a bit sparse on information.
Suppose I'm the attacker and after say, ten guesses the fake passwords are shown. So if I now save the passwords, will the original ones be overwritten? I guess not, since that would be rather inconvenient. So if not, will the fake passwords along with the master password and the original data be stored in the password database? Than the attacker can check the length of the original file after saving to determine whether he has obtained fake passwords. Or are they assuming some mysterious online password application where the user has no knowledge of where and how his passwords are stored? In that case, the application will be insecure anyway.
I suppose the right way to make this work is by saving fake passwords (or the space for them) along with the real ones all the time but encrypt them separately with the fake master password after it has been created on the fly. Thinking about it, I might add this as an option to my program.
Instead of feeding that password managers with fake passwords why don't we fill it with distress passcodes that will lead the attackers straight into the honeypot?
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
"There is, however, one large problem: What if a person mistypes a password? In that scenario, a fake vault is generated, and a user is locked out of his or her accounts."
This is the weak point - It forces the user, or the system, to generate an additional artifact to inform the user (but hopefully not the attacker) that the password safe is correctly unlocked.
"One possible fix is to create a hash of the master password that is linked to an image that is shown when the password is entered. The authorized user should recognize when the wrong image is displayed, but an attacker would not."
I'd expect this one image to be shown only when the master password is entered. i.e. it is an unique indicator. Fake images will need to be generated for all other passwords, and if there are duplicates then they can be eliminated as false-positives. Strategies like this will always be the weak point. It's commendable that they're attempting to fix the problem, lets just hope the additional complexity doesn't weaken the system overall.
Am I the only one who thought to himself "Do I actually have anything to hide that would justify this much effort?"
If somebody hacks my ebanking account, chances are the bank would be liable unless they could prove I have been negligent. And besides, this whole security thing becomes rather funny when you think that my bank is the only site which limits my password length to seven digits.
This is like a company that puts up draconian password restrictions, does not trust just hypervisors but also switches, cables and the air when it comes to DMZ but at the same time has the SAME admin credentials for every customer and their own environment that they NEVER change. So basically, every fired employee could walk into a customer's office and connect to just about anywhere.
This discussion is like trying to fix a nail hole in your barn when somebody's blown through the barn door with a tractor.
This was a standard feature of the password keeper in Ericsson phones 10+ years ago.
this would be improved if the password manager provided a password that when used, an alert was issued and actions were taken
This security mechanism is pointless. The only way that this would work is through obscurity. If you know the algorithm to check the data file itself in the same way the password manager does, you just offline attack the actual database. Once you reverse engineer the password vault software's behavior, you can go straight to the file instead of being a dumbass and typing things into the program itself.
I can't think of a single attacker (other than maybe a teen's mom) that would repeatedly type passwords into the vault's frontend. The solution for that is already straightforward: use a secure password instead of your dog's name. For non-trivial brute-forcing, attackers should already be using a heavily customized program to brute the store itself.
The problem with giving out a fake password would be that the real user ends up locked out of sites or systems due to too many bad password attempts.
I use a password manager. It has a very strong a password on it. Is it really that hard for people to remember just one really strong password?
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.
so then my password manager opens up and tells them about accounts they did not know about ..
and gives them access to all the files i store in there? no.
Everyone in IT circles automatically puts down any technique that is "Security by obscurity", but no one in the military (or mother nature) would say camouflage does not work. There is a time and a place for it. Sometimes, just the camouflage alone is sufficient to stop an attacker. Combined with other measures, it is a proven to be effective.
Yeah.. my thinking also... this thing seems kind of silly anyway. Seems like they would know pretty fast none of the passwords work. Maybe if they worked with the sites and had a "distress password" which would open up a fake account and start logging information. But again, lots of complication, if they have gotten to your password manager there is already a problem.
I assume this solution would be based around the app providing bogus passwords if you enter a bad master password. I suppose that would be something you could do for foiling the petty pickpocket or keystone cop. But surely any attacker that actually plans to succeed will use a cryptographic attack against the data store, not poke random keys on the UI.
I have wondered before if security could be improved by storing an encrypted file inside another encrypted file, ideally with different schemes. But from a serious attacker standpoint I don't really know what I'm talking about. It sounds good, but probably would only prove vaguely annoying, rather than mega-secure.
I wish i had mod points left :-)
when it consisentently give up passwords you can log in with - your in
All the password manager needs to do is take the name of the account want a password for, tack on the ow manager password, hash it. That's what it returns as the account password
There done. No need to check if you entered the right password for the manage. No need to even have a password management database. Or pay for anything since it's a one line perlscript. Since the ow manager has no clue if you entered their right password or not it won't give it away. One can think of embellishments to allow you to change your password
Some drink at the fountain of knowledge. Others just gargle.
+1 Using this image as a keyfile will certainly make your stuff safe (and if you lose it, you can count on it being posted to every /. article ... ).
"If you have nothing to hide, you have nothing to fear." - Every fascist, ever
Firefox has had a plugin for a long time, the "PassHass" from wijjo.
I have used it for a long time.
https://addons.mozilla.org/en-us/firefox/addon/password-hasher/
Get of my lawn!
Comment removed based on user account deletion
The word is "jig," not "gig."
Have the password manager generate multiple passwords for each site. Associate each one with a randomly selected image. When the user wants to retrieve the password from the password manager, show all of the images and associated passwords. User will know which password is the correct one and which are equally-random gibberish. However, anybody cracking the database has a set of key-value pairs. The user would know which image is correct. An attacker not so much. The database doesn't know which one is correct, so cracking it doesn't add much value. You have to try the passwords at random and risk getting locked out. Would probably make hacking the password manager uneconomical unless you are a *very* high value target.
https://pages.cs.wisc.edu/~rch... has a github link and the original paper...
I can't believe I don't see this anywhere in the comments yet, but this is the bigger issue at hand. https://xkcd.com/538/
There exist a number of entries in my password manager that wouldn't cause me concern if someone learned the password, mostly login-to-comment stuff, but also a few merchants that don't have any payment information stored. If a password manager is going to give out fake passwords, it might help to have a "keep it secure" check box for making a new database entry. Then, those passwords would be available and pass a test when login to the password vault program fails, and also, if I'm using the vault to look up one of those passwords, I don't have to use my real password to the vault in order to gain access to them.
...the difference between a hacker and a user who has forgotten how to unlock the password manager? now, he has wrong passwords for his accounts, and they all lock too. terrific.
This reminds me of a question I had about securing a linux server.
We all know it's quite good practice to move the SSH connection from port 22 to some arbitrary high port. But of course if attacker finds nothing on port 22 he's just going to start port scanning until he gets it.
Way better would be for port 22 to respond as a valid SSH server but to reject ALL username and password combinations EVEN THE CORRECT ONES.
Only drawback I can see is when I forget I moved the SSH port and get confused when my password doesn't work. But apart from that...
This seems so obvious that I am sure something already exists to do this. Sadly my primitive google-fu didn't find it.
Jolyon
Please read my Canon EOS tech blog at http://www.everyothershot.com
So the car is like a fake car that drives you to the wrong building? Or does it do its best to kill you somehow?
Cthulhu Saves.
I don't get it either but it's not "stupid" per say since it will get you (if you use the standard 2048-bits size) a password with a length of 372 that is infeasible to crack.
Except when a site truncates the password to 8 characters.
Why would an automated system need to attempt more than one login with the "password" from the manager? Its not like it has to worry about typos.
now: crack the master password with five million guesses per second on your cluster
then: search the ten services with weakest security (as many guesses as you want), start to brute-force the generated passwords for random master-passwords until ones works with 10 services, which allow one (confirmed correct/incorrect) login in two seconds. And may inform you of the cracking attempt.
It only changes the name of the game...
Instead of state-based brute forcing it will be time-based, considering a scenario where all the "bad passwords" take less time to decrypt than the correct one.
Don't be too sure. I recently had a 5x8" notebook (the physical paper kind) stolen while I was at a customer site (accessible to the public). They didn't take my wallet, tablet, phones or tools, but the notebook and pencil vanished. It even had my name & phone number in the cover, but, nothing.
While it didn't contain any passwords (ok, it contained one IP address/router admin password but I changed it as soon as I got back), it did contain notes from that night that I would have liked to have for wrapping up, as well as notes from other customer sites (switch and port information, but nothing beyond "this cable goes here" sort of stuff) and other things that I think of while out and about (and trying to store such things on my tablet is more arduous than pulling out the notebook and pencil).
Fortunately, most of my notes get transcribed to some form of an electronic version every other day or so, but those don't always come with the other things you can only really get when you draw something on paper (like lines connecting one idea to another) - and even though I didn't "lose" much, it still makes me very uncomfortable that someone else may have *any* of the information (assuming they can make sense of it or even read my handwriting).
Founder & COO, Hayai India (hayai.in) / USA (hayaibroadband.com)