I took the liberty of translate your very good article in French (http://www.fotozik.fr/votre-fichu-mot-de-passe-est-bien-trop-court) quoting you and linking to your blog. If it’s not OK with you, let me know that and i will delete it.
Thanks
At least 200 characters, I’d think. Enough to allow a reasonable passphrase. And since you don’t store the password, but the hash…
The hash is of fixed size (128-bit, 256-bit, etc) so pick the correct size for the hash you chose. Remember that you may need to version logins if you switch to a stronger hash later, too.
Problems, though, because some sites…
- don’t allow 22 character passwords
- don’t allow special characters
- may require some other unique combination of “just numbers and letters”, specific length, etc
Something has to give, because a thousand sites / apps with a thousand different passwords – all stored differently, with different requirements – is unworkable.
I believe the future is more federated logins behind your Apple, Google, Facebook, Twitter etc login, with two-factor enabled on the parent.
2 Likes
Yeah but you get the idea. My default is 22 length alphanumeric, I don’t like to bother with weird characters in case I do have to one day enter the password in manually for whatever reason. Ditto for why going beyond 22 chars really only hurts you, not increasing entropy for most hash algs.
The main benefit is of course that:
- A dictionary is unlikely to have your random character combination.
And when I say unlikely, I only say that so that a mathematician
doesn’t jump on me. Your random character combination won’t
show up in any dictionary. - You don’t have to remember it. Which is good, because you definitely won’t remember it.
- It can be unique among your accounts, yet another good reason to not have to remember it. If you have 100 online accounts, how many strong passwords do you want to have to remember? For me, thats a zero.
- Anti-phishing. Lets say you do something dumb and click on a link that takes you to your bank’s website instead of going there manually. Password managers recognize that it’s not suntrust.com. You have no passwords registered for suntrvst.com. So your manager doesn’t autofill the fields. Moreover, you don’t actually know your suntrust password, so you can’t manually enter it in anyways. You are beyond being phished.
Indeed Suntrust as well doesn’t allow more than 15 character passwords and has no MFA support.
Even PayPal’s MFA is lackluster. It works well with a keyboard, but makes it neigh impossible to access from a phone.
Its so sad that the financial sector, the industry that hurf durfs more than any other industry about online security, has by leaps and bounds the most mickey mouse security policies out of any industry.
Maybe one day they’ll catch up to online videogames and message boards. 
Love the fact that I do not have to remember more than one password. Actually that’s a lie, have two password I need to remember. Because our government login system is really trying the stupid approach of denying auto-completion by using multiple inputs to screw with password managers.
That’s a another topic you could cover auto-completion for websites fields
Prior to switching to password manager I had to remember somewhat 20+ passwords which kept becoming harder so you start to create your own mini password manager with insufficient protection.
Then I took the plunge and started using LastPass, it was time consuming going through all those websites and changing password for what was 50+ sites which has been steadily growing ever since.
My vault has well over 150+ passwords, stores my address, credit, SSN, auto fill completion.
Using pass phrases with +22 characters for master password is a bliss while having toopher’s push notification as two step verification.
Lastpass password generator has quick settings for length, lower, upper, special, minimum number. Which I hope most other password managers have too.
Logging in to anything is a breeze. Auto logout after idle for x minutes depending on the device is wonderful.
What really pains me is when website submits limitation when they are storing password, if it is really so hard then simply don’t as you suggested using OAuth2.
It boggles my mind that my bank has agreed to the government login system with a limit of 16 charters of lower cased a-zæøå and 0-91
Using two step verification should be on every important site sadly the bank also allows that to be a piece of cardboard paper.
In the case of ‘correcthorsebatterystaple’…
Wouldn’t a password that simply uses random english words be easy to crack via a combined english dictionary + heuristic analysis.
I seemed to remember a talk being presented by the author of the JohnTheRipper tool go into detail about speeding up the cracking process by using heuristics that check common patterns ex. capitalizing the first letter, l33t5pe@k, appending a number, using a long string of common words.
I’d assume that any algorithm that’s easy enough for a user to use off the top of their head is trivial to script as a heuristic. Ie it’s just another form of ‘security through obscurity’ because it assumes that your algorithm is uncommon enough that it’s unknown to the cracker community.
Personally, I use randomly generated passwords provided by KeePass for ‘sensitive’ stuff and my ‘internet drivers license’ for anything social because 2-factor auth is simple with an app.
I think people should be allowed to choose short passwords.
In defense of bad passwords, I just don’t care if most of my accounts are hacked. My email and my bank account (and other accounts with direct access to my bank account) have long, random passwords, but I feel that everything else is just noise.
Memorizing unique, long passwords is an inconvenience. As long as my email is secure, I can regain access to all my other accounts through that.
I feel that short passwords are a valid choice, especially for unimportant sites.
Not really, if done correctly… you can check out the diceware page that was linked in the post for more information:
http://world.std.com/~reinhold/diceware.html
Besides that, all other things being equal, and ignoring pathological cases (e.g. my long password is 1111111111111111``1) a longer password is much more secure than a shorter password.
MD5 is old but not trusted.
Working the Help Desk at a huge prestigious university, password resets were frequent, as was the frustration. My two favorite password related jokes (yes, I have so many that I have two favorites):
- User, having their fourth new password rejected – Holy s%&t! My bank password isn’t this complicated!
Me – shouldn’t you be angry at your bank, instead?
- User – oh, I just use the same password for everything.
Me – oh totally, what is it??
That second one is hysterical, but dangerous. Best case, they open their mouth, followed by a long pause where their face twists from friendly to horrified. Worst case, instead of a long pause, you hear actual sounds about to emerge that you have to rush to yell “DONOTTELLMENONONOJAYKAY” because it really is supposed to be a joke, not a social hack attempt.
Three levels of authentication security :
- Something you know (passwords),
- Something you hold (USB key),
- Something you are (biometrics).
Or
- Something you forget,
- Something you lose,
- Something you cease to be.
1 Like
Chrome, at least, is moving in this direction.
I’ve been disappointed with progress on this. I first saw the linked page years ago, and apart from a few tweaks to the way the proposed feature will work, nothing has really changed.
Probably the single greatest failing of people that devise their own security scheme are the assumption that it will millions/billions of brute force tries to break it. That isn’t how cryptographers work. At the end of the day, any passphrase or more specifically, human devised pattern is breakable. That xkcd post? Silliness. That password along with many, many passphrase combinations are now known. That book you read as a child with a cute phrase? Cracked. l33t the text? Cracked. Add your kids favorite word into it? Cracked (thank you Facebook). The only solution with passwords is to take the human devising the pattern out of the equation. A password manager that generates random passwords is orders of magnitude better than a human devised passphrase or password scheme. Two factor is even better.
I think you have just made an excellent case for the elimination of the password. Giving the level of hacking involved globally its pretty clear that passwords are no longer a solution for securing anything. There is some very good work being done by the FIDO alliance to create standards that will be widely supported. Key FIDO members are: Google, BOA, Discover, Ali Baba, PayPAl,… Their standards allow for 2FA or even password elimination using various supporting biometric technologies (fingerprint, voive, etc…)
Hopefully the password will be dead soon and we will all be safer. You can check out the FIDO alliance at:
FIDO Alliance
If you’re looking from a purely mathematical analysis perspective, you’re right.
The thing about newer password cracking tools is they have the ability to create heuristic matching rules. Consider for a moment the sheer amount of leaked data available. Then consider that most of the leaked data has already been cracked.
If you process a sufficiently large sample data set (ex millions of leaked passwords) you can discover common patterns relatively quickly. Combine that with frequency analysis to order them by weight and you have a complex – but completely feasible – platform for cracking passwords.
Check this out:
DEFCON 17: Cracking 400,000 Passwords, or How to Explain to Your Roommate why Power Bill is a High
Consider 11111111111111111. The pattern of repeating the same number many times is an easily identifiable and will likely score a high weight in the pattern listing. Therefore, with modern cracking tools it would have a high likelihood of being cracked.
Relying on mathematical complexity alone assumes that password crackers are incapable of developing effective strategies to divide and conquer.
We use machine learning algorithms to do pattern matching on images using large sample sets of images. 2D data is a hell of a lot more complex than string data. Is it really so hard to believe that you can train a computer to pattern match common password patterns when you feed it with a sufficiently large data set?
1 Like
Thanks so much for this article which is so timely.
It happens I’m defining a secure password policy for a web application. For instance, I did not think other sites could be our biggest threats if they don’t properly protect their password database and, therefore, reveal the password used by our users if leaked and cracked. I was so much worried about protecting our own database.
Regarding
I don’t feel like pre-pending the domain name of the web site to your usual password is a great idea. Once one of your password is cracked, the pattern you use can be easily identified and your password on other sites easily generated. Maybe I’m wrong about the suggestion you made.
How would that happen, though? We’re talking about (in my case, testing the formula with this site) a 23 character password. It would only be possible
- if the password is stored not as a hash, but as plain text
- if a keylogger is installed on your system
- the login form is not using https
I guess it depends on your level of paranoia. The formula can be adjusted to taste, ultimate is diceware.
My point is that the simple pattern of “user uses same password on x different sites” which is incredibly dangerous is blocked by using the domain as a salt. So no, it’s not perfect … but it is a huge, huge improvement over what most users do, which is reuse identical passwords a bunch of places.
I guess you assume it’s impossible to crack a 20+ characters password stored as a bcrypt/scrypt hash ? And that, whatever is the domain name, the password will be 20+ characters long.
I was taking a different assumption where the “salted” password could be 12 to 15 characters long. Eventually crackable. Once it’s cracked, the pattern can be identified and apply with the same global password on other sites.
I realize that pre-pending or appending the domain name will create a 20+ characters long password most of the time, especially when the global password is 12 characters long (once again I rather assumed 8). And that it’s very difficult to brute force, thus you’re safe.
I totally agree with that.
1 Like
I wrote a browser add-on for FireFox, which uses your “everyday” password and pin-code, along with the base domain name, to generate a password based on SHA512. Completely random-garbage-looking, and absolutely repeatable as long as you don’t forget the inputs. Not stored anywhere, so nothing to steal. Password Generator Toolbar for FireFox
Since I no longer know what the passwords are, I also wrote a companion desktop app and even an Android one, so that I can generate them when I’m away from my home browser.
I’m not just advertising my product (which is completely free anyhow)… I’m trying to address one aspect of the problem: good passwords are hard to remember and type, and trusting somebody else to curate them brings its own concerns.
1 Like
This is quite similar to the way I generate passwords for most sites. Without going into to many details I use many iterations of the sha512 hash of a base password + site name + a salt derived from the time/date of sign up + a sha512 hash of a picture of [censored]. Anyone who can brute force that deserves my login credentials.
A salted secure hash function is generally more than enough, but I would also add a two factor authentication subsystem you can get one integrated with Authy very quickly. The other thing I would add is a NoCAPTCHA check on the login button.
The advantage of 2FA is it reduces my concern for a single point of attack, even if the password for the site is “password” they still need to know that and the actual 2FA value which is less likely.
The NoCAPTCHA check prevents bots from overloading the system.
A few years ago I wrote up a related idea in https://tools.ietf.org/html/draft-kistel-encrypted-password-storage-00. It seemed like a good idea at the time, but it didn’t get traction.