I'm starting to have trouble figuring out who said what in this thread, but here are some thoughts.
- I don't think we can mitigate weak encryption with greater password entropy. Password entropy is a mitigation for brute force (or intelligent) guessing attacks. A successful attack on the encryption itself, on the other hand, will allow the attacker to read a passwords, independent of how long or complex it is. I think the confusion comes from the fact that (according to one of the articles I sent yesterday) many (most?) attacks on encrypted passwords are not actually attempts to decrypt the passwords; they're guessing attacks that leverage very fast hardware and software for encrypting the guesses.
- Then language about Kerberos that was quoted is from the section about the assertions sent to a relying party (section 9.3.2.2). In our case, that's SAML, so that language doesn't apply to us.
David
On Tue, 2013-06-18 at 23:10 +0000, Eric Goodman wrote:
OK, what would help is to determine if “entropy” (as used in the password guessing table A.1) is equivalent to “cryptographic operations” (as used with impractical, on the order of 280 operations, for off-line cracking resistance as the result of eavesdropping.)
Both of these definitions come out of SP 800-63-1, so they are not in the Silver spec, but table A is included by reference. The Silver spec mentions entropy, eavesdropping resistance, and impractical. Perhaps those are terms and assumptions that could be “defined” as part of the AD Alternative Means purposes.
My assumption is that a cryptographic operation is a single hashing or encrypting process. Hence my reference to rounds/passes of encryption in the original comment. AES applies its encryption between 10 and 14 times, depending on the actual algorithm. So my assumption is that a password with 2^30 entropy would take ~2^34 cryptographic operations to brute force (2^30 * 14 rounds/password).
This may have been a short-cut, but the complete space for 95 characters with 12 length would be 9512 which works out to roughly 279 which is reasonably on the order of 280 combinations. I don’t think the full entropy calculation was factored in for the “impractical” calculation.
Not really following. I understand the character space is 2^79. That assumes random password creation. In reality, humans use many fewer letters. That’s what table A.1 is estimating: the loss in possible entropy based on their presumptions about the actual “randomness” inherent in user chosen passwords.
Going back to Kerberos, SP 800-63-1 is even more unforgiving in that it says “All assertion protocols used at Level 2 and above require the use of Approved cryptographic techniques. As such, the use of Kerberos keys derived from user generated passwords is not permitted at Level 2 or above.” How does sentence 2 relate to sentence 1? Kerberos can certainly be set to use only approved algorithms. Is this exclusion related just to the assertion? If that is the case, then for Shibboleth, the assertion is sent via SAML and not Kerberos.
I don’t know where that assertion came from (other than our NASA people saying FICAM doesn’t like Kerberos) and wasn’t trying to imply an answer on the Kerberos side. I was strictly focused on the entropy lookup, and the “entropy vs. cryptographic operations” language.
My thinking here is that if Kerberos could be interpreted/configured to be OK for Level 2 (Silver), with keys derived from user generated passwords, then Kerberos-only could be a method for configuring Active Directory to meet Silver. Microsoft even says that Kerberos is their strategy and that NTLM is not going to be “fixed”.
Well, I agree with your hypothetical, but my agreement is not worth much since I’m not helping prove the antecedent.J
--- Eric
|
