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?

[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: Passwords should not exist

[sexconker]

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.