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."

Comments

Why so high?

[wisnoskij]

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.

Re:Why so high?

[gbjbaanb]

Its not about entering passwords on the web login page, but securing the back-end system so that the password database cannot be stolen.

I am constantly amazed at the reports that hackers have accessed the passwords of every user on some site or other. I used to work at a financial company where the web server didn't have physical connectivity to the DB, every request had to go through a service that was not only secured itself, but also could only run stored procedures which were in turn secured. The net result was that is (or rather when) the web site got hacked, all the hacker could do *at best* was access some public data for a single user, which never included the stored password. (incidentally, the developers didn't have access to production servers either)

So sites like ebay et al have direct DB connectivity to their DBs, so if any hacker exploits some zero day that gives them access to the OS, they can simple "select * from user" and download every password, hashed or not, and crack them at their leisure.

Personally, I think passwords should be stored in plain text in the DB as a reminder to all developers that they need to be protected in other ways so the hacker cannot access them in any circumstance.

However, what I do find strange is that web devs do not know this, I wrote the above for an ArsTechnica comment and the "security editor" promoted a criticism of it where the concept of a 3-tier architecture was "too expensive" an d"inefficient", suggesting that storing your DB credentials in your web code was OK as long as you "secured" it. If this is the level of comprehension of security in the web dev community, then I'm not only unsurprised at the number of hacks, but will be using a randomly-generated password for every website that asks me for a password.

Re:Why so high?

[rtb61]

Then do the simpler thing and ensure the password file is securely protected and add some real time in the password entry. A simple countdown timer to slow password entry down and increasing the time each a wrong guess is made, say simply doubling of the wait time between entries ie 1 second, 2, 4, 16, 32, 64, 128, 256 and so it goes, with a reminder to the user of the implication of too many bad guesses. Throw in a email warning to the user when say three incorrect password attempts are made in a row. Also association IP addresses with user name passwords not locked so much as for when too many bad guesses occur as an additional flag. To go really secure put the passwords on a separate simple small cheap box and all that box does is encrypt, decrypt and test passwords and user names, nothing more. That is the only communications the box will accept and the only information the box will provide is pass or fail on that test.

The big security advantage in switching from boxes that do everything to appliances only, is that those appliances can be hardware and software configured to be able to 'ONLY' do what they have been designed to do. You make them unhackable by simply making sure they can not carry out the required functions needed to carry out the attack, they are locked into only carrying out their designed algorithms and require a specific hardware and software rebuild to do anything more. This can be done very cheaply with things a password checker. Flexibility in technology leads to a whole lot of security problems ie the system ends up doing things the user never intended.

Re:Why so high?

[Altrag]

As long as your DB is connected to any network in any fashion, its susceptible to cracking. You can't possibly know what new attack vectors may arise. And even if you somehow manage to guarantee 100% security in your software (which is frankly unlikely to the point of impossible -- software is hard!) you still can't guarantee that some human participant won't either go rogue or screw up, allowing access to the DB that doesn't require _any_ technological cracking.

The only way to completely lock down a computer is to keep it shut off in a vault that literally nobody can open. But of course that also makes it no more useful than a rock.

As for web dev's comprehension of security.. again, software is hard. When they say its "secured" what they mean is "I can't think of a way in." But of course that's a totally irrelevant metric because they aren't the attacker.

And that fact applies to everyone, up to and including the most experienced security researcher in the world, because of the obvious fact that if they could think of a way in, they'd patch it. Its always the ones you don't think of that get you.

No matter how smart you are, there will be a maximum program size you hit before the complexity overwhelms you and you have to internally abstract things, and every abstraction is a potential security hole that you may or may not ever consider. Never mind relying on third party libraries or for that matter the security of the hardware layers.

We've definitely come up with some best practices, and its no secret that there are loads of people who don't know, don't care, or don't have the time to implement the best practices.. but all the best practices in the world don't solve the problem of program complexity exceeding (full) human comprehension.

Computers: They can respond fast -and- slow

[Empiric]

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.

Re:Why are we still using passwords?

[gbjbaanb]

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.

Re: Passwords should not exist

[ShanghaiBill]

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.