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

Perhaps we should ask resident expert

[Anonymous Coward]

Bennett Haselton? I'm sure he has an opinion on how we can solve this problem, now that he's solved the world's ice selling problems.

Re: Perhaps we should ask resident expert

[Anonymous Coward]

Please for the love of God someone please find Bennett Haselton because I am dying to know what he thinks about this.

Re: Perhaps we should ask resident expert

[Anonymous Coward]

Please for the love of God someone please find Bennett Haselton because I am dying to know what he thinks about this.

No, let's not. Whatever your obsession with Bennett Haselton is, get a room and take this offline. I'm getting sick of this already.

Re: Perhaps we should ask resident expert

[Anonymous Coward]

You must not be Bennett Haselton then, because he's the only one not sick of him.

Re: Perhaps we should ask resident expert

[Anonymous Coward]

It took some serious deductive prowess to figure that one out. /snark

CAPTCHA: contempt

Passwords should not exist

[Anonymous Coward]

Smartcards. Please.

Re: Passwords should not exist

[Anonymous Coward]

Authentication should be a combination of "something you know" and "something you have". Smartcards shouldn't replace passwords but they can enhance their security.

Google Authenticator is a great solution to improving authentication security on most websites.

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

[Lunix Nutcase]

Hopefully not ones from HID if you want any actual security.

Re: Passwords should not exist

[dgatwood]

They only fix 2 problems - weak passwords and keyloggers.

That's not true. They also provide protection against:

• Shoulder surfing attacks, which require no compromise to the internals of the endpoint
• Storage of data encrypted with a protocol that later proves vulnerable in some interesting way, such as a key compromise

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.

Re: Passwords should not exist

[Altrag]

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.

Re: Passwords should not exist

[roc97007]

> so there are entire management, recovery schemes introduced to make them usable.

I'm hoping that other companies do this better, but I've noticed that the recovery scheme is particularly open to a social engineering attack. If you lose your RSA clock dongle or it quits working, a call to the helpdesk will get you a "temporary code" that gives you access to the company's intranet. To do this only requires the helpdesk phone number and a valid employee name and associated employee number. None of these items are particularly secret.

Re: Passwords should not exist

[roc97007]

> Not impossible, but also pretty difficult to achieve since it usually means physical access to something relatively local to the sender.

Wow I just had a flashback. This was the first step of the plan in most Mission Impossible episodes.

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.

Re:Passwords should not exist

[ShanghaiBill]

Smartcards. Please.

Smartcards alone are not a solution, because they can be lost or stolen. You want both a smartcard and a PIN/password. You smartcard may get stolen, or your password may get compromised, but it is less likely that both will happen at the same time. You might want to setup a threshold for PINless transactions for, say, purchases under $10, but you still want more security for important stuff.

Re: Passwords should not exist

[skids]

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.

Re:Passwords should not exist

[sjames]

What I want to see is a smarter card. Ideally it has a few indicator leds and a membrane keypad on it.

It should support ssh style security and a simple agent protocol so that you can plug it into a reader, enter a pin directly on the card (so no intercepting the PIN from a hostile terminal). This should log you in and allow you to use agent forwarding to connect to other machines you are authorized on.

Possibilities when you pull the card out include locking the screen or logging you out.

It should have persistent storage as well so it can be used as a payment card as well. Enter a maximum amount of payment you are willing to make using a wallet device, then insert into a reader on the POS. POS presents it with a transaction record and if the amount is correct, it signs it and hands it back. The record should contain a sequence number so that the bank will only accept the transaction record once.

Restrict the record to ASCII so that it can be cut-pasted if you want to complete a web based transaction without a browser plug-in. At that point, the account number is strictly for identification, the crypto signature is what authorizes the transaction.

More advanced features can be carried out on a trusted computer such as your home PC.

Re: Passwords should not exist

[flyneye]

Oh what's the difference, any security scheme in IT today, including government, is about as secure as a locked house with a big doggy door and a key hidden on the doorframe.
Let's just go back to the original dream of an open network and sharing all our files. How much do you intend to stress yourself about IT security? Live is pretty short, hardware and software will always have holes, people will always want to snoop and charlatans will always try to profit. Just adjust to reality and quit trying to force an elephant into a gnats ass.

Re: Passwords should not exist

[Anonymous Coward]

• "Something you are"
• "Something you have"
• "Something you know"

A password is something you know. A code via SMA or smart card is something you have. If the attacked compromised either the console being used to log in, or the server, then no amount of security is going to prevent the attacker from being able to masquerade as the user.

In your bank example, if the banker accepting the ID is a malicious actor, then your authentication system is irrevocably broken.

All that's left is auditing to clean up the mess left behind afterwards (which is an entirely separate topic, and can be done both poorly and properly).

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?

[tqk]

If you flag an account after 10 wrong guesses, start requiring a CAPTCHA after the first one ...

Didn't we see a story a while ago purporting CAPTCHA had been cracked? I didn't bother with it myself (don't much care). It's only useful for web based logins, yes? I'm not suggesting those don't matter; just they don't matter much to me.

... and ban ip addresses when you detect massive multiple account attempts ...

A few years ago, someone reported that has changed the attackers from "batter on the door until it breaks" into slow trickle instead; lots and lots of attacking hosts on separate IPs, each one making only one or two attempts, then moving on to the next on the list.

Re:Why so high?

[firewrought]

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.

If it only takes 100 guesses, then an attacker can slowly try passwords stretched out over time, depending on his victim's routine behavior of logging in a couple times per day to reset the fail count. Or maybe he can try 1 guess (with 1/100th odds) on each account in the target system. If there are hundreds of accounts... well, you get the idea.

IP-based banning can make this harder (forcing the attacker to find/use multiple victim PC's), but it's not widespread yet (for instance, I don't think Active Directory or slapd support it).

Re:Why so high?

[ColdWetDog]

... but will be using a randomly-generated password for every website that asks me for a password.

I'm not in the position to argue the merits of the rest of your post, but this last part seems obvious.

Once you have more than a half dozen passwords, your ability to remember them drastically decreased unless you are some sort of savant. You need a password manager. Once you are using a password manager, there is no reason NOT to use a different, random, difficult to hack password on every site. I have no idea what the vast majority of my passwords are - the only ones I remember are the three I use multiple times a day at work. The rest get created and filled out by 1Password.

And, yes, of course, now I'm at the mercy of my 1Password password and the company's ability to manage their program. Can't be perfect and the current system really does suck but this way seems to be the best of the worst.

One feature I wish Agile Bits would set up is the ability to automatically change passwords on a regular basis. As it is, I manually change some high value passwords every so often (not Slashdot's of course). PITA.

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?

[vux984]

I used to work at a financial company where the web server didn't have physical connectivity to the DB,

I suspect you meant something entirely different from what you said. The webserver cannot be air-gapped from the password database unless you literallly have a person sitting between the two systems keying requests from one into the other and back again. Otherwise they most assuredly ARE physically connected in some way.

Personally, I think passwords should be stored in plain text in the DB as a reminder to all developers

Then your DBA has all the passwords, and your one bribed, disgruntled, or incompetent DBA away from a massive leak.

suggesting that storing your DB credentials in your web code was OK as long as you "secured" it

I'm generally ok with this. You shouldn't be embedding your root or sa or whatever database credentials in the website but its not necessarily improper to embed limited access credentials to the database in the web app that needs that access.

On windows, for example, one can put database credentials (for a limited account that only has access to specified views and or stored procedures) in the web.config and encrypt it. This seems entirely reasonable to me.

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.

Re:Why so high?

[MpVpRb]

Agreed

It's hard to imagine any site allowing 1,000,000 bad guesses

It probably varies by site, but methinks anything over 100 or so would trigger a response

Even if the limit was 1000, same outcome

Re:Why so high?

[HiThere]

Besides, it wouldn't matter if CAPTCHA were cracked for his purpose. His purpose is to raise the cost of intrusion to the point where the attackers go somewhere else. Not ideal, but it's probably the best you can do.

Now there are several layered approaches that one can adopt to strengthen the security, but convincing the attackers to pick on someone else is probably the best any of them, or all of them combined, will accomplish. How much security you use depends on what you're protecting. Personally, if I were really after security I'd mount the system on a read only device, checksum everything, and have a daemon that rebooted the system if checksum validation failed. The idea of storing the user passwords on a separate device that can only reply "True" or "False" to a username:password pair has a lot going for it. But is it worth the hassle? That depends on what you're protecting. (For me, no. I don't have anything valuable on my machine except some code I'm developing, and when it's done it will be GPL.)

Re:Why so high?

[HiThere]

I'd like to set it to any number of errors in a row starts increasing the time between allowed login tries, and start the delay with the 2 seconds and square it for each succeeding wrong guess. Also a warning on the login page as soon as even one erroroneous login attempt is detected.

Unfortunately, it's not a standard option, I'm lazy, and I don't have anything valuable on my machine. (E.g., I won't do banking over the internet.)

Re:Why so high?

[WaffleMonster]

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

Occasionally I hear people making statements like this and while practically useful *at best* language is a dangerous assumption.

Additionally complexity of a middle tier just for security sake could well provide additional avenues of attack that may not be available in a globally less complex solution but it all depends on specifics of the implementation.

The reason why *at best* is wrong an attacker able to compromise the application, middle or data tier is almost always able to exert complete control over the environment... just not immediately or on demand.

At any tier an attacker may record data persistently over time compromising user credentials and data as they login and use the system... you don't need to select * from users when attackers already have copies of your data mirrored to them over time or are able to impersonate any number of users.

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

Better than delusions of safety.

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.

Data tier could be made to offer functionally same level of security as an application specific middle tier with view based access and or procedure driven access. Not uncommon to run into systems where user accounts are unable to touch any real table.

Re:Why so high?

[stephanruby]

Agreed

It's hard to imagine any site allowing 1,000,000 bad guesses

It probably varies by site, but methinks anything over 100 or so would trigger a response

Even if the limit was 1000, same outcome

Apparently, this guy had no problem trying to guess 20,000+ passwords for any account on iCloud, a security issue he disclosed to Apple six months before CelebGate.

But again, this must have been user error.

The theft of the photographs, a statement from the company insisted, was not the result of “any breach in any of Apple’s systems including iCloud or Find my iPhone.”

The only thing Apple did wrong was not to educate its users about security.

“When I step back from this terrible scenario that happened and say what more could we have done, I think about the awareness piece,” he told the Wall Street Journal. “I think we have a responsibility to ratchet that up. That’s not really an engineering thing.”

Re:Why so high?

[s.petry]

The idea should not be just to require CAPTCHA as an additional password, the idea is to slow down an attacker and break scripts.

Maybe it's just me, but TFA and most comments so far are way off base. A guy suggesting to store passwords plain text in a DB? TFA claiming 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."?

Is this an early April fools gag, did the NSA start posting and responding to threads?

Most security experts admit that Passwords are a problem, but "Strong" passwords are not overly complex for a user to remember if they receive the right training and reinforcement. P@ssw0rd is a bad idea, it's in every crack dictionary on the Internet (as well as p@55w0rd, p@ssword!, and a few thousand others. 1b=aTan[1998] is another story, and extremely difficult to crack. For a user, they can use variations of the same password for all of their services with minimal changes, and still have an extremely low chance of losing everything. 1998 may be your bank, denoted by the "b", where "e" and a different four digits is your email. Assuming the user changes the full structure about every year, you don't have to worry much about hackers.

Yes, if a shadow file gets stolen you have a different problem. That problem exists no matter what your password is. If a company notifies you that the shadow file was stolen you go change all your passwords. You have a couple days of time, unless of course a Government agency with massive power gets the shadow file, because you can't statistically crack a 12+ character "strong" password in 2 days even with the shadow file. Cracking a 12 character dictionary based password would still be hard to crack in 2 days time.

Re:Why so high?

[Anonymous Coward]

I don't expect a reply, as I'm posting AC, but feel free to take it or leave it.

Yeah, most of the people here are way off base. Virtually every suggestion I've seen implies a complete and total lack of knowledge about best practices related to security. Any hints of familiarity with actual cryptography is totally drowned out by the people suggesting stupid shit (like the aforementioned idea that we should store passwords in plaintext).

I wouldn't be at all surprised if fully half of these were NSA-sponsored posts. I remember a Slashdot where an article on password security would result in actual useful comments. Now... this bullshit. I mean: +5 Insightful for a guy who doesn't know what an "offline attack" is and vehemently defends his interpretation of it as an attack on a box that doesn't have a network connection (as opposed to its actual cryptographic meaning); people who suggest 4 common symbol passwords being stronger than 8 symbols of garbage; homebrewed crypto suggestions that have seriously major flaws (timing attacks, reduced search space, etc.).

Or maybe this generation is just stupid. Either way, they ought to get off my lawn!

TL;DR: It's not just you. This shit really is fucked.

Re:Why so high?

[disambiguated]

Once you have more than a half dozen passwords, your ability to remember them drastically decreased unless you are some sort of savant.

Absolutely. The fact that we (application developers) are dealing with passwords at all is the root of the problem here. The first time I wrote an app that did this (in 1997) I felt a little queasy about it. Yes you should use a three-tier design if at all possible. Ad-hoc queries cause many more issues than just this anyway; stored procedures should be the only allowed access from the middle tier. The password should be hashed a zillion times before being stored or compared.

But really, that's all just band-aids. We should not have to re-implement this for every application, and the user should not be subjected to the absolute train wreck of having to register and make up credentials for every fucking site. I would have thought something better would be here by now.

No amount of bitching at users or developers is going to help. This whole way of doing things needs to be tossed, and we need to figure out which one of these we want. Or something else if none of those are really sufficient. But something.

Re:Why so high?

[rthille]

I took "didn't have physical connectivity to the DB" to mean that they used Wi-Fi for extra security :-)

Re:Why so high?

[Anonymous Coward]

Developers no nothing of security. If you try to make them use it, they will say it is "too difficult" or will take "too long" and they will stick to plain text whenever and wherever possible. Combined with this plain-text attitude they will also stick to password like "123" or "abc". Both developers and end-users need to have an understanding of what is at risk when they have no security.

Re:Why so high?

[gbjbaanb]

lol, no. It meant that there was more of a layer between the web server and the DB server than just a php page with the DB credentials in it chmodded to 700.

Assume an attacker has taken over your web server with an exploit and now has full admin access to it. If there is no direct connectivity to the DB, all he can do to get at your DB is call the methods on the middle-tier services that the web server called. These are not "download all passwords" but small and tightly targetted services that only provide a smallpiece of the puzzle that ends up providing the end-user experience.

So, in practice there is nothing the attacker can do to really break your DB. He can attempt to hack the application server, and that is a fair point, but he still has to break it and if you're really doing security the app tier is running a different OS that the web tier, and is firewalled down so only specific ports can be accessed anyway and there are no similar services running on it (such as apache or IIS) that are the usual attack vectors. You also have more leeway in rejecting requests from the webserver that you do not have on the web side of things - whereas a webserver has to respond to anything the user sends to it, you can trust your webserver to only send you specific requests - and if your webserver sends you a mangled request you can rightly assume its been compromised and start to refuse all requests from it (this works best if you have multiple web servers). you raise a big alarm to the admin who can then investigate. Webserver hacks can often go un-noticed if the attacker is careful.

Assume the attacker is really skilled and has hacked your web server *and* your application server... he *still* cannot download all the passwords as they are store in tables that the app tier cannot read, all it can do is fire stored procedure requests at the DB which will only respond with what they were designed for. (none of which allow 'download all passwords')

So you see that while its not impossible to be secure in such an architecture, its damn right difficult for an attacker to really get at your precious data, So difficult they'll either be unable to do it (eg most kiddies with their downloaded apache or IIS hack cookbooks) or will find it so difficult they'll get caught, or they'll just move on to another target.

We used to have a linux web tiier, and a windows middle tier. We encrypted the DB credentials in a web.config and ran the services, each on a different user. The DB sprocs also were allowed access to only those services that required it. I would never encrypt the web tier access to the DB, because I would never allow it. An attacker could take that credential file offline and hack it at his leisure. Its best if he is not given the chance to read it at all. But worse, if he can logon as that user then he can access the DB without even knowing the password. Storing it on the easily-hacked box is the flaw here. Make it hard for them, and assume your webserver is already hacked when you code your site.

As for employees, there's not a lot you can do about that other than monitor their activity on the production server and restrict access. ensure they work in pairs perhaps and maybe (and this is radical for a lot of companies), treat them well so they don't become disgruntled!

Re:Why so high?

[Anarchduke]

Well, you could login to the website using your facebook account :-)

