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.

Re:Why so high?

[Altrag]

CAPTCHA had been cracked?

No.. CAPTCHA is a concept. Several specific CAPTCHA algorithms have been broken over the years, but new ones come to take their place.

Image-based CAPTCHAs (that is, stored images not ones that are generated on-the-fly) are trivially broken by building a database of them and solving them. Of course building such a database without being detected is the tricky part -- you can't just spam Recaptcha's server with 100 million requests and not raise some flags. The best / hardest to detect I've heard about is getting an MITM installed on a legitimate website and then when (real) users solve (real) captchas, you fire the answer back to your database. That's probably what you mean by the "trickle" you mentioned above (or something similar to it.)

Algorithmic image creation (ie: create a random string of letters/digits and then muck it up to make it hard for OCR software to read) is a lot more secure.. but at the same time its also a lot harder for a human user to successfully answer. Some of them get so bad that you can't even tell that they ARE letters never mind which ones.

Recaptcha (being pretty much the biggest third-party captcha provider out there) is interesting in the sense that they mix multiple algorithms. They use stored images.. they use generated images.. their generated images are obscured using multiple algorithms.

Sure adding an additional algorithm is only a linear complexity increase, but if you go from say 1 algo to 3 algos, you've dropped an attacker's chances of success by 66% (unless one of your algos is trivially breakable but we'll assume you know what you're doing when you introduce a new one.) That's not insignificant even if its only linear. And I'm pretty sure Recaptcha is up to a dozen or more different obscuring techniques.

It's only useful for web based logins, yes?

No, its useful any time you need to distinguish a real person from a machine attacker (in principle at least.) There's just very little need to make that distinction in most offline software. And of course you need to have at least the ability to pass images in order for a captcha to work at all, so you couldn't add a captcha to say telnet, which is intrinsically a text-based protocol.

Per-user salting

[lgw]

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.

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.

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.