Slashdot Mirror
Passwords: Too Much and Not Enough
An anonymous reader writes: Sophos has a blog post up saying, "attempts to get users to choose passwords that will resist offline guessing, e.g., by composition policies, advice and strength meters, must largely be judged failures." They say a password must withstand 1,000,000 guesses to survive an online attack but 100,000,000,000,000 to have any hope against an offline one. "Not only is the difference between those two numbers mind-bogglingly large, there is no middle ground." "Passwords falling between the two thresholds offer no improvement in real-world security, they're just harder to remember." System administrators "should stop worrying about getting users to create strong passwords and should focus instead on properly securing password databases and detecting leaks when they happen."
Why would it ever be even close to that high. Every decent system I have ever encountered raised some serious flags after 3-5 wrong guesses. If you flag an account after 10 wrong guesses, start requiring a CAPTCHA after the first one, and ban ip addresses when you detect massive multiple account attempts, you can offer security fool proof security, with, lets say, around 100 guesses.
Troll is not a replacement for I disagree.
Le'ts just get to Two Factor Authentication everywhere and be done with this conversation!
Two-factor auth is a big win, of course. For anything financial, and for work accounts, the whole idea of strong passwords should be abandoned in favor of well-designed two-factor solutions.
How many people do per-user salting of the password hash? It's an important best practice to defeat rainbow tables. If you have thousand of passwords stolen, despite your best efforts, the least you can do is make it non-trivial to guess each one.
Mostly, though, encrypt your stored credentials in some way that requires an attacker to compromise two unrelated machines to get anything of value. Even a simple AES encryption with a hard-coded key is a win, as it's actually pretty tough (for a non-insider) to figure out he needs to either hack the source code repo, or somehow find the key in the object, on disk or in-memory. That's not impossible, but practically it limits the threat to malicious insiders, and malicious governments.
Socialism: a lie told by totalitarians and believed by fools.
There are infinite varieties of ways to inject a delay between login attempts, or lock out the console/IP entirely, after N failed attempts. N should be on the order of 10, not 1,000,000 or 100,000,000,000,000.
This has been well-understood by the entirety of the competent developer world for years, and implemented extensively as such. I hope security "analysts" catch on to reality soon.
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
Encrypting the password with a small salt is enough to slow down simple password guessing with rainbow tables. If you make the salt non-trivial, such as encrypting with a 64-bit additional site password, tables wouldn't work. Of course, the same password could have been used to encrypt the entire password file in the first place, but this technique allows the password to be stored in the usual way. You have to keep that additional site password a deep-deep-deep-dark-secret, even more secure than you thought you were keeping your password file. It can't just be included in the source file - or appended to the end of the password file - best if the password verifier reads it from a separate secure location. In that way, 2-factor encoding works for the password data itself.
When you send things down a wire, everything is "something you know".
A smart card or an RSA clock or a code sent via SMS is effectively just another password. And while it may be a strong password that's hard for an attacker to know, changes with time, etc., it's still vulnerable to MITM attacks because you're sending your shit over a single, unsecured channel. It's also a password the user has little to no control over, can lose and not have a backup of, etc., so there are entire management, recovery schemes introduced to make them usable. They provide very little in terms of security over a strong password. They only fix 2 problems - weak passwords and keyloggers. But keyloggers are just a subset of compromised boxes, and if you're using a compromised box then you're susceptible to an active attacker MITMing you using your valid smart card / token / codes / etc.
For two-factor security to actually be "two-factor", you have to validate the 2 things separately and via different means. A bank can do this in person by verifying your account information/name/etc. and your photo ID by actually fucking looking at the ID and you. When you automate everything and shove it down a single pipe (the internet), it's all effectively just a password.
Because its wrong.
If you treat each word as a symbol, rather than each letter, then you find the average vocabulary is about 10000 symbols and you have just generated a 4-character password (admittedly in base-10000 rather than base-26) but you'll find its still easily crackable, especially if the hacker uses pre-generated rainbow tables.
Or to put it another way, your xkcd password, if the user has a vocabulary of 10k words, being cracked by a CPU that can manage a trillion hashes per second (easy) means your password can be brute forced in less than 3 hours. For reference, 16 random characters would take 2.5 billion years (ie 64^16 = 8*10^28, which is 8*10^16 trillion seconds, or 2512 million years). Ok probability says your chances are on average half that.. only 1.25 million years.
The best password is a random one, use a tool to generate and store them and let it type them into the password field. If you must use a xkcd style password, at least stick a digit between each word.
Then you've accomplished essentially the same thing as salting, because you'll need to store the number of times hashed along with the password entry in the database. Why not just make life simple and use something designed for hashing passwords, like bcrypt and a salt?
Frankly, you're overcomplicating things. Complicating your security scheme is a bad idea, like inventing your own crypto. As a hobby, I study cryptography and write crypto code, but I would never use one of my own homebrewed schemes in production or for anything important. The chance of screwing up something non-obvious is far too high.
Stick with the tried and true.
That's not true. They also provide protection against:
For example, consider heartbleed. If someone stores your encrypted communication, and later compromises a host's private key, that attacker could ostensibly decrypt those communications. If you use a password, that password is compromised, and it's "Game over, man." If you use a physical token, only the PIN is compromised (assuming the actual verification happens in a separate process).
Ideally, you would still want to issue new PIN codes, but the account hijacking risk would be largely mitigated by the physical token requirement, at least after the n-hour cookie expiration window passes, and you could even eliminate that window by expiring any cookies in your authentication database before bringing it back online after you fix the heartbleed vulnerability.
Check out my sci-fi/humor trilogy at PatriotsBooks.
No password is complex enough to survive a brute-force attack.
Um, that's complete BS. I suggest you replace "No password is" with "Many passwords aren't". Most proofs in cryptography are based on assuming that you can convert a significant fraction of the Universe's resources into an attack on a given password/key. The idea is that the heat death of the Universe would happen sooner than a brute force attack.
The way we decrease the time needed to attack a given algorithm is by finding a flaw in the algorithm which reduces that complexity. A blanket statement that "no password is complex enough to survive a brute-force attack" is ignorant at best. Most attacks aren't true brute force attacks, but attacks which reduce the search space/complexity first, and THEN perform a much more limited brute force attack.
That's where trusted authorities and public key encryption comes into play. The trusted authority essentially acts as the "different means."
Of course its still susceptible to MITM if the attacker can get between you and the point where the data transmission splits off between the CA and the destination site (and of course are already in place at the time you register with the CA and have the private key on the wire.)
Not impossible, but also pretty difficult to achieve since it usually means physical access to something relatively local to the sender. At least until the ISPs themselves become the MITM attacker (which is becoming more and more probable unfortunately in the modern age of Orwellian surveillance attempts.)
Of course yes, the most obvious solution is to just pass the key over a different communications channel. But nothing is ever absolutely secure. If you meet the person face-to-face to exchange the secret, you have no guarantee that he isn't in collusion with or coerced by an attacker, or won't be at some point in the future.
The only way to be 100% sure that a secret is safe is to keep it in your head (don't even write it out or save it to your hard drive!) At least until we figure out mind-reading devices. But most secrets need to be shared with someone to be useful so that's not always a plausible solution.
it's still vulnerable to MITM attacks
No. The smartcard is pre-programmed with the public key of the authenticator, and vice versa. Unless someone knows the private key of one of the endpoints, the authentication cannot be faked. A MITM attack will not work.
The comic does tread each word as a symbol, which is why it only claims 11 bits of search-space per word, which requires a dictionary of only 2048 words, and there are way more than 2048 words that are long enough that the fact that they're in a dictionary is the limiting factor. It's already accounted for in the search space estimate.
The claim of the comic hasn't been "debunked" because the claim isn't that you can use words to have a lot of characters in your password, it's that we've been focusing too much on getting the most search space out of each character when the thing we want to optimize is the total search space per password that a person can remember, and the word technique sacrifices a lot of character efficiency to result in better overall passwords.
Your hypothetical user isn't choosing between four words from in a 10k word dictionary and a 16 character password. The fully random 64-symbol password of equivalent memorability is probably quite a bit shorter than 16 characters. I wonder what research has been done on this; I'd put my money on the equivalently memorable password being closer to 6-8 characters.
It only takes nine words from a 10k dictionary to beat a 16 character (64 symbol space) password. It also only takes 21 lowercase letters to beat your "complex" 16 character password, and I know which one I'd prefer to actually have to type regularly. More symbols per element is only a benefit when it increases the ability of the user to actually use stronger passwords.
Can you be Even More Awesome?!
When you send things down a wire, everything is "something you know".
Kinda one of the points of smartcards is that you don't know the key inside of them. Thus your access can be revoked physically by depriving you of the card, should it become necessary.
And no, MITM attacks don't affect properly implemented smartcard or even password authentication, as preshared material and/or mutually trusted authorities counteract that.
With regards to TFA, here's an example of how PubkeyAuthentication has some drawbacks and is not a hands-down superior method for authentication over passwords. Letting users leave those lying around wherever they please means the weak passwords they chose on those keys are more likely to be guessed in an offline attack than is a password in an online attack against a rate-limited authenticator.
Someone had to do it.
And the funny thing is, super-complicated password are an anti-security measure.
Because if the password is hard to remember, chances are the user has it written on a piece of paper or a note somewhere..
Normal passwords don't tend to suffer from this problem.
If the super-complex password requires causes the user to write it down or store it on their phone or such, it is hurting security --- not helping it.
Priest: "Universe from nothing, no laws of physics, sped up time"+ huge discrepancies. Creationism? No. Big Bang Theory
Disclosure: I work as a penetration tester In my line of work, we often go for passwords, encrypted or not. Especially on office networks, we go for the LANMAN (yes, we do get to see those on a regular basis still) or NTLM password hashes. Even NTLMv2 are useful to us, although cracking those requires more time.
The reason that LANMAN and NTLM are so useful to us, is that we can just use the hashes to authenticate against remote servers. That's right, knowing the password isn't required, just having the hash is enough for the remote server to authorize us as the person that the hash belongs to. This is "fixed" in NTLMv2 and if you properly implement Kerberos for your AD authentication. However, since legacy systems are abundant, in practically every office network we encounter, the older systems are still in place because of "backwards compatibility requirements".
No amount of password complexity helps against the above problem. Several commercial 2-factor vendors solutions aren't even a solution. Why? Because they replace the password prompt for a prompt for a token generated by their device and once that reply is satisfactory, they simply send the hash themselves. Their solution replaces the password, but not the real weakness, the hash itself.
This may not be a significant problem on the internet, but once an attacker has gained access to your corporate network, this problem usually means doom for anything password protected. This sort of thing happens on a larger scale than most internet users realize. Advanced Persistent Threats (APTs) aren't named that for no reason and they are just a few of the many organizations and individuals attacking companies these days.
I was promised a flying car. Where is my flying car?
Me and other security experts have been saying such things for years.
Basically, our password handling systems and policies are completely broken. It's not just what xkcd pointed out - it's worse. Those policies are based on making brute-force attacks more difficult. But to sum up a complex topic in a soundbite: If your system allows for brute-force attacks, your system is fatally broken.
Assorted stuff I do sometimes: Lemuria.org