Re:Why so high?

[Kjella]

You can do a lot tighter security with a three-level design unless you very deliberately design the sanity checking into the database logic. For example say you're designing a online bank client, it may in theory show every transaction of every account as every user may in theory be logged in at some point. But if you've logged in as user X and rooted the web server and can query any view or call any procedure that returns data from any other user than X then you have a huge security problem.

In theory I guess you can solve it through the login procedure giving you a session ID, that session ID is used as input to every procedure and everything is validated in SQL on the database server on every procedure before returning any data, but it sounds inconvenient. Not to mention you'd like a little more to happen than just not return data, you'd want some pretty big red lights to go off if user A starts querying on B's account numbers.

That and a lot more lockdown since you know exactly what requests the web server should be sending to the middleware server, you control both sides of the communication, you don't have to deal with all the formatting and navigation and whatnot and got a fairly limited core that you can do security review on. Sounds like good defense in depth to me.

Re:Why so high?

[Ash Vince]

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.

As a php developer who works for a security company we generally do what the pen testers advise us to in regard to hashing passwords. Currently that is to use the password hash function in the latest versions of PHP.

Maybe the reason us dumb old web developers do not have your amazing knowledge at our disposal is because NOT hashing passwords is not exactly a recommended practice by any real security company.

Where I used to work we had a pretty crappy legacy product which did not hash the passwords in the DB. This was because the customer liked the fact that the system would mail out passwords if the user forgot them instead of making them reset it. When they got pen testing companies to test this product the pen testers always noticed this process and correctly deduced that the passwords were not hashed. This was then always raised as something that should be fixed, of course the customer always ignored this defect, they would make us fix anything else that was raised though.

We went through several pen tests over the years I worked there, by a few different companies, nobody thought have the passwords stored in plain text was a good idea. The fact that you think it a good idea suggests to me that either:

A) You are either some amazing outlier security guy miles ahead of everyone else on the planet.
B) You know fuck all

I reckon B

Re:Why so high?

[amxcoder]

The problem with using a password manager is that it is not much better than writing your passwords down on a piece of paper or a ledger book. Sure the password manager encrypts the passwords so they can't be accessed easily by someone, but some of the major drawbacks to me is:

1) the password manager requires a password to access, so if THIS password is ever discovered, then all the passwords are available to the attacker.
2) The password manager is software that uses data, and thus is suseptible to loosing the data (or having it corrupted/erased) by random causes, which would then render all your passwords "lost" and you would not be able to login to any websites using your current accounts. Computers crash, data is lost
3) Like cell phones have done with phone numbers, it encourages passwords that not remember-able or memorized, thus if you loose your passwords file (see item#2) or you are on another computer that does not have the manager software on it, you have no way to access any websites. For instance, your at a friends house, and need to check your email, but you can't, because your passwords for gmail are on your computer at home.
4) You are trusting ALL your passwords to a 3rd party program and company that they aren't doing anything nefarious, and trusting that they don't have some kind of backdoor to their program to retrieve the passwords, or have weak encryption, or are not simply secretly email your password list to themselves when you use their program like many private companies love to do with your data and meta data these days.

Most of these issues are similar issues to just writing your passwords on a post-it note and hiding it.

If your passwords are in your head, there is no way for a hacker or government agency to obtain them without your help. If you use a password manager, then they have a physical file that they can hack and try to recover this information from.

Re:Why so high?

[gbjbaanb]

I know plenty. The whole point is that a hashed password is simply one that takes a little time to decrypt. For example, it was reported a year or so ago that someone had built a machine from commodity hardware that could crack a NTLM password in about 5 minutes. Now a better encryption algorithm is good, but it just kicks the can further down the road. Its not a solution, just more of a sticking plaster solution.

The best security is not to allow the attacker to get the passwords at all. How many sites have you heard of that have announced security breaches that inform all their users to immediately change all their passwords? 1? 2? Oh yeah, loads. Do you think these very large sites had security experts too?

The point of saying "keep passwords in plaintext" is not a truly valid suggestion - everyone should encrypt them, but they should not imagine for a second that it will keep the passwords secure from attackers, that job is down to architectural decisions, the idea that you store them plaintext is to make people really think about their architecture. If your passwords are plain text, you think "how else can we secure these". Leave them encrypted you think "job done, that's secure!", and then sometime later you find your password DB downloaded and is being decrypted by some arsehole off 4chan and you have to tell the media that all your users should change their passwords.

Once I worked at a financial services company and the security guy gave us a little presentation. He opened up IE (for we worked with Windows at that place, like many financial services companies) and entered the URL for the web server, then types in a string of characters into the browser address bar. And we saw it open a command prompt that had full administrative access to the webserver box. That was an exploit that Microsoft fixed... but I always wonder when another one just like that will be discovered.. for all you know, it already has been and is being used right now.

That's why you do not rely on bcrypt as the only answer to the security of your passwords (I hope you use bcrypt, last time I saw PHP it still used MD5..... crackable in minutes)

Of course, you didn't mention salting, so I hope they told you about that too. Unsalted password hashes... about as useless as chocolate teapots.

So I hope I don't use sites you coded. Its not as if 3-tier architectures are a bad thing anyway, but if your webserver has direct access to the DB, its only a matter of time before someone has all your passwords and will happily cracking them open.

Re:Why so high?

[Ash Vince]

Of course, you didn't mention salting, so I hope they told you about that too. Unsalted password hashes... about as useless as chocolate teapots.

I explicitly mentioned the password_hash function in recent versions of PHP. This does the heavy lifting for you, including generating a random salt as best it can.

That's why you do not rely on bcrypt as the only answer to the security of your passwords (I hope you use bcrypt, last time I saw PHP it still used MD5.....

What in PHP used MD5? The password_hash stuff has only been in PHP since 5.5 and only ever used bcrypt. Previously some PHP developers might have used MD5, but there was nothing built in to PHP that purported to hash passwords, it was left to developers to role that own and they often did it badly. That is not the same as saying that PHP "used" MD5 for hashing passwords though.

Re:Why so high?

[disambiguated]

Hey, you said it, not me. ;)

Re:Why so high?

[s.petry]

The guy not knowing what an off line attack was one of many that seem very fishy, and yeah the moderation also raised serious red flags. Does a person really believe that they can offload authentication from a web server to a DB server without a network connection? Sure, it's possible that someone believes this, but it's sure not insightful stuff.

Re:Why so high?

[gbjbaanb]

I think you need to read up on what the system does instead of blindly following it.

PHP used to use the crypt() function, which would generate a DES or MD5 hash. In PHP 5.5 they introduced the password_hash function to replace this, but it has a mode that generates backward-compatible crypt() style hashes, so if you pass the wrong arguments to it, you will be generating md5 (or worse) hashes.

I don't mean to sound rude (even though you did say you thought I knew "fuck all") but you really need to understand what you're doing. Saying "I used password_hash so I'm golden" just isn't good enough for security. This why I repeat, storing your passwords so they are not accessible is the only solution - as far as both of us know, you've been storing your passwords in something not far off plain text anyway.

To be fair you probably are using bcrypt, but don't keep thinking that's a done deal either - this guy shows you why you should not use bcrypt :-)

