SoylentNews is people
SoylentNews
The latest NIST (United States National Institute for Standards and Technology) guidelines on password policies recommend a minimum of 8 characters. Perhaps more interesting is what they recommend against. They recommend against allowing password hints, requiring the password to contain certain characters (like numeric digits or upper-case characters), using knowledge-based authentication (e.g., what is your mother's maiden name?), using SMS (Short Message Service) for two-factor authentication, or expiring passwords after some amount of time. They also provide recommendations on how password data should be stored.
[Ed. Note: Contrary to common practice, I would advocate reading the entire linked article so we can have an informed discussion on the many recommendations in the proposal. What has been your experience with password policies? Do the recommendations rectify problems you have seen? Is it reasonable to expect average users to follow the recommendations? What have they left out?]
(Score: 2) by theluggage on Saturday August 20 2016, @12:16PM
The latter is 9 characters expressed across a possible minimum of 72 characters, perhaps even up to 94. Yours is 38 characters expressed across 52 possible characters.
Trouble is, even if your math is correct (and a couple of people above have challenged it) you're basing it on false assumptions about the world - in particular that the password is randomly chosen and that the cracker will resort to a dumb "infinite monkey" technique to guess it. The "keyspace" of words that users are likely to pick is far, far smaller than the number of possible permutations.
"Sw0rdF!s#" isn't "9 characters expressed across a possible minimum of 72 characters" - its a commonly used password [wikipedia.org] that will be on many lists of "bad passwords" with a couple of predictable "readable" letter-symbol substitutions thrown in (CamelCase, O=0, i=! etc) - which is precisely what you are going to get if you simply force people to use "At least 1 upper case character, 1 symbol and 1 number".
Any self respecting "rainbow table" or other cracking tool will surely include some of these common permutations. Also, you somewhat assume that the cracker is trying to crack one specific password: more likely, they've got 100,000 password hashes from somewhere and they'll be happy if 10 of them turn out to be "$3cr3t" or "Pa55w0rd". Or that they know your Facegoog password is "Sw0rdF1sh" and are trying to guess which minor variation is your Twitbook password. Any system that lets hackers brute-force passwords by making repeated login attempts has more urgent problems than its password policy.
You hit a secure website and *your* system pops up the request for the passphrase, decrypts your key, and then securely presents it to the remote site. That's a lot of work that I doubt will ever happen though.
Yet every half-decent terminal emulator or file-transfer utility supports it for SSH.... and HTTPS effectively does the reverse to authenticate the site. All the crypto code needed is out there, it just needs the protocol and UI.