[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Cryptography] Possible reason why password usage rules are such a mess
> On Nov 20, 2020, at 5:53 PM, Sid Spry <sid AT aeam.us> wrote:
> On Fri, Nov 20, 2020, at 1:57 PM, Arnold Reinhold wrote:
>> and Sid Spry wrote:
>>> reversing a properly salted
>>> password database is only feasible with such a dictionary.
>>> Brute force in the strictest sense isn't usually tractable.
>> These two comments do not reflect the current state of the art. For
>> example by 2012 it was possible to try all Windows NTLM eight-character
>> password containing upper- and lower-case letters, digits, and symbols
>> in 5.5 hours using 25 AMD Radeon graphics cards of that era (GPUs have
>> gotten a lot faster since).
>> Modern cracking software, such as John the Ripper use a variety of
>> modes, including dictionaries, straight brute force and pattern-based
>> searches using word mangling rules. Almost all the passwords in
>> recovered corpuses were from stolen file of hashedd passwords. It’s
>> rare to hear of a hacked firm storing plaintext passwords. Recovery
>> rates from stolen hash files are typically 70 to 80%.
> Point: NTLM is particularly weak compared to modern constructions and
> as you are aware JtR is using dictionaries and pattern based searches gleaned
> from analyzing plaintext and reversed user databases.
> That's not really brute force, you're guiding the search. But thankfully(?)
> most people choose bad password.
The password cracking community has had lots of experience and their tools are quite refined. They sensibly try the easy stuff first, common passwords, dictionary words, mangled words in various patterns. They save brute force for the passwords that still don’t yield. But brute force is quite feasible for password sizes people commonly use if hashed by a fast hash.
Microsoft still stores passwords using NTLM, I believe. NTLM hash is based on MD4, which is throughly broken for collision attacks, but last I heard is still reasonably resistant to preimage attacks. And the attack described above didn’t exploit any weakness except fast speed of execution, which allows many guesses to be tried per second. SHA-256 takes about the same time to evaluate as MD4, so it is no stronger against brute force attacks. Worse, there is a lot of hardware designed to evaluate SHA-256 for Bitcoin mining on the used market, so SHA-256 might even be more vulnerable than MD4.
On Nov 20, 2020, at 4:36 PM, Kent Borg <kentborg AT borg.org> wrote:
> Though self-certification of what? Sounds like ISO standards or something. (I hope there isn't a "best practices" requirement of changing passwords every 30-days in there.)
> Things are a mess, even some bad standards might be useful. Maybe for things such as just prompting people to survey to know what their systems consist of.
We do have NIST SP-800-63B, especially section 22.214.171.124, By my count, this one paragraph has about 28 separate provisions which addresses many of these issues, including a negative opinion on requiring frequent password changes, absent a breach: "Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.”
I have some ideas for a set of certification levels, which I will try to write up.
The cryptography mailing list
cryptography AT metzdowd.com