Re:Why so high?

[Ash Vince]

In PHP 5.5 they introduced the password_hash [php.net] function to replace this, but it has a mode that generates backward-compatible crypt() style hashes, so if you pass the wrong arguments to it, you will be generating md5 (or worse) hashes.

It might generate crypt style hashes, but it will not ever use MD5. It always uses Bcrypt at present until something better comes along. You should have read the link you posted more closely.

There are probably ways you can screw it over though so it doesn't add any security, but the defaults are pretty secure and the php manual steers you toward not changing them unless you know what you are doing.

I don't mean to sound rude (even though you did say you thought I knew "fuck all") but you really need to understand what you're doing.

Your right, but I have the advantage that all my code is peer reviewed nowadays and we also get free pen tests and advice from a really top notch security team who are world leaders in this stuff. That does mean that if I screw up this sort of stuff it is generally noticed and I then have to fix it, that certainly helps raise your game.

Re:Why so high?

[vux984]

As for employees, there's not a lot you can do about that other than monitor their activity on the production server and restrict access.

Only storing individually salted hashes instead of plaintext passwords goes a long way to mitigating what even a disgruntled or corrupt employee can do with the password database.

Granted if the employee corruption (or hacker) runs long enough and deep enough, they could add code at front end to capture and dump passwords as they are being submitted prior to being hashed.

As a bit of a tangent...

I ran a web forum for a while once (relating to a competitive multiplayer game), and it occurred to me at the time just how trivial it would be for me to log login attempts and build a database of email account + passwords.

Based on the likelihood of password reuse, that list would likely prove valuable in general (and would probably have given me access to game accounts of a disturbingly high percentage of my fellow players, allies and opponents.

Even failed login attempts precding successful ones may be valuable, under the assumption that they used one of their real passwords on my site by accident. (I know I've done that... tried to log into site x with password for site y.)

Never use the same password on two sites that matter to you even in the slightest.

Re:Why so high?

[godefroi]

You don't pick an account and guess passwords for it, you pick a password and guess accounts for it. That way, you don't risk locking out accounts. Because most people use one of the very common passwords, you have a shockingly high chance of finding an account that works with the (presumably common) password you've chosen.

Re:Why so high?

[godefroi]

Why do you want to change your passwords regularly? Honestly, what security do you hope to gain from that?

Re:Why so high?

[Anonymous Coward]

How much does it help to hash the password a zillion (or 50) times?

I ask because I had though up a personal approach for managing my own passwords which relied on an easy to remember sentence and then an easy to remember 6 digit number.

#1 = use one of 9 different hashing algorithms
#2 = hash the password this many times
#3 = use one of 9 different hashing algorithms
#4 = hash the password this many times
#5 = use one of 9 different hashing algorithms
#6 = hash the password this many times

So if I wanted to log into some account I would go to a php app on my localhost and type in my phrase "Yahoo! was my 2econd ever e-mail address." Then punch in the 6 digits 45672(which would be the first 6 digits of my late grandmother's phone number or my first job or my first P.O. Box ). That would generate something like a2c5339ec0e4117377349304cd9541a5 and that would be the password I copy to use.

But problems were #1 Does this even really make things more secure? I have no idea. And #2 depending on the hash type used in the last step the generated password would be something like a2c5339ec0e4117377349304cd9541a5 which does not satisfy the annoying password requirements of some sites.

a2c5339ec0e4117377349304cd9541a5 would not work for iTunes because it does not start with a capital letter. It won't work for some other sites because it is too long or it doesn't contain ($%&!@). Or maybe it did contain @ but @ is not allowed on some sites. I ran across a U.S. Gov site once that said I had too many integers in my password.

I think my system could work great for me if it weren't for the silly and inconsistent password restrictions out there.

Why are we STILL discussing this?

[LaoTzePhuuk]

Le'ts just get to Two Factor Authentication everywhere and be done with this conversation!

Re:Why are we STILL discussing this?

[Anonymous Coward]

2 factor authentication is a pain in the ass. I hate it. I would rather use a really complex password. Yes, I am being selfish, because the world has more people than me, but I still hate it.

Re:Why are we STILL discussing this?

[Altrag]

That's a long time in the coming. Screwing around with a keyfob or other physical item is a pain in the ass. Sometimes a worthwhile pain in the ass, but enough of one that "everywhere" is going to be a stretch.

Unless they can make the second factor an intrinsic value (that is, something built into the computer or the OS that could be passed without the user having to physically do much.)

It wouldn't even be all THAT hard to do, but it pretty much means having to set up some sort of certificate system which requires CAs and whatnot and figuring out how to decide they're trusted and the such.

For example when Windows is installed, it generates a certificate and registers the public key with MS. When a website wants authentication it has to go ask MS for the public key. They then send you a token that you encrypt with your private key and send back as the second factor.

Have an easy-to-use system (preferably client-to-client directly to limit MITM attacks) to clone your certificate between your various devices and you have a fairly decent second factor without too much hassle for the user.

The hard part is getting everyone to agree on how to do this. Its not going to work if my Windows machine uses a different authentication system than my iPhone which uses a different system than my Nexus tablet. It would have to be standard across _all_ devices.

Re:Why are we STILL discussing this?

[HiThere]

Two factor authentication is no more secure than a longer password. (Granted, it can easily be the equivalent of a MUCH longer password.)

FWIW I think we should switch from passwords to pass phrases. "All cows eat radishes" is much harder to guess than "#iOpqn23!"

Re:Why are we STILL discussing this?

[Anonymous Coward]

Bzzzt. Wrong. You've suggested what is essentially a 4 character password. If we switch to passphrases, each word functions as a symbol. If a given person has a vocabulary of 10,000 symbols, you're pretty screwed. 10,000^4 is the same as 10^16. The random password you suggested requires letters (upper and lower case), symbols, and numbers. That's about 94 different potential symbols, but raised to the 9th power, which is around 5.73 * 10^17. Already a larger search space.

Exponential functions always grow faster than linear functions. Not only that, but what the words a person chooses are likely to be in the most common of their vocabulary, reducing the effective number of symbols to more like around 1000.

You can throw in letter-number substitutions and such, but do you really think that current generation password cracking tools don't take that into account during dictionary attacks?

Re:Why are we STILL discussing this?

[Anonymous Coward]

Because I don't want to give every company my phone number.
Because I don't care if most of my accounts get hacked. There's only a couple that are important.
Because it's so much easier to type in a password than always carry around another item.
Because every website will do their 2-factors differently.
Because most of those 2 factor sites will still be easily broken into.

Why aren't web devs competent enough to secure their sites? It's almost 2015. Why are we STILL discussing this?

Re:Why are we STILL discussing this?

[HiThere]

I think you misunderstand my prosal. No particular part of the pass phrase can be guaranteed to be in a dictionary. They just need to be memorable for some reason. (Even with your understanding of what I meant, I believe that you miscalculated.)

I will admit I could have used a better example, but I'm not suggesting that the peices should necerssarily for words of any extant language, merely that they be memorable. I would restrict it to things that I can enter from my keyboard, but that, to me, seems reasonable. Intentional misspellings are desireable in this context, but I was just whipping up a short, quick example, and didn't consider it carefully. Even so you underestimate the number of words. English has a dictionary of on the order of 5 million words, though that may be including technical vocabularies. Then add in punctuation as desired and the occasional number in an unpredictable place and...

What I'm really proposing is lifting the limit on password length...or at least extending it to 512 characters...and using all of them in computing a base 64 (or 128) code from that. (I'm not considering salting, because I'm only here talking about an individual password, but tables of passwords woudl need to include that.)

Additionally, if thinking about logon attempts, if failed logon attempts result in increasing delays before the next attempt if permitted, even the current systems are sufficient. This has the problem that you may need to disconnect your machine from the internet before you'll be able to access it, but in many cases that's a trivial price. If it isn't, then you need another approach, such as whitelisting certain ip address numbers, so that they never exceed 5 minutes between allowed attempts.

14 length passwords?

[ThorGod]

Am I wrong for thinking this means you just need a string of totally random numbers from 0-9? (or even a-Z, 0-9)

Re:14 length passwords?

[tqk]

Am I wrong for thinking this means you just need a string of totally random numbers from 0-9? (or even a-Z, 0-9)

Or "totally random numbers from 0-9? (or even a-Z, 0-9)" plus punctuation chars, plus not made up of words which could be found in any dictionary, plus not made from anything that could be gleaned from your online activities or through social engineering.

I think I'll stick with ssh, post interfacing with a real human face to face.

Even 100,000,000,000,000 is too small

[Anonymous Coward]

log2(1,000,000) is only 19.9 bits.
log2(100,000,000,000,000) is 46.5 bits.

An 8-character random password with upper/lower+numbers only has log2(62^8) = 47.6 bits.
If you're serious about security, use something longer. A 16-character password has 95.3 bits.

tl;dr: Memorize a random 16-character password, and use it to to access your password vault of other 16-character random passwords.

Re:Even 100,000,000,000,000 is too small

[Archangel Michael]

My very secure password, is well over 100 bits of entropy. Easily extendable when the time comes.

But that is not the problem. We're using a Secret for single factor identification. Real identification is multi-factor and requires non-secret means for identity, and then a secret for proof of identity. Non-secret identification requires a web of trust. Online systems have neither non-secret web of trust Identification nor proper secret proof of Identification.

Re:Even 100,000,000,000,000 is too small

[NotSanguine]

log2(1,000,000) is only 19.9 bits. log2(100,000,000,000,000) is 46.5 bits.

An 8-character random password with upper/lower+numbers only has log2(62^8) = 47.6 bits. If you're serious about security, use something longer. A 16-character password has 95.3 bits.

tl;dr: Memorize a random 16-character password, and use it to to access your password vault of other 16-character random passwords.

Even better, pick some song lyrics as your password -- especially lyrics you have wrong inside your head. That way the password can be really long and extremely difficult to guess. Add in spaces and punctuation and it's even better:

There must be some kind of way out of here, said the joker to his feet

would make an excellent password. And It's really easy to remember. Much easier than something akin to correcthorsebatterystaple

Re:Even 100,000,000,000,000 is too small

[Anonymous Coward]

"There must be some kind of way out of here, said the joker to his feet"

Too many characters, contains an illegal character, doesn't contain a number.

Re:Even 100,000,000,000,000 is too small

[NotSanguine]

"There must be some kind of way out of here, said the joker to his feet"

Too many characters, contains an illegal character, doesn't contain a number.

Oh, absolutely. Because all password applications and databases have the same limitations and configuration, which can never be modified. Sigh.

Re:Even 100,000,000,000,000 is too small

[Altrag]

requires non-secret means for identity

Not exactly true. It can to be a secret that the user themselves don't know. Many (most? all?) keyfobs work that way. The fob itself has a secret that only it and the fob provider know. And in particular, its a secret that you as the fob user doesn't know.

Re:Even 100,000,000,000,000 is too small

[Anonymous Coward]

There must be some kind of way out of here, said the joker to his feet

In practice, this might indeed be a good password, but solely because currently only few people use such a long sentece as a password and attackers therefore don't consider it when choosing candiate passwords in a dictionary attack.

Mathematically speaking, I wouldn't be too sure about it.
A while ago I generated a wordlist from the whole content of the english-language Wikipedia, ordered by frequency of occurence. Almost all of the words in your sentece occur in the first ~1500 words of this list. Granted, if you assume that the 16 words in your sentece were all chosen uniformly at random from a set of 1500 words, like in xkcd's example, it would really be a very strong password indeed (log2(1500^16) = approx. 169 bits). But they weren't. There is a lot less entropy in it as it is gramatically correct sentence. The words are not uniformly distributed at all. I'm fairly sure that even if you choose a really simple statistical model for the english language, you would find that your sentece is not very random at all.

Re:Even 100,000,000,000,000 is too small

[tepples]

Because all password applications and databases have the same limitations and configuration

Many systems in use have similar "limitations and configuration".

which can never be modified.

Many systems in use "can never be modified" by end users.

Re:Even 100,000,000,000,000 is too small

[Anonymous Coward]

There must be some kind of way out of here, said the joker to his feet

Not anymore. ;D

p.s. Actually I'm really surprised that your comment is the only hit in google for "said the joker to his feet," since it is a well known butchering of the first lines of All Along the Watchtower. I'm sure I heard that exact wording back in the 70s/80s, but you're apparently the first person that ever typed it someplace that got indexed by google.

Re:Even 100,000,000,000,000 is too small

[Anonymous Coward]

There is a lot less entropy in it as it is gramatically correct sentence.

Like you'd know.

Re:Even 100,000,000,000,000 is too small

[manicb]

"There must be some kind of way out of here, said the joker to his feet"

Too many characters, contains an illegal character, doesn't contain a number.

This. Right here. Every time I come up with a password that is both strong and memorable.

Re:Even 100,000,000,000,000 is too small

[Archangel Michael]

A key fob doesn't prove identity. It is a secret generating device. If I have your key fob, it doesn't prove I am you, or that I am a counterfeit. It proves that I have your key fob.

Re:Even 100,000,000,000,000 is too small

[Altrag]

Right. And if the second factor is a fingerprint, having my fingerprint only means that you've cloned my fingerprint (or cut off my finger.) It doesn't prove that you are me.

The idea isn't to guarantee perfect security (that's impossible.) The idea is to provide a minimal level of guarantee.

In this case, its very unlikely that you both know my password AND have grabbed my keyfob, unless I've specifically allowed you to do so. You can lose a keyfob sure. But that by itself tells you nothing.. not even what account its for generally and sometimes not even what site/program.

Similarly you can have your password stolen (keylogger or whatever) but without the keyfob, that password is similarly useless.

Hence two factor -- one factor is something you know (the password) and the other factor is something you have (the fob.) Either one could be obtained by an attacker with (relative) ease, but BOTH being obtained at the same time is fairly unlikely.

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.

Re:Per-user salting

[Anonymous Coward]

I've done exactly one webapp where security mattered and this was 10 years ago. What I did was I used a sha-based hash with two part salt; one part was per password (md5sum of creation time + random text) and the other part of the salt was shared between all passwords. Yes, a little bit of obscurity there, but supposing the hackers only got the password database it'd be useless for offline attacks without the systemwide salt. It makes me fucking cringe to hear how lacking the password protection on most sites has been, especially since I don't really do web or security stuff.

Re:Per-user salting

[Fweeky]

How many people do per-user salting of the password hash?

People spouting things like this is precisely why we have tens of millions of web apps using shitty password storage solutions that boil down to HASH(salt + password) and are thus borderline fucking useless. It's like asking if someone's home-grown encryption algorithm uses an IV - that might be an important part of it but it's kind of missing the point.

If you're using passwords for authentication in your app, use a recognised key derivation function. Use PBKDF2 or bcrypt and tune them to take at least 100ms to run. If you're extra paranoid, use scrypt and tune it to take 100ms and 16MB of memory. If you're doing anything else without having a well-received peer reviewed academic paper describing it, you might want to reconsider.

Re:Per-user salting

[phantomfive]

Two-factor auth is a big win, of course.

It's a double-edged sword. Do you really want every website out there to be able to track you based on your phone number?

Re:Per-user salting

[Anonymous Coward]

Having read your post, I can't help but feel that you didn't quite grasp what lgw was talking about.

His point was that every user's password should be salted with a string that's specific to them. Thus the password hashing function would look something like password_hash(hardcoded_salt_common_for_all_users + db_stored_salt_unique_to_this_user + password, algorith_to_be_used)... As opposed to just using a single salt for all users (as many web applications do).

This approach effectively prevents using a rainbow table to attack a database full of hashes. As this is the main method to break a large amount of hashes, calling this "borderline fucking useless" without elaborating it further made me feel you two weren't speaking about the same thing.

I have yet to work with a single web application that didn't use some well-established and relatively robust KDF. I'm sure many use something that's not the optimal but if I had to choose whether all the services I use would switch to proper salting practice (single static salt -> individual salts) or improve their choice of salting algorithm (sha -> bcrypt) and its configuration, I'd absolutely choose the first one. And that's even without having to think about things such as server performance.

Re:Per-user salting

[lgw]

I've used a half-dozen two-factor auth solutions between different finance sites and different employers in the past 5 years, and non of them have used my phone. I see that from email providers, as it's the cheapest possible solution (which, still, far better than no solution). I wouldn't use anything phone-based for banking, to be sure, as malware targeting phones is so damn common (plus physical theft of the phone happens), but that's just me.

Re:Per-user salting

[lgw]

You'd be better served in life by less arrogance and better reading comprehension. I can understand that attitude from someone in their early 20s -- at that age life can still seem simple and thus everyone's an idiot for not agreeing with you -- but I rather think you'd need hexadecimal to still be in your 20s.

Do you understand that PBKDF2 is chained iterated hashing, and informally calling that process just "a hash" is normal? Do you get that rainbow tables make it easy to retrieve a percentage of passwords from a large credentials store, but only if they all use the same salt? Changing the salt (the salt parameter to PBKDF2 or whatever) in some per-user way defeats this.

Building a rainbow table of 1 billion likely passwords with a 100ms hash only takes 30k core-hours. 10 years ago that was a big deal, but now that's one day and a few hundred bucks on a commercial cloud, or cheaper on a botnet. (And I'd bet there are hardware solutions that make it trivial.)

solution: don't try to remember them

[Anonymous Coward]

Here:

$ pwgen -N 3 20
OSohG7ohbee0yu1CohPh vohR7gah4ip3ti4so3in aj5eiPaiqu6ohpeoh2ku

That's all the harder it is. Don't remember passwords: keep them on a physically secure device protected by ONE password you remember. Then someone has to do two things: steal your secure device, and break the master pw. Yes, could happen, but very unlikely.

If a big three letter agency is after you personally you're fucked no matter what. You only need to protect yourself from the common crook - be more secure than the 99.9%, and that's what you need.

Re:solution: don't try to remember them

[Anonymous Coward]

If a big three letter agency is after you personally you're fucked no matter what.

Not necessarily. Even big three letter agencies have their limits, and they're not magic.

Re:solution: don't try to remember them

[PurpleAlien]

Make that:

$ pwgen -N 3 -y -s 20
Q^lu)bgREy3c$OH5PmGI 95Q~\\1?"W#S9*yDa1)A c0UX4]?e$1{WjM3N7inI

Re:solution: don't try to remember them

[HiThere]

If you can get at the info, a TLA can coerce you into giving them the information. Unless you're both willing to die and to be tortured to protect the information, you can't both access the information and keep it from them, if they're determined. Of course, if they're just mildly curious you can do it, but then things that work against the phone company should work.

Re:solution: don't try to remember them

[skids]

Don't remember passwords: keep them on a physically secure device protected by ONE password you remember.

Ok, so we give a password manager device to all the users that cannot be trusted to create strong passwords, or if given a long password will write it down, probably on a sticker attached to said device. Then, they take 4 times as long to log into things since they constantly have to unlock their password manager, and each time they do so open a window to keylogging or sideband attacks on the same password. And they leave their passwords hanging around in cut and paste buffers. Finally they lose their "physically secure device" in a public location and expose it to an offline attack, and possibly also lose their written-down copy of the master password.

Not a fan of those systems.

Re:solution: don't try to remember them

[Damarkus13]

Are there really password managers that don't purge the clipboard a few seconds after copying a password?

Re:solution: don't try to remember them

[Anonymous Coward]

If there are, you shouldn't be using them ^_^

In any case, I do use a password manager. I can make arbitrarily complex passwords and not worry about the length or how hard they are to remember.

Too bad a lot of sites can't handle much in the way of passwords. Banks and other financial institutes are the absolute worst for this. Anyone running their own phpBB forum can handle much longer and more complex passwords than any bank or financial institute I've ever had an account for. Some of them still limit you to 8-16 characters, all alphanumeric. It's completely ridiculous.

Given Up

[Anonymous Coward]

I've given up trying to get other people to use decent passwords. I don't care how you get enough length or complexity. Personally, I CAN remember long strings of garbage, so running pwgen with symbols, letters, numbers, and mixed case, then yoinking out a random 16-24 characters works for me. Thats something like a 94^16 through 94^24 space to search for my password.

I write it on a *small* piece of paper which stays on my person for the next week. By the end of the week, I have it memorized (largely as muscle memory). Then I burn the paper and flush it. Done. I have throwaway passwords which get used for most stuff that doesn't matter, and each separate service which is important gets its own password. They change about twice a year. For example, my Slashdot password is the same as my password for Reddit. You can't get into anything important from them. However, my email and my bank account have their own, individual passwords.

Good luck cracking it. No, I'm not trolling, and I realize that most people can't remember garbage like that, especially not in any reasonably short amount of time--but that's their problem. I don't have a good answer for everyone else. Tough cookies. Maybe use a password manager?

Re:Given Up

[Anonymous Coward]

One thing you shouldn't do is post all the details of how you choose your passwords online, even as an AC.

Re:Given Up

[Anonymous Coward]

+5 Insightful!

Re:Given Up

[Anonymous Coward]

Waaah. pgwen. You can go download the source code for it.

Repeat after me: security through obscurity is not security at all. If the method can't withstand public scrutiny, it's inherently flawed to begin with.

Fucking NSA shills and bloody idiots.

Hash multiple times

[Anonymous Coward]

Well if you hash the passwords 10.000 times over so it takes around a second to login, both offline and online bruteforcing is 10.000 times harder. Easy fix.

Re:Hash multiple times

[weilawei]

Until someone generates a rainbow table for that. More important is to salt passwords individually and use a hash function with a work factor, instead of a hash designed to be run quickly.

Re:Hash multiple times

[Anonymous Coward]

Until someone generates a rainbow table for that.

Sure, but they will also be wasting their time trying to generate the rainbow table for the exactly amount of times the passwords were hashed. You can easily randomize the amount of times each password is hashed beyond a specific minimum and those hash tables are effectively useless because not only will you need potentially a large amount of rainbow tables but you won't know which one to use for each password. At that point you're no better off than simply brute forcing.

Re:Hash multiple times

[weilawei]

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.

Re:Hash multiple times

[Anonymous Coward]

When you hash something twice, you've limited the input space to the second hash function to the output space of the first function. This is often smaller than the thing you were initially hashing.

Instant flaw, and not immediately obvious.

Re:Hash multiple times

[Anonymous Coward]

This. Fellow cryptographer here. What GP is suggesting is exactly the reason why we warn people not to do home-brew crypto. We don't just mean that non-experts shouldn't try to invent a replacement for AES or Diffie-Hellman, as most developers are actually smart enough not to try that. But it is exactly the supposedly "easy" stuff like password hashing that they routinely get wrong.
As the parent said, the chance of screwing up something that you maybe just didn't think about are very high. And the details are also easy to get wrong. The salt size should be at _least_ 32 bits. If you take that into account, the iteration count (which is acting as the salt in GPs scheme) would have to vary somewhere between a static offset (let's say 5000) and 2^32. Now try to caculate a SHA512 hash with 2^32 iterations. Even on the fastest computers today with a highly-optimized implementation, this is going to take _much_ too long to be practical in many of the cases (order of several seconds up to a minute). Now imagine that this has to be done on an embedded device, or on a busy server with thousands of users.
Also, the salt size should be fixed, whereas the iteration count could be made flexible in order to adjust to the computing power of a machine. This cannot be done with this scheme.
That aside, even if it didn't take prohibitively long, some users would be able to login in a matter of miliseconds (at the cost of having a smaller security margin) while others would have to wait a few seconds for the hash to be calulated. So even from a non-crypto standpoint, this scheme is stupid and there is no reason to use it, as it does not offer any advantage at all over existing schemes (apart from putting people suffering from NIH syndrom at ease).

So, why not just use an existing, well-known scheme like bcrypt, scrypt, or PBKDF2?

Re:Hash multiple times

[Anonymous Coward]

some users would be able to login in a matter of miliseconds (at the cost of having a smaller security margin) while others would have to wait a few seconds for the hash to be calulated

That sounds like a timing attack waiting to happen. So there goes the randomization of the OP.

Re:Hash multiple times

[Anonymous Coward]

Sounds a bit naive to me.

Homebrewn crypto has a good overall effect, because it forces 'interested parties' to cryptanalyse all that (mostly bad) crypto and recode it into for their systems to hook it up with their rainbow tables and gigantic passwordlists. That can create huge problems for them. Cryptanalysis and reverse engineering is very expensive and they have only limited manpower for this kind of work.

That's why government agencies love standardized cryptography, it reduces their workload tremendously.

Re:Hash multiple times

[Anonymous Coward]

NSA shill detected!

You're full of shit. Homebrew crypto often has blindingly obvious flaws to someone who's studied cryptography which are not so obvious to the average developer.

You're the naive one (or the NSA shill). Stick with what works and don't rely on insecurity through obscurity.

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.

Why are we still using passwords?

[jdege]

Why are we still using passwords?

Pass phrases are far more secure, and easier to remember.

http://xkcd.com/936/

Re:Why are we still using passwords?

[sexconker]

Because people like you still link to that shitty comic that's been debunked over and over and over.

Re:Why are we still using passwords?

[Anonymous Coward]

Because XKCD sucks.

Re:Why are we still using passwords?

[Stan92057]

I've never had my passwords guessed. They have been given away by the likes of Target,Wallmart,Sony,Facebook,EA, and the long long list I don't even know. 1 brute force attempts must be blocked period end of story. Any business who has customer data in an unencrypted formatte when stolen..opps Given away, must be fined 50 million dollars per customer data stolen..opps given away. You laugh at 50 million I am however not laughing. its time to get serious

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:Why are we still using passwords?

[jbolden]

That's a great comic! If only people checked that the phrase being used were unconnected with them far far better system.

Re:Why are we still using passwords?

[markass530]

replace 1 letter in each word with a number and use numbers as spacers, problem solved

Re:Why are we still using passwords?

[Altrag]

And you fail your check when I use Correct instead of correct.. or corr3ct.. or whatever. That adds a LOT of complexity to the basic 4^10k. Throw in variable punctuation and spacing and things start looking a little uglier to an attacker.

And yes, 16 completely random characters is probably still harder to crack, but how many people use completely random characters? How many people would be able to remember their passwords even if they did make such a one? And if you're using a password program rather than trying to remember it, you may as well make it 64 completely random characters cause why not.

There's a tradeoff between perfect security and practical security. You can't just assume that because your favorite scheme is 10 or 100 or 10^100 times more secure than the one that's currently in use that anyone's actually going to switch if it means an enormous amount of extra work on the part of the users.

Re:Why are we still using passwords?

[zippthorne]

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.

Re:Why are we still using passwords?

[Anonymous Coward]

When you start requiring passphrases to use RanDoM cAps or l33t sp34k or symbols#for$whitespace, you lose their main advantage as an alternative to random alphanumeric passwords: ease of memorization. Essentially what you end up with is exactly the current password situation, but with much longer passwords that people will be that much more likely to write down (or worse, store in a text file on their computer!).

Re:Why are we still using passwords?

[Anonymous Coward]

'Anonymous Coward' - October 2014:

OK, bait taken.

Thomas Duncan - 1
Nina Pham - 2
Amber Vinson - 3
Nebraska Biocontainment Cameraman - 4
Anonymous Emory Patient - 5
Newark Patient - 6
Chicago two - 7 and 8, more than likely.

That's one to go, and today is only October 22.

How are your Newark Patient and Chicago two feeling today, sexconker?

Re:Why are we still using passwords?

[julesh]

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.

Err... that's rather faster than any CPU or indeed GPU I've ever heard of. Depends, of course, on your hashing algorithm, but the fastest I've ever heard of is 3.5 x 10^11 NTLM hashes, which wasn't a single CPU but a cluster of 25 GPUs, so call it 2x10^10 for a single processor, or approximately 2 orders of magnitude slower than your suggestion of what is "easy" to achieve.

Also note that this was NTLM, which is a lot weaker and easier to calculate than most of the algorithms used by web-based systems today. The same cluster only managed 71,000 hashes per second against bcrypt, which is the algorithm that is usually recommended for new systems at the current time. That's about 3,000 hashes per second per processor.

So cracking that XKCD-style password in less than 3 hours...? Not in reality it can't. That's 10^12 possible passwords. If they were hashed using NTLM and you were using all 25 nodes of the fastest password cracking cluster that has been publicly described, and they were as short as the passwords used in the original benchmark it would take about 3 hours, yes. But (1) nobody seriously uses NTLM, and (2) few attackers have that kind of hardware available, with cost estimated at around $30,000.

Used on a site complying with modern standards of password encryption against a realistic attacker (a script kiddie using a couple of high-end gaming system with 2 top-end GPUs, thus cranking out about 10^4 bcrypt hashes per second) your XKCD-style password would last about 5x10^7 seconds, or approximately 1.5 years.

Change your password every 6 months and as long as the site uses modern encryption techniques you'll be just fine.

Re:Computers: They can respond fast -and- slow

[Anonymous Coward]

And that does nothing for an offline attack. Salting your passwords individually is a good start. As is using a hash function with a parameter for delay, instead of a hash function designed for speed.

Re:Computers: They can respond fast -and- slow

[Empiric]

Try entering multiple incorrect passwords into your offline *nix box of choice. See how it responds.

Something is so very wrong with a web site or soft

[Stan92057]

Something is so very wrong with a web site or software program that allows any kinda brute force password cracking attempts. How many times can I type in a guess to a web site I might have forgotten the password too? Its way less then 10 in 1 minutes time I can tell you that.

Make the salts non-trivial

[craighansen]

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.

Re:Make the salts non-trivial

[WaffleMonster]

Encrypting the password with a small salt is enough to slow down simple password guessing with rainbow tables.

What is the practical effect on a password list when rainbow tables are taken off the table?

Yes much easier everyone gets that...so what ... what does this actually mean in the real world?

Say I have a password list with 10000 accounts, they are all salted.. I'm still going to be able to recover thousands of passwords without much effort... still adds up to epic failure with or without salts.

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.

Symmetric keys are a much better idea than the dangerous delusion too many people seem to be subscribing to that clear text storage of salted password hashes affords users any meaningful protection.

In that way, 2-factor encoding works for the password data itself.

Nope this counts only as tweaking integrity of a single factor.

Re:Make the salts non-trivial

[Anonymous Coward]

Say I have a password list with 10000 accounts, they are all salted.. I'm still going to be able to recover thousands of passwords without much effort... still adds up to epic failure with or without salts.

You can't save users who use 'aaaaaa' as a password. No matter what you do. Otherwise, you're not going to recover thousands of strong passwords properly salted and hashed. It just isn't going to happen. If you do know how to make it happen, you should be working for the NSA, not commenting on Slashdot.

Symmetric keys are a much better idea than the dangerous delusion too many people seem to be subscribing to that clear text storage of salted password hashes affords users any meaningful protection.

What are you going to protect with that symmetric key?

The password database? It'd still need to be accessible to the machine holding the database, in order to login.

The user's data itself? Well, I hope you plan on doing all crypto routines client side, because you're back to storing passwords ("symmetric key") in plaintext if you ever transmit that to the server.

A symmetric key is also called a SECRET KEY for a reason. It needs to be kept SECRET. It's exactly equivalent to a very long password in plaintext.

Properly salting and hashing is the correct solution. Have you checked your oil lately?

Re:Make the salts non-trivial

[WaffleMonster]

You can't save users who use 'aaaaaa' as a password. No matter what you do. Otherwise,

What about the user who uses 11elephant82 as their password? Are they doomed as well?

you're not going to recover thousands of strong passwords properly salted and hashed. It just isn't going to happen.

It will happen easily. The only thing that isn't *ever* happening is people using strong passwords relative to current and projected cost per transistor.

What are you going to protect with that symmetric key?

The password database? It'd still need to be accessible to the machine holding the database, in order to login.

Yes this is just punting responsibility for keeping a secret. Whether punted to physical keys, operating system keychain, TPM circuits or manual startup inputs all of these things do a better job than tens of thousands to millions of hashes stored in the clear on disk.

Regardless password does not need to be accessible to machine holding the database offering some (small) protection against theft while still being much better than nothing (e.g. hashed passwords with a proven track record of epic fail after epic fail)

Properly salting and hashing is the correct solution. Have you checked your oil lately?

I'm afraid to, daily commute to Langley is taking its toll.

Re:Make the salts non-trivial

[chgros]

I'm not sure you really understand how salting a password works.
There's never any point in "trivial" salt.
Salt is a public random value (randomly generated for each password), the same size as the hash. It's stored in plaintext alongside the hash.
To check the password, you hash <salt><password>. It's effectively impossible for <salt><password> to be in a table no matter what <password> is. It doesn't prevent brute-forcing the password in other ways of course.
I'm not sure what your deep-deep-dark secret password would enable.

Re:Make the salts non-trivial

[craighansen]

Perhaps you are unaware that a typical salt has historically been much smaller than a password. UNIX systems had a 12-bit salt, BSDi extended to 24 bits and earlier Linux systems had a salt of 48 bits. Only fairly recently has a salt of 128 bits come into use. Salts that were considered adequate in the past, should now be considered trivial.

The point of having a deep-deep-dark-secret password would be to permit the existing infrastructure of textual salted password files, but to augment that with an additional "salt" - thus making validation depend on two factors - the password file as before and second factor of the DDDS password. We've seen many releases of password files, as they seem to be widely distributed from systems that have been broken into. Keeping a second factor elsewhere would complicate the use of purloined password files.

Re:Make the salts non-trivial

[Anonymous Coward]

It will happen easily.

You greatly underestimate the difficulty in breaking 512 bits of entropy. The Universe will die of heat death sooner than you break it. Note the word "strong". Again, you can't do anything for idiots who use permutations of dictionary words. "11elephant82" has about 5 symbols worth of entropy. Pathetic.

If you use a secret key, it needs to be loaded into memory, as does the password database. Guess what? If I can get at the disk, I bet you I can dump the contents of memory. Game over. Symmetric encryption isn't some magical pixie dust.

If the key isn't directly accessible, that means that I have to send the encrypted password to a chip and it has to send the decrypted password back. That's plaintext on a wire and in memory. You've already lost. With proper hashing, the password is NEVER in plaintext. You can even run the hash on the client side so it's never transmitted, if you're extra paranoid.

Alright, I'm through with this troll. Someone else's turn.

Re:Make the salts non-trivial

[WaffleMonster]

Again, you can't do anything for idiots who use permutations of dictionary words. "11elephant82" has about 5 symbols worth of entropy. Pathetic.

The world is full of "idiots" otherwise known as people who have better things to do then remember things they are either incapable or lack sufficient motivation to remember.

For a solution to have value to real people in the real world it can only cost as much in time/money/convenience as people are willing to spend/accept.

Decades of experience makes it crystal clear too many people reject secure passwords and nothing we do or say will ever change that... Calling everyone names or blaming users for their poor choice of passwords after a server compromise is not only worthless waste of time that helps nobody but ignores the fact the systems compromise = epic system/administrator failure + blaming the victim. When you get hacked it isn't the users fault so what business do you have asking more of them to hedge against compromise that should not occur in the first place?

If you use a secret key, it needs to be loaded into memory, as does the password database. Guess what?

No shit. You can still create systems with high security with physical separation of concerns. Here is an example architecture:

Application server + database server teaming with millions of reversibly encrypted passwords.

Separate specialized authenticator server with encryption key and separate trust relationship to application server.

User authenticates using zero knowledge proof method... authentication material passed directly from user, thru application stack to authenticator... authenticator looks up password in application database, completes mutual identity verification and sends approval token to application stack.

The only way compromise of credentials occurs in the above scenario is if the authenticator server which does nothing except authenticate is compromised. Even if the application and data stacks are fully compromised user credentials are still safe for all the good that does.

If the key isn't directly accessible, that means that I have to send the encrypted password to a chip and it has to send the decrypted password back. That's plaintext on a wire and in memory. You've already lost. With proper hashing, the password is NEVER in plaintext. You can even run the hash on the client side so it's never transmitted, if you're extra paranoid.

You have it exactly backwards. The authenticator server or hardware only needs to provide a token to the application stack it is not necessary to send clear text passwords anywhere see my example above.

Your example fails because you have three and exactly three options and **NONE** of them work.

1. Send clear text password from user to compare with stored password...This fails as password is required to be transmitted for comparison operation.

2. Use a challenge/response protocol or ship hashes.. This does not work because all such protocols are subject to offline attack while your logging in an easedropper can obtain enough material to run an offline attack and recover credentials.

3. Use a zero knowledge proof of possession to authenticate. This fails because even if you use a hashed password possession of the hash is what is being verified and so having a copy of the hash becomes just as valuable as having a copy of the plaintext.

Alright, I'm through with this troll. Someone else's turn.

Unfortunately in the real world our fairy tales don't get to come true just because we feel empowered to call our users "idiots" and blame them when we ask too much of them or otherwise provide security solutions that are not operationally practical.

My example architecture allows passwords to be only as secure as necessary to prevent *online* attack and clear separation of concerns prevents system compromise from affecting stored credentials regardless of how complex or vulnerable the application and data tiers become.

hunter2

[sir_eccles]

Quick someone mention the horse password thingy

Laws to set minimum value personal information

[Anonymous Coward]

Set the basic value LEGALLY of unauthorized obtaining any ONE persons personal information/accessing their financial accounts to be a sufficient minimum to make the crime Grand Theft (a felony) with multiple incidents to be additive for conviction penalty.

Will need strengthening the response to criminals who think they are safe when they commit the crime across a national border.

Re:Computers: They can respond fast -and- slow

[Stan92057]

I believe they don't want to stop it that will stop them from doing things they already know they shouldn't be. Im with you take the toys from the scriptkiddies tool box

Re:Something is so very wrong with a web site or s

[Anonymous Coward]

*gasp* the database can be stolen and brute forced offline

Too many attempts, try again later.

[JazzHarper]

You don't need long passwords, just reasonably good ones, to defeat online guessing. Estimates of how quickly billions of guesses can be performed assume that all your encrypted passwords have been downloaded and can be subjected to brute force, offline. That means your security has already been compromised.

Re:Too many attempts, try again later.

[Anonymous Coward]

AC due to moderations, but the whole point of this discussion is that one must assume that the password database will be stolen eventually. This is why people are talking about salts and hashing and what-have-you. Defeating on-line guessing is relatively trivial since limiting the guesses to a hundred or so inside of a week (a huge number relative to the policies of most sites) would prevent attacks against all but the weakest passwords. Requiring two-factor auth for a password reset would safely take care of those too dense to remember their passwords, and then the only problem you're left with is dealing with a stolen database.

Re:Too many attempts, try again later.

[Anonymous Coward]

Exactly. If hackers got your password file, which should be your best protected secret - what do you still want to protect using the passwords?

Which is of course exactly the point of the submitter: strong passwords are pointless.

I would go further: strong password rules are counter productive. I have a site that keeps refusing high entropy 12 characters passwords, because it requires 2 digits. User start writing down passwords. All kinds of bad things happen because of badly thought out security policies.

Re:Too many attempts, try again later.

[Anonymous Coward]

Agreed. The variation of password rules means that any algorithm a person uses to come up with a password ends up being site-specific. Some site require special characters, but ban certain special characters - some sites ban special characters altogether. Some of these seem to be concerned that people will use the "Little Bobby Table" http://xkcd.com/327/ name as a password by banning the dollar sign or apostrophe - the thought that systems might be vulnerable to quoting problems in the password gives me the security creeps in a really special way.

Re:Computers: They can respond fast -and- slow

[Anonymous Coward]

Yeah, that's not an offline attack, though. An online attack is one made against a running service - like your *nix box login screen. An offline attack is when you have the password hash in front of you and get to crack it at your leisure.

Re:Computers: They can respond fast -and- slow

[weilawei]

Do you know what an OFFLINE attack is? Hint: it's one where you're NOT sitting at a login prompt.

Wow.. the stupid in this one is strong. Let me explain it: an offline attack is where you have the password database itself and don't need to wait for a login program. You're free to hash things as fast as you like.

And Republicans are incapable...

[Anonymous Coward]

of comprehending his which is why their solutions of beating criminals will never work. It is the passwords that are the problem. They can't understand that. They are so stupid.

LOL, my CAPTCHA is ovaries which is something the Republicans hate.

If your system really matters

[royallthefourth]

Implement two factor authentication. It's not hard program nowadays and it makes your login system far more resilient to password related fuckups from your users.

Mozilla Persona / BrowserID

[Anonymous Coward]

I really want to see Mozilla Persona succeed.
It is the correct (technical) way to do "simple" web authentication, especially when your provider does multi-factor auth or something equally safe.

Passwords are outdated, and even half-assed systems like Facebook Connect or OpenID are better in my opinion.
Personally I use something I call "Login by Email" that almost every site supports, only they call is "Forgot password" and require me to enter a random string every time.

Re:Computers: They can respond fast -and- slow

[Empiric]

No need to. "Offline" means precisely how I used it. That you have a more qualified usage in mind is something I'd address when it was stated.

Re:Computers: They can respond fast -and- slow

[weilawei]

No, it doesn't mean what you think it means. It has a specific meaning in relation to security. It has absolutely nothing to do with whether or not a box is connected to a network.

You're showcasing your complete incompetence by talking out of your ass. Just shut up already.

Re:Computers: They can respond fast -and- slow

[Anonymous Coward]

Show any source that says an offline attack is what you think it means.

What ever happened to biometrics?

[mmell]

Two factor authentication for most applications - something you have, something you know will do nicely. Three factor authentication for the sensative stuff - something you have, something you know and something you are.

Re:Something is so very wrong with a web site or s

[JazzHarper]

If the database can be stolen, then that, in itself, IS the problem.

Re:Computers: They can respond fast -and- slow

[Empiric]

https://en.wikipedia.org/wiki/...

Under the direct control of another device
Under the direct control of the system with which it is associated
Available for immediate use on demand by the system without human intervention

Apparently a more specific usage was intended, though. Fair enough.

Re:Computers: They can respond fast -and- slow

[Empiric]

Linked below.

Re:Computers: They can respond fast -and- slow

[weilawei]

The phrase "offline attack" is not the word "offline". Tough concept, I know. The AC above said "offline attack", not "offline".

You need to shove it, because you have NO IDEA what you're talking about.

Re:Computers: They can respond fast -and- slow

[weilawei]

Again, the phrase "offline attack", which is what the AC used is NOT the same as the word "offline" used all by itself.

How hard is that to grasp for you? You're here spouting off suggestions for cryptography/security without knowing the most basic terms.

Re:Computers: They can respond fast -and- slow

[Empiric]

Sorry, I can in fact parse the sentence as an attack that occurs "offline", as well as a more selective usage parsing it as "offline attack".

Good luck with your emotional self-control.

Re:Computers: They can respond fast -and- slow

[weilawei]

The fact that you would choose to parse it that way shows that you have no idea what you're talking about. The topic at hand is passwords and security. The phrase "offline attack" has a specific meaning within that context. More to the point, only you used the word "offline" all by itself.

You must be trolling. This is an incredible level of stupid or purposeful ignorance. I'm done trying to fix that much stupid.

Re:Computers: They can respond fast -and- slow

[Empiric]

Again, my parsing of the sentence is fine, and was the one pertinent to the suggestion that 10,000,000 online attempts is a reasonable possibility to be addressed.

Which is what I intended to convey.

Re:Computers: They can respond fast -and- slow

[Empiric]

Fine, be done.

Particularly envious of dev salaries today, or what?

Re:Computers: They can respond fast -and- slow

[Anonymous Coward]

And that had exactly what to do with the summary which mentioned, "100,000,000,000,000 to have any hope against an offline one" (where the word "attack" was implied, assuming the reader wasn't a complete moron)?

You didn't even read the AC you replied to either. They also said that your suggestion would do nothing against an offline attack. And yet you persist in trying to parse their statement in the most ridiculous way possible--a way that is absolutely incorrect in this context.

What you intended to convey is your total ignorance of the matter at hand.

Re:Computers: They can respond fast -and- slow

[Empiric]

So, back to my original statement:

Correct, absolutely, as stated, that the ability to inject delays into the supposed 1,000,000 online attempts makes the notion superfluous as a theoretical security concern.

Here, I am using "online" to me specifically the use of "online" clearly called for by the premise of the topic.

Again, no problem. I am using it in the way relevant to the question.

Re:Something is so very wrong with a web site or s

[Anonymous Coward]

Offline attacks don't exist! /sarcasm

At least, according to Empiric up there.

hum

[Anonymous Coward]

What about 2 step security, biometrics or smartcard over the internet(encrypted and tunneled temporarily by VPN) in conjunction with the regular password you setup already with your bank or email provider. Windows 10 will have biometric support so hopefully we will see cheap biometric devices(or built into AIO and tablet computers) coming soon for all consumers.

Nothing to see here move along..

[Anonymous Coward]

At the moment password DB thefts seam to be all the rage. From the pastebin entries I've seen the attacks at the moment appear to be using a dictionary attack, with a dictionary size in the 10s of millions. They are attacking 1000's of password hashes. So the one in a million password is far too week, the one in a 100 trillion password is also pointless, because the bad guys don't want your specific password that much. There are easier passwords to break.

So their lower boundary is too low, and their upper one is too high. So what strength password do we need to be safe from this kind of attack, but not be totally bonkers? Well it turns out you need about 8 characters with suitable entropy to meet this requirement, which is what the security industry has recommended all along...

Re:Computers: They can respond fast -and- slow

[Anonymous Coward]

Here, I am using "online" to me specifically the use of "online" clearly called for by the premise of the topic.

Troll score: 0/10.

This is Slashdot, not Digg.

Re:Computers: They can respond fast -and- slow

[Anonymous Coward]

You make up for your slightly uninformed comment completely, by the way you handle the troll calling you a troll :-)

If I had mod-points you would get some.

No password can survive an offline attack

[Todd Knarr]

Offline, the attacker can if all else fails brute-force the password. No password is complex enough to survive a brute-force attack. With the growth in computing power, including the ability to apply GPUs and specialized hardware to the task, search space size alone isn't enough protection. The only protection, as noted, is detecting the leak of the password database early so users can change passwords before the offline attack has yielded usable results. Alternatively, the authentication system can employ two-factor authentication so that the password alone isn't enough to compromise the account.

For on-line attacks, I'd argue the number given's too large. A properly-designed on-line system should be designed with rate-throttling and account-locking mechanisms, and with those in place a password should only need to survive at most maybe 10 attempts before even the correct password won't access the account. Those mechanisms can be applied to all current systems right now.

The biggest hole isn't the password itself, it's the password-recovery system. Why bother with either an offline or on-line attack on the password when you can initiate password recovery and change the password on the target account to one you know?

Re:No password can survive an offline attack

[weilawei]

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.

Re:No password can survive an offline attack

[Anonymous Coward]

SCRYPT:131072:8:1:PjNHmOoZTexyHHnURQirkvaSOxyxCjMPFP88gqthKbI=:ydSHOaYlO2UngCdHc68Qt2nTD/o9+Fd7d4nPDCo4Gk4=

gg no re

Re:No password can survive an offline attack

[brantondaveperson]

You vastly underestimate the amount of work involved in breaking 512 bits of entropy. You vastly underestimate how big 512 bits of search space actually is. It's got nothing to do with how long it would take, there simply isn't enough energy in the universe to count up to 2^512, let alone do anything with the numbers.

Flipping a bit in a computer takes a teeny tiny amount of power. Multiply the smallest possible amount of power (the plank energy) by 2^512, and boom you're talking about more energy than exists in the universe.

2^512 is *plenty*.

The biggest hole isn't the password itself, it's the password-recovery system.

On the other hand, this is a very intelligent point, and is entirely correct. "Security Questions" my ass.

Re:No password can survive an offline attack

[Todd Knarr]

Except that it's not 512 bits of entropy. Remember that you're searching passwords, not hashes, and you're not running a rainbow-table attack so the size of the hash doesn't matter. For the common case of US-ASCII passwords there's 95 possible characters (excluding control characters and code 127). That's about 6.5 bits, call it 7 for convenience. For a 15-character password that's 105 bits max, and closer to 98 bits in reality. That's assuming that all symbols are allowed. The floor would be an alphanumeric password which nets you 6 bits per character for a total of 90 bits in a 15-character password. That's a lot smaller search space than 512 bits.

Passwords are the worst solution...

[Anonymous Coward]

...except for everything else.

Re:Computers: They can respond fast -and- slow

[Anonymous Coward]

Posting AC to pump up your own ego, Empiric?

That's pretty sad.

Re:Computers: They can respond fast -and- slow

[Empiric]

So now I have trolls accusing me of trolling and ACs deriding me for supposedly posting AC...

But no, wasn't me. My emoticons are dashless. ;)

Re:Computers: They can respond fast -and- slow

[Anonymous Coward]

Most passwords aren't cracked in an online attack, but in an offline attack where the entire password database is stolen. Adding a delay and locking out an account after multiple failures is already standard practice to defend against online attacks.

The article was talking about the need to defend against online attacks and offline attacks. The 100,000,000,000,000 figure given referred to offline attacks. Who in their right mind would try to run an online attack against a service with even a 1-second delay or a service that locked you out after 10 tries? It's far simpler to find an exploit, steal the password database, perform an offline attack, and use the gleaned passwords to attack more lucrative targets (such as bank accounts).

Did you read TFS?

Re:Computers: They can respond fast -and- slow

[Empiric]

Yes, it is. And I've been here a long time.

People getting emotionally irate at reading "offline" as "not online" rather than "offline " is reasonably rare here, fortunately.

Re:Computers: They can respond fast -and- slow

[Empiric]

Speaking of parsing...

Before Slashdot's got ahold of it, that read "offline [subqualifier]". Need to watch my > and < too, apparently...

Re:Computers: They can respond fast -and- slow

[Anonymous Coward]

Because you seem able to handle feedback (as opposed to the people giving it, in this thread), I'll share why I think your idea has little merit.

There are indeed many ways to delay attacks on a service, but it is imho not something that really adds to the security. A determined attacker can likely use a botnet to distribute the attack or even simply buy credits for cloud services. If the delays/blocks are IP based they won't work and if the delays/blocks are based on the login ID, any attack in effect becomes a DDOS.
Besides, your approach also does nothing against off-line attacks, but I think that is discussed already ;-)

Don't manage passwords

[Art3x]

Don't roll your own password system. If you're a public site, use OAuth Connect to let them sign in with their account from Google, Yahoo, or some other company that specializes in this sort of thing. If it's a business-to-business site, use Kerberos or LDAP to let them sign them in with their own company's username and password. This also cuts down on the number of usernames and passwords users must remember.

100,000,000,000,000 less than 2^47

[Anonymous Coward]

Are they kidding? 47 bits of entropy in passwords are strong enough? You can get that with eight characters in base 64.

And here I upgraded to random 14 character passwords a few years ago, because eight seemed too short to be comfortable. Today, I'm using random 22 character passwords, just to be sure.

1,000,000 would be about 20 bits, which would mean four characters of base 64 are good enough against online attacks. Weird.

Re:Computers: They can respond fast -and- slow

[Empiric]

Well, I wouldn't argue that on a theoretical level that a password of any size or complexity can't be compromised by a botnet of arbitrarily large size. The article opens with what is "enough", and with an arbitrary number of IPs over an arbitrarily large amount of time, no password complexity would be "enough".

However, I think simply doing this:

1. Delay 5 seconds after an incorrect login
2. Double the delay after every subsequent login attempt
3. Block the IP after 10 sequential failed logins
4. Lock out the account after 100 sequential failed logins, and require a CAPTCHA or e-mail process to re-enable the account ...would be very difficult to brute-force even given a very large IP pool, and that size is ultimately limited by cost.

As you say, though, it doesn't stop someone from executing a DDOS attack, but the potential exposure and damage there is quite different.

Offline vs online

[gmuslera]

Your online password could turn to be an offline one if the crypted version of it was in a server with a vulnerability/been hacked/given to authorities.

Re:Offline vs online

[Anonymous Coward]

This seems to be lost on many of the self-styled experts proposing homebrewed schemes here, many of which have significant security issues.

Either that or the NSA just really likes trolling articles related to security.

Re:Computers: They can respond fast -and- slow

[Empiric]

Did you read TFS?

Yes.

They say a password must withstand 1,000,000 guesses to survive an online attack...

Feel free to state if you think this phrase, which my post addresses, is or is not present in TFS. If we agree it is, that is what I was responding to, on the basis that one can respond to something in any way they wish, in whole or in part. If you feel I am required to have responded to some other part of the summary, or in some other way per your preferences, feel free to explain why. Otherwise, your own independent post making your own points seems appropriate.

Slashdot is getting really OCD-strange lately...

Too Much and Not Enough

[fustakrakich]

One martini is not enough
Two martinis is too much
Three martinis is not enough

Re:Computers: They can respond fast -and- slow

[Anonymous Coward]

As a user, I would hate such a website (I am passionately opposed to passwords of any kind, more so with "annoying" login prompts). Especially because there are many decent (and even a few good) alternatives.
Things like Facebook Connect, OpenID Connect and Mozilla Persona (BrowserID) are better than passwords (But only Persona is 'good' IMHO).
If a service can't or won't outsource the identity management, there is multi-factor auth or private/public keys.
All of these are easy on the user when implemented right.

You are correct about things being fine when they are "good enough". My personal opinion is that the easiest way to obtain "good enough" is simply to avoid user-typeable authentication stuffs. Lets go outside during all the time saved from implementing and recovering from password security policies/breaches.

Paper statement surcharge

[tepples]

I won't do banking over the internet.

Some banks have started charging a $60 per year fee to send paper statements instead of e-mail. What will you do once all banks with ATMs in your home town do this? Switch to an online bank that can't accept cash deposits?

Re: Paper statement surcharge

[Anonymous Coward]

You don't need to actively use internet banking to receive statements by email.

Re: Paper statement surcharge

[tepples]

Because of the low adoption of S/MIME and OpenPGP, I've seen banks send not a copy of the statement but instead a notice that a new statement can be viewed by logging in to the bank's HTTPS site. Besides, without Internet banking, how do you discover unauthorized withdrawals from your checking account before your statement, and how do you send money to individuals?

Re:Computers: They can respond fast -and- slow

[tepples]

Things like Facebook Connect, OpenID Connect and Mozilla Persona (BrowserID) are better than passwords [and] easy on the user when implemented right

The problem comes when well-known sites don't implement it right, such as by implementing only Facebook Connect and nothing else. The Huffington Post, for example, requires each commenter to have a valid subscription to mobile phone service and give a globally unique number capable of receiving SMS to Facebook.

The cost of great security is severe inconvenience

[tepples]

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

At which point you may be on the wrong side of the tradeoff between security and convenience. If you have 100 subscribers behind a proxy with a single public IPv4 address, and ten of them forget one password, good luck fielding customer support calls for all of them.

Key stretching with PBKDF2

[tepples]

a CPU that can manage a trillion hashes per second (easy)

A trillion (10^12) hashes per second can still check only 100 million (10^8) passwords per second if checking each requires 5000 rounds of PBKDF2. In the common PBKDF2 built on HMAC, each round is two hashes, making a 5000-round PBKDF2 take 10,000 (10^4) hashes.

Re:Key stretching with PBKDF2

[julesh]

a CPU that can manage a trillion hashes per second (easy)

A trillion (10^12) hashes per second can still check only 100 million (10^8) passwords per second if checking each requires 5000 rounds of PBKDF2. In the common PBKDF2 built on HMAC, each round is two hashes, making a 5000-round PBKDF2 take 10,000 (10^4) hashes.

That, and the fact that there's no CPU on earth that can calculate 10^12 cryptographic hashes in a second using any algorithm that's ever been commonly used for password hashing. Even hardware using custom ASICs designed for the purpose struggles to approach this rate; the fastest bitcoin miner money can buy manages 4x10^11 hashes per second in each of its 15 processors. Any single chip solution can't really do much better than that, because cooling.

Re:Computers: They can respond fast -and- slow

[Anonymous Coward]

You did not understand what an offline attack is, he informed you. You got moronically defensive. I'm still not sure you know what an offline attack is.

A web login checks a string, the hashed password. It stands between you and the hashed string, checking it upon your request and only so many times that it determines. If you have JUST that string (from a stolen database) you can bruteforce and your only limit is your compute power available. THIS IS AN OFFLINE ATTACK. It's you and the string, the hashed password nothing in between

Re:The cost of great security is severe inconvenie

[Anonymous Coward]

Please do not feed the troll.

Thank you.

- Management

CAPTCHA: diners

WHY IS THE INTERNET FOCUSED ON THIS SHIT

[AbRASiON]

I'm so sick of these goddamned articles, insisting I need FDGHN$@%YFSDG#$T#62532@..1..sdg..FGT34#$% as a password or horsebatterystaplegoatsehamburgerlolsixtynineomelette?

Tell me internet, tell me, how many compromised accounts over the past decade have been from poor passwords, OR how many have been compromised due to the site / service in question having a security hole / unpatched exploit run on it and tell me even further how many are due to social engineering?

I'm more than willing to bet that over 95% of all compromised accounts on any system(s) in the entire world is due to those 2 things and not the complexity of the password and frankly, I'm sick of having to have monstorously complex or awkward passwords in some environments which are almost deliberately difficulty to remember.

Re:WHY IS THE INTERNET FOCUSED ON THIS SHIT

[TrollstonButterbeans]

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.

Re:WHY IS THE INTERNET FOCUSED ON THIS SHIT

[AbRASiON]

I've personally reverted to pattern based passwords now, they feel quite ingenious to me and simple to type but none the less they are probably not ideally secure. They are a breeze to input and get past idiot systems though
Example

567tyughjbnm%^&TYUGHJBNM

Try typing that, I can do it in about 1 second.
I shouldn't have to do that though and if you asked me to verbally recite my password to you, or type it into an android keypad or something not laid out identically to a standard PC 101? Yeah, I'd have trouble :/

Re:WHY IS THE INTERNET FOCUSED ON THIS SHIT

[MS]

Hah!
I used the same password all over. Fortunately I now know better.

Re:WHY IS THE INTERNET FOCUSED ON THIS SHIT

[WuphonsReach]

Writing down a password is not the big bug-a-boo that you make it out to be.

Writing it down and leaving it stuck to the monitor / keyboard is a problem (a social problem). Writing it down and keeping it in a secure location, not such a big deal (password manager software falls into the second category).

The trap that many system admins fall into is that they think requiring long and complex passphrases meshes well when combined with forced password expiration of less then a few years. When you force password resets on everyone on a week/monthly/quarterly basis, your users will figure out some trivial method that gets past your system or resort to just sticking passwords on notes stuck to monitors.

Far better to let them choose something reasonably complex (which is 14+ characters these days) then monitor for signs of unauthorized activity. And add in two-factor authentication using their corporate assigned phone or smart card or token thingy that kicks in if things look iffy.

Re:Computers: They can respond fast -and- slow

[Anonymous Coward]

You just went full retard.

Re:The cost of great security is severe inconvenie

[Empiric]

I really wish I could convey how much I appreciate the poseur irony of this post, particularly with the "coincidental" CAPTCHA.

Maybe a song will help.

allow all characters, always

[NotQuiteReal]

I understand different places have differing levels of "complexity" requirements for passwords, by why would there ever be a limit on the characters you can use?
One site might want 8 characters, with one number and one uppercase, and one special character, but they only allow "certain" special characters!

Some sites are ok with dashes, others, underscores... WHO CARES!

Oh, and don't get me started on credit card input "please enter just the number, no spaces or dashes" - Well, if you don't want the spaces and dashes in the user input, JUST FUCKING REMOVE them, and say "thank you" to the customer, who used to always be right, but now is apparently just a schmuck.

Was that too harsh?

Re:allow all characters, always

[Anonymous Coward]

No.

Re:allow all characters, always

[Anonymous Coward]

For example, we should allow passwords to contain backspace, delete, tab, and enter characters, thus makng them untypable except in a very special terminal session. And also the null character, so they cannot be stored in a C-style string.

Re:Something is so very wrong with a web site or s

[Anonymous Coward]

No, it is KNOWN and ACCEPTED problem that there will be 0days and new attack vectors that allow the user table to be stolen. that is the whole fucking point here. your user table can be stolen but you have strong passwords for all users, salted, etc... just like you encrypt an archive to send it over the clear, you assume you can't 100% prevent sniffing. SAME CONCEPT

Re:Computers: They can respond fast -and- slow

[skids]

Do you know the difference between STUPID and simply UNINFORMED? Also the difference between bold and SHOUTING?

Nobody does that

[dutchwhizzman]

You must have encountered one of the few systems where people actually pay attention to such "details". There are plenty of locations where you can brute all you want and where the entire DB of passwords or hashes is relatively easy to obtain for a hacker. Since people re-use passwords a lot, that's often enough to get into the few locations where brute-forcing is made more difficult.

Trivial to hack

[dutchwhizzman]

You just created one tiny extra step for people stealing the database. If a system is so flawed that an attacker can get your database, they will most likely only take a few extra minutes to get their paws on your salt.

Granted, they need to write their own module for oclhashcat to get this cracked at a decent speed, but once that's done, your proposal isn't functional.

Re:Trivial to hack

[weilawei]

The salt is a public value. You're not hiding it. It's stored in plaintext with each entry of the password DB. It's unique per-user. Its only purpose is to eliminate the generation of one-size-fits-all rainbow tables.

This is not a "tiny extra step".

Biometrics sucks for authentication

[dutchwhizzman]

Because biometrics can often be cloned, copied or otherwise be "fooled" when used for authentication. Finger print scanners are worthless since so many attacks exist to current finger print readers when someone copies your print. You can't get new finger prints once someone made a copy of yours, so as an authntication method they are worthless.

Some other authentication methods using biometrics exist, but they are generally too expensive to implement in most cases. They may not be "affordably" circumvented yet, but I have no doubt that once it's worth it to put time and effort in it, people will find ways to fool those systems too. I'd hate to have to get new eyeballs because someone copied a scan of mine onto a synthetic ball.....

Apart from this, remote authentication using biometrics replaces the biometrics with some sort of device sending some sort of signal to the remote location with either a signature of the biometric information, or just a version of "I've check this person out and they're okay". You once again transfer the problem from biometrics to some form of digital communication which obviously is just as weak to hack as the technology you are trying to augment for being weak.

NTLM and LANMAN

[dutchwhizzman]

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.

Re:NTLM and LANMAN

[weilawei]

So, you're saying that a totally broken scheme which doesn't rely on the password at all is totally broken? Color me surprised! The solution is to throw out the broken scheme, not to make vague gestures about "doom for anything password protected".

Sysadmin here.

[Anonymous Coward]

System administrators should stop...

Protip: We don't give a fuck.

We're just saddled with corporate bullshit from above.

Re:Computers: They can respond fast -and- slow

[nine-times]

They're talking about a different problem. If hackers get ahold of the password hashes, then restricting the rate of login attempts on the server itself won't help. That's where that "100,000,000,000,000" number comes from. I believe it's saying that's how strong the password needs to be to withstand a brute force attack when an attacker has gotten ahold of the table containing encrypted passwords. That's why it says:

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

However, that seems like a short-term solution when there's a better long-term solution that's pretty obvious, which doesn't require relying on system administrators to secure password databases. If we stopped using passwords and used public key encryption instead, then websites wouldn't have your password, so they wouldn't be able to leak it.

It's an obvious solution. We know how to do it; the technology isn't new. We won't do it, though, because we don't care about security and we're unwilling to develop new standards. The companies who could push new standards forward are more interested in maintaining walled gardens.

not news

[Tom]

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.

Re:not news

[weilawei]

Because everyone writes absolutely perfect code, no one ever loses anything, and there are no exploits out there.

When your server gets hacked or sysadmin/DBA gets disgruntled and steals your password database, you'd better hope they're salted with a strong salt, per-user, and hashed with a function like bcrypt or PBKDF2. Your online attack which didn't allow for a brute force attack suddenly turned into an offline attack which does.

You can keep pushing the problem off to other places, but at some point, somewhere down the line, you're going to need a password, even if only to secure your private key for your SSH session for when you lose the token it's stored on. There aren't any magical solutions.

Re:not news

[Tom]

Because everyone writes absolutely perfect code, no one ever loses anything, and there are no exploits out there.

No, because there is a difference between looking for the perfect castle and realizing that maybe having a wall isn't so stupid and closing the door and night isn't a bad idea, either.

Making brute force attacks difficult is not a question of perfect code. It's a question of not allowing unlimited tries at unlimited speed (online) or not storing unsalted password hashes (offline). It's not a matter of protecting your server from compromise. A serious defense strategy always includes the assumption that several layers of your protection fail and you should still not suffer a total defeat.

you'd better hope they're salted with a strong salt, per-user, and hashed with a function like bcrypt or PBKDF2.

You see, this is the point. Whether or not they are is not a matter of hope like rain and sunshine. It's something you actively control.

There aren't any magical solutions.

No, but there are good and stupid solutions, and it's time we stop using the stupid ones. It's a feature of this anarchy we love so much, because if software was a car... well, at least in the western world you can't legally sell a car without brakes anymore.

Re:Computers: They can respond fast -and- slow

[Tom]

or lock out the console/IP entirely, after N failed attempts.

Which opens the door to DOS attacks on target accounts, but there are several smart ways to work around that (send an unlock link to the e-mail address for that user, for example).

I hope security "analysts" catch on to reality soon.

There are two kinds of security people in the business world. Those with a real interest in advancing the field and making computing more secure, and those working for large consulting and IT "Security" companies. I am exaggerating some, of course, and there are great people in those companies as well, but unfortunately the business concept of too many of them is based on solving problems in such ways that you can sell the solution to many other customers, not on finding a solution that takes care of the actual problem.

It's the same with consulting companies and the insource/outsourcing cycles. There are good arguments for both of them, but if you've watched the business world for a decade or two you understand that they are hyped in cycles so the same consultants who sold outsourcing to a company last period can sell insourcing to the same company next period or after the next CTO change.

Re:The cost of great security is severe inconvenie

[Anonymous Coward]

Forget subscribers. Anyone can DoS your administrative accounts.

Random 16-character password strength

[Alan Kennington]

Just for the record, the strength of a random 16-character password with random combinations of upper and lower case letters and decimal digits is:

62^16 = 47,672,401,706,823,533,450,263,330,816

Well, that's the number of combinations, and one would need to check half of them to have a 50% chance of cracking such a password. (Well, that's not precisely the strict probability theory language for it, but it's something like that.) In other words, anyone who uses a simple password manager should be fine.

A 1 in a quadrillion password

[Anonymous Coward]

So just using the 36 characters of the alphabet and the 10 numerical characters a password need only be
10 characters long to pass the upper threshold. Is that right?

passwords != strings

[Anonymous Coward]

It should be treated as a binary authentication token. I don't care how the user enters it - hell if they can get "untypable" characters in there, more power to them, and all the harder for someone to guess.

2FA

[lonecrow]

2FA

Don't allow user-generated passwords.

[Anonymous Coward]

Instead of allowing users to pick passwords, if password authentication is still necessary, simply impose a password. Allow them to generate a new one whenever necessary, but do not allow them to choose what the password will be, therefore, the password will be random, and the password is unlikely to be shared with any other site.

Stuipd

[Anonymous Coward]

Why bother securing password databases and fixing leaks at all? If a user's password is compromised, then most of the data is stolen(depending on access permissions).

hash a simple pre-password for a strong password

[KWTm]

This is a reply not just to the comment from amxcode but the GPpost from ColdWetDog.

A random-seeming password doesn't really have to be random, and thus you don't have to rely on someone else's software to keep track. You can generate a long password by hashing a short, easy-to-remember "pre-password" that only you could guess.

For example, you can decide that your personal password-salt is "ColdWetDog", and the pre-password for your Amazon login is simply "amazonColdWetDog". (And the pre-password for your bank would be "bankColdWetDog".) Then you hash it with MD5 (or SHA-1 or RIPEMD-160 if you don't like the collision vulnerability of MD5, though in tis case it doesn't make a difference). The result is a long string, and you can take the first n bits and use that as your password. (Yes, MD5 only generates hex digits, so accumulate it into base64 to make them ASCII characters.)

And, boom!, there's your big long pseudorandom password that you can use no matter which operating system you switch to, without having to worry about any password app from some app store.

My own password manager is a text file encrypted with open-ssl. It's not just that I am paranoid about password apps someone else wrote; I also need it to work on multiple platforms. Write your own; it's not that hard.

Re:hash a simple pre-password for a strong passwor

[Anonymous Coward]

What ultimately matters is the entropy. I feel prefixing something with "amazon" when to be used on Amazon.com is just going to add 2 bits of entropy for that position. For the cracker to try it with and without amazon. Even combined with MD5 and the like, those are also bits of entropy.

I don't believe Windows has MD5 built into it. So, in order to get that what you want, something would have to be downloaded first, if on someone else's computer. Or am I missing something here?

I really question whether your suggestion is a good idea. Maybe you used the username as an example, and meant just any other favorite string. Still, entropy is what matters.

I haven't tried this, but there's always: http://www.passwordcard.org/en
But if I were to do that, I'd want to do it offline with my own printer.

IDs might be a good idea

[Anonymous Coward]

The weakest thing may not be the password... it may be the password recovery system. So, enough with all these secret questions and whatnot. One idea might be a combination of things (which may include secret questions). Allow an OPTION to scan your ID into the system. For password recovery when this option is chosen, a live video chat (maybe for a nominal fee of $1.99) would be required in which a live person verifies whether you are who you claim to be... based on on the ID uploaded to the system. Maybe it's not full proof, but it's an idea.

Passwords should not be handled by people.

[lhunath]

We have hundreds of accounts scattered across the net, and each's security relies on a secret that is supposed to be unguessable and shared only between you and that site. Such is the primary assumption of passwords, and yet such a system can never work for people.

The only solution is to stop using passwords as passwords and instead consider them as "symmetric keys". Master Password is a password generator that takes the name of your site and generates a unique key for you and it which you use as the password for the site. The awesome thing is that it's a generated key and thus doesn't rely on any form of storage, be it cloud or require backups and sync, nor can it ever be lost. It uses the scrypt KDF to protect itself against off-line reversal attacks.