{"action":"created","issue":{"url":"https://api.github.com/repos/usnistgov/800-63-3/issues/585","repository_url":"https://api.github.com/repos/usnistgov/800-63-3","labels_url":"https://api.github.com/repos/usnistgov/800-63-3/issues/585/labels{/name}","comments_url":"https://api.github.com/repos/usnistgov/800-63-3/issues/585/comments","events_url":"https://api.github.com/repos/usnistgov/800-63-3/issues/585/events","html_url":"https://github.com/usnistgov/800-63-3/issues/585","id":213380950,"number":585,"title":"Password length","user":{"login":"bluefoxicy","id":3127473,"avatar_url":"https://avatars3.githubusercontent.com/u/3127473?v=3","gravatar_id":"","url":"https://api.github.com/users/bluefoxicy","html_url":"https://github.com/bluefoxicy","followers_url":"https://api.github.com/users/bluefoxicy/followers","following_url":"https://api.github.com/users/bluefoxicy/following{/other_user}","gists_url":"https://api.github.com/users/bluefoxicy/gists{/gist_id}","starred_url":"https://api.github.com/users/bluefoxicy/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bluefoxicy/subscriptions","organizations_url":"https://api.github.com/users/bluefoxicy/orgs","repos_url":"https://api.github.com/users/bluefoxicy/repos","events_url":"https://api.github.com/users/bluefoxicy/events{/privacy}","received_events_url":"https://api.github.com/users/bluefoxicy/received_events","type":"User","site_admin":false},"labels":[{"id":369794812,"url":"https://api.github.com/repos/usnistgov/800-63-3/labels/63B","name":"63B","color":"c5def5","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2017-03-10T16:05:25Z","updated_at":"2017-03-24T21:38:15Z","closed_at":null,"body":"I have serious issues with the password length requirement of 8 characters.  It's far too short.  This is the discussion on that.\r\n\r\n> 5.1.1.2. Memorized Secret Verifiers\r\n>\r\n> Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length.\r\n\r\nOkay, some history.  Put this in the appendix for this document, because I want it forever stamped on someone's _face_.\r\n\r\nProbably everyone has heard that a good password should be eight characters long; use a mixture of upper- and lower-case letters, numbers, and symbols (“four-class”); and not include a dictionary word.  Even Microsoft’s password complexity rules enforce the four-class recommendation, and most password policies require a minimum of eight characters.\r\n\r\nWhy eight characters?\r\n\r\nSecurity experts have recommended twelve-character passwords [as far back as 2010](http://www.infosecurity-magazine.com/news/12-character-passwords-essential-say-experts/), and [length is mathematically more-important than complexity](http://crambler.com/password-security-why-secure-passwords-need-length-over-complexity/).  Eight characters has been a mainstay for years, even though a twelve-character password is obviously much stronger—just like counting to a hundred is like counting to ten ten times, breaking a twelve-character password is like counting all possible four-character passwords and breaking that many eight-character passwords.  Instead of adding length, we’ve tried to create more possible eight-character passwords.\r\n\r\nThat still doesn’t explain why we chose eight characters.\r\n\r\nIn older versions of Windows released before 2002, Windows stored passwords as two passwords of seven characters each.  Because a seven-character password always had the same encrypted value for the latter half, it was easy to identify and quickly break weak passwords.  Eight-character passwords created some variation—a maximum of 68 possible values, in fact, meaning an attacker could immediately know the eighth character and attack the password as if it were only seven characters long.  The entire approach was ineffective; yet the eight-character recommendation stuck.\r\n\r\nTo summarize:  **the advice to use an eight-character password was originally given as an ineffective work-around for weaknesses in the NT LAN Manager hash in 1995.**  It was never secure.\r\n\r\n# Pasword Variations\r\n\r\nLet's assume absolutely-random passwords for a moment.  People can't memorize these, and they're not really put into use; but we still use them as a basis, so let's try the low-hanging fruit first.\r\n\r\nAn all-lower-case, 8-character password has 200 billion variations, whereas a four-class password has 6,000,000 billion variations.  That seems fine, yet an all-lower-case 12-character password has 95,428,957 billion variations—because it’s 1.5 times as long, instead of using 3.6 times as many possible characters.\r\n\r\n[Illustration A](http://imgur.com/lAGGrsd):  Second place is the first loser.\r\n\r\nSome experts suggest [selection of words](https://xkcd.com/936/), by [Diceware](http://world.std.com/~reinhold/diceware.html) or other means.  Generally, words average four characters plus a space, thus a password length of five per word would make some sense:  a minimum password length of 16-20 is appropriate for passphrases.\r\n\r\nAbove, we assumed a truly-random, 4-class, 8-character password would have 6,000,000 billion variations.  If we instead assume the password is based on a dictionary word with complexity variations, the number of variations falls to a theoretical strength of just 13 million.\r\n\r\nCompare that 13-million-variation real-world memorable password strength to passphrase generated from three and four words.  Diceware supplies a 7,700-word vocabulary.  Assuming a 5,000 word vocabulary, a 3-word passphrase presents 125 billion variations; a four-word passphrase gives 625,000 billion variations.\r\n\r\n[Illustration B](http://imgur.com/ZlhmkFt):  First, second, third, fifth, and twelfth loser; why did you even finish?\r\n\r\nIn this context, a \"word\" is equivalent to a \"character\", and we've simply constructed a scenario where your keyboard has 5,000 keys to chose from.  Four words out of a vocabulary of 5,000 gives a number of variations equal to 5,000 raised to the power of 4.\r\n\r\n# Summary\r\n\r\nEight characters is too short.  While the passphrase argument makes good sense, password length is the only readily-enforceable characteristic.\r\n\r\nWhile a password length of fifteen to twenty would be appropriate for a hard-line passphrase approach, compliance would likely suffer.  To maximize standards compliance, NIST should indicate a minimum password length of twelve; regardless of password complexity, this raises the number of password variations to a power of 1.5.\r\n\r\nEven given the low complexity in modern passwords, a raise to a power of 1.5 adds a _tremendous_ amount of entropy.  Our pessimistic 13-million-variant password space above becomes a 46,872-million-variant password space when raised to 12 characters.  That's over 3,600 times as many variations, meaning a password which is broken in one day now averages nearly ten years of resistance at current computational speeds.\r\n\r\nEight-character passwords are built on a flawed work-around for an even-more-flawed password storage system.  The advice to use eight characters as a minimum length is not based in any form of science or mathematics, and has never been adequate.  Eight-character passwords represent what may be the largest failure in information security theory history:  flawed advice with no theoretical backing taken as gospel and perpetuated well beyond its age.  Any discussion of password length must establish that the eight-character password was _never_ a well-developed concept, and that the advice was _always_ wrong.\r\n\r\nYour thoughts on the matter are appreciated."},"comment":{"url":"https://api.github.com/repos/usnistgov/800-63-3/issues/comments/289149294","html_url":"https://github.com/usnistgov/800-63-3/issues/585#issuecomment-289149294","issue_url":"https://api.github.com/repos/usnistgov/800-63-3/issues/585","id":289149294,"user":{"login":"jimfenton","id":1020212,"avatar_url":"https://avatars2.githubusercontent.com/u/1020212?v=3","gravatar_id":"","url":"https://api.github.com/users/jimfenton","html_url":"https://github.com/jimfenton","followers_url":"https://api.github.com/users/jimfenton/followers","following_url":"https://api.github.com/users/jimfenton/following{/other_user}","gists_url":"https://api.github.com/users/jimfenton/gists{/gist_id}","starred_url":"https://api.github.com/users/jimfenton/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jimfenton/subscriptions","organizations_url":"https://api.github.com/users/jimfenton/orgs","repos_url":"https://api.github.com/users/jimfenton/repos","events_url":"https://api.github.com/users/jimfenton/events{/privacy}","received_events_url":"https://api.github.com/users/jimfenton/received_events","type":"User","site_admin":false},"created_at":"2017-03-24T21:38:15Z","updated_at":"2017-03-24T21:38:15Z","body":"We expect only modest security from passwords alone; that is one of the reasons that Executive Order 13681 mandates the use of multi-factor authentication for any application that makes personal data accessible to citizens. However, there are still many applications that require only this modest level of security.\r\n\r\nIt is useful to consider online and offline attacks separately. A relevant paper in this area is Florencio, Herley, and Van Oorschot, \"[Pushing on string: the 'don't care' region of password strength](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/09/pushingOnString.pdf)\" published in November 2016 _Communications of the ACM_. \r\n\r\nThe primary defense against online attacks is authentication attempt throttling. We believe that the rate limit guidelines in Section 5.2.2 are appropriate for the complexity of 8 character passwords used in conjunction with a blacklist or for 6-digit randomly-generated PINs.\r\n\r\nFor offline attacks, we instead focus on storage of memorized secrets by the verifier. They must be salted and processed using a one-way stretching function to drive up the work factor for the attacker. We also highly recommend the use of an additional one-way stretching operation using a secret value as the salt. With this secret value (which is to be stored separately from the stored hashes, perhaps in an HSM), it is not practical for an attacker to mount an offline attack unless they can also obtain the secret value.\r\n\r\nAs the paper points out, there is little point in choosing a password requirement that is longer than that required to protect online attacks and shorter than that required to protect against offline attacks."}}
{"actor":{"display_login":"jimfenton"}}