I’ll grant that if you have to go to brute force, you’ve essentially already lost. But you don’t have to. You may increase the number of permutations to try by a fair number, but you’ve still got almost every single person using easy to guess methods of complicating their passwords that are still fundamentally weak.
I actually took a password database that had rules such as you describe. In 3 days I had 95000 out of 120000. It it took me 4 days, what’s the difference? I could have just added a few more compute nodes to the mix and made up for it anyway.
Have you looked at the prices of Amazon EC2 instances? Compute is cheap, you’ll have to do a lot better than adding tens of percent to the difficulty to make it secure.
The best thing to do is to use random, long passwords. With a 20 character random alphanumeric string, it doesn’t matter if it has no punctuation, or caps, or anything. It’s not going to be broken. Too bad people use simple, predictable permutations of simple, predictable passwords, then use them at every site the log into because it’s hard to remember 20-30 passwords.
How is that supposed to work when you are for instance logging into your machine via ssh from a random lab thin client? Or maybe you want to jump on gmail from a friend’s laptop?
As I said, 1Password can be accessed even from another computer, etc. and smartphone. It doesn’t have to be your own. If it has a web browser, you can access your Keychain. Of course, you take precautions when you do so, but that should go without saying. Most thin clients I’ve used have access to a browser nowadays.
I don’t know about 1Password specifically
I’m not going to go into any details on how I access mine or what I set up for clients, but here’s some basics:
1PasswordAnywhere is accessible on Windows, Linux, iOS, Android, etc. as well – stick it on a USB thumbdrive, etc. LIke I said, if it has a browser, you can assess your keychain. Otherwise, keep your own smartphone handy.
Well, aye, it doesn’t make sense for everyone, but it still cuts down on passwords shared across sites, and makes this particular attack harder. Tradeoffs, innit?
that password is uncrackable by the techniques outlined in the article.
Good!
It’s still crackable by beating you with a rubber hose
Um, no. Only if one is stupid enough to only use 1Password and nothing else. One can store its keychain utilizing something else that gives plausible deniability. But, I’m not going to go into this in any more detail…
or, more simply, by installing spyware on your machine
That’s not very simple on my machines. Neither are man-in-the-middle attacks because of my setup, but… once again…
Well, as I covered here in my blog post, what this means in practice is that you really need a minimum 12 character password to be reasonably safe these days.
More than 12 probably won’t help a ton, but anything under 12 characters is definitely at risk, and increasingly so.
Also, to @clayton_coffman and others asking, this is about the hashes getting exposed, which can easily happen if one of the thousands of companies you give a password to doesn’t have perfect security across all their computers touching the Internet. I’m just saying. Statistics, man. One weak link is all it takes.
What we need is to incorporate QRcode generators/scanners into these password managers, and just have cameras snap your password wherever you need to log in.
Of course, if the computer is already compromised, you’re screwed, but you already were, anyway.
If you need to log into some account from some MIPS-based terminal running some weirdass OS, you’re probably safe just using correcthorsebatterystaple as your password because nobody else will be looking.
Back when storage was expensive and attacks were rare and passwords were being stored unaltered, limited field size in the password database made some sense.
Now that everything’s trap-door hashed those justifications don’t work. So the limit these days is forms and/or input buffers.
“Nobody will ever need more than 64K of RAM in a PC, right?”
16 characters should be plenty for security, remember that every additional character is a power operator – multiply the possibility space by (n) where (n) is the number of potential characters, digits, etc in that position.
Still annoying since a hash means you could have a password of any length and use a passphrase, but the odds of anyone brute forcing a 16 char password that isn’t something ridiculously simple are pretty slim.
It really depends how you setup your password though. Once hackers discover that the password policy at an organization tends to cause people to fall into patterns, they can crack all sorts of passwords that most people would consider too long.
For instance, an organization has a 16 character password length requirement, and a digit requirement. The hackers discover that a tremendous number of the passwords fall into the pattern of [dictionary word][digit][dictionary word] and begin cracking them left and right.
A longish password is a requirement for good security, but it is not sufficient. You must also avoid falling into a guessable pattern. That’s why overly strict password policies are bad (Must have 2 capital letters, two digits, two punctuation…) because it greatly reduces not only the total search space, but also the number of possible patterns. The policy ends up enforcing a homogeneity in the passwords that makes them much easier to crack.
I’d certainly agree with that. It’s also a charmingly simple-seeming exercise. I may not be able to design a secure computer system but I can make up crazy rituals for “unguessable” passwords.
Agreed – if systems are only storing hashes, there should be no limit on password length up to the size of their input buffer at least. Most of the length limits come either from older systems which were storing passwords in plaintext, or from fixed-size input fields (which used to be a problem on “green screens” and which have arisen again with GUIs and webforms).
There was a parody document circulating in industry, about a decade ago, which gave a password policy made up of rules that individually seemed justifiable attempts to discourage trivial passwords but which, when combined, left only a few acceptable passwords.
Re passwords being “crackable by beating you with a rubber hose” – in systems which have to worry about that, the proper (though not always implemented) solution is to have a “panic password” which appears to work but (a) doesn’t give access to anything useful and (b) announces that you’re under duress and that someone should try to find the person using this password and rescue you.
Password stash on secure USB drive. Or non-password authentication against that USB dongle.
See transfinite piles of past discussion of the axes of security – I have, I know, I am – and the many ways of implementing them. Password alone is “I know”.
