Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Compare cell phone plans using Wirefly's innovative plan comparison tool ×
Security IT

Passwords: Too Much and Not Enough 223

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."
This discussion has been archived. No new comments can be posted.

Passwords: Too Much and Not Enough

Comments Filter:
  • Why so high? (Score:5, Insightful)

    by wisnoskij ( 1206448 ) on Friday October 24, 2014 @06:15PM (#48225733) Homepage
    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? (Score:5, Insightful)

      by gbjbaanb ( 229885 ) on Friday October 24, 2014 @06:37PM (#48225899)

      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.

      • ... 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 mul

        • 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

      • Re:Why so high? (Score:5, Insightful)

        by Altrag ( 195300 ) on Friday October 24, 2014 @07:26PM (#48226209)

        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.

      • by vux984 ( 928602 )

        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

        • by rthille ( 8526 )

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

      • 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

    • Re: (Score:3, Interesting)

      by tqk ( 413719 )

      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? (Score:4, Insightful)

        by rtb61 ( 674572 ) on Friday October 24, 2014 @07:13PM (#48226143) Homepage

        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? (Score:4, Informative)

        by Altrag ( 195300 ) on Friday October 24, 2014 @07:47PM (#48226385)

        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.

        • by HiThere ( 15173 )

          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

      • by s.petry ( 762400 )

        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

    • 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 Di

    • by MpVpRb ( 1423381 )

      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

      • by HiThere ( 15173 )

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

        • 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?

      • 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 [dailydot.com], 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.”

    • 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.
  • Le'ts just get to Two Factor Authentication everywhere and be done with this conversation!

    • by Altrag ( 195300 )

      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

    • by HiThere ( 15173 )

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

  • 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)

    • by tqk ( 413719 )

      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.

  • Per-user salting (Score:4, Informative)

    by lgw ( 121541 ) on Friday October 24, 2014 @06:19PM (#48225765) Journal

    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.

    • by Fweeky ( 41046 )

      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 [wikipedia.org]. Use PBKDF2 or bcrypt and tune them to take at least 10

    • 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?

  • by Empiric ( 675968 ) on Friday October 24, 2014 @06:24PM (#48225803)

    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.

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

  • by craighansen ( 744648 ) on Friday October 24, 2014 @06:35PM (#48225885)

    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.

    • 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

    • by chgros ( 690878 )

      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 y

      • 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 additio

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

  • Quick someone mention the horse password thingy

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

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

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

  • 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

    • 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 p

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

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

    • 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.
      • 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 :/

        • by MS ( 18681 )

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

  • 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 sp
  • by dutchwhizzman ( 817898 ) on Saturday October 25, 2014 @03:11AM (#48227887)

    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.

  • by Tom ( 822 ) on Saturday October 25, 2014 @07:14AM (#48228297) Homepage Journal

    Me and other security experts have been saying such things for years [dfn-cert.de].

    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.

"If it ain't broke, don't fix it." - Bert Lantz

Working...