[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <74AC0E9E-F560-483E-A054-0FD4230ED95A@me.com>
Date: Sun, 29 Oct 2017 15:39:07 -0400
From: Arnold Reinhold <agr@...com>
To: passwords@...ts.openwall.com
Subject: Re: Real world password policies
> On Oct 27, 2017, at 10:56 AM, e@...tmx.net wrote:
>
> On 10/27/17 16:02, Arnold Reinhold wrote:
>
...
>
>> Perhaps we need a website of silly password requirements.
>
> there are no good policies (see the MS vs Google example)
> they are not possible at all.
> well, except one: make your password longer
> so that all policies will end up on your website, and it will get flooded :)
Well, some are sillier than others. Apple, for example asks for "8 or more characters,upper and lower case, at least one number”—that may not be effective but it isn’t obnoxious. The web site could catalog the worst offenders.
As for the possibility of having good password policies (besides bare minimum length) here are two possibilities.
1. As suggested earlier in this thread, exclude the user’s login name, email address, and other personal info that can be easily scraped from public social media and the like from the length calculation. (I would credit each as one letter)
2. Require a password that doesn’t crack easily. Sophus.com <http://sophus.com/> says in "Why you can’t trust password strength meters:"
https://nakedsecurity.sophos.com/2015/03/02/why-you-cant-trust-password-strength-meters/ <https://nakedsecurity.sophos.com/2015/03/02/why-you-cant-trust-password-strength-meters/>
"The best way to determine how difficult it is to crack a password is to try doing just that. But attempting to crack passwords requires lots of time and lots and lots of processing power, and it isn’t a practical solution for websites.”
Sophus is right about the first part, but completely wrong about the second: such testing can be done quite efficiently using a Bloom filter.
Creating a password cracking Bloom filter would indeed take lots of processing power, comparable to a complete cracking attack, but you only have to do this once. You’d just run one or more best-of-breed cracking programs, but instead of testing a hash for each guess, you'd add the guessed password to the Bloom filter. The Bloom filter might end up hundreds of gigabytes in size, depending on how deep you choose to search and what is an acceptable false positive rate for the Bloom filter, but checking a password against the filter would be extremely fast, especially if it is stored in a SSD. The resulting filter could be copied and shared among multiple enterprises.
How many passwords to load into the filter would depend on the desired level of security, the target cracking machine (say 10 high end GPGPUs) and whether, and with what parameters a resource intensive hash (such as PBKDF2, scrypt or argon2) is being employed to store the validation data. One could even build several filters, terminating each at a different search level, to create a meaningful password strength meter.
One could generate new filters periodically as new password corpuses become available and processing power improves. Avoiding the need for a high depth password cracking Bloom filter that disallows a large fraction of passwords users submit might be an incentive for organizations to employ more resource intensive hashes, and to up their strength periodically. One might combine methods 1. and 2., excluding the user’s login name, etc. if present, before testing on the Bloom filter.
Arnold Reinhold
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
