Assurance

[Brian Arkills <>]

No, there's a combination of RC4 + DES encryption on the hashes, where the 
PEK is used in the RC4 encryption (to get the PEK you need RC4 + 1000 rounds 
of MD5) and the user's RID is used as a salt on the DES encryption. See 
http://www.ntdsxtract.com/downloads/ActiveDirectoryOfflineHashDumpAndForensics.pdf
 for a thorough and detailed 3rd party analysis. But to be fair, to my 
knowledge, Microsoft has never given the detail noted in this analysis and 
the most explicit details given (by Jesper Johannson) have some minor 
contradictions with this analysis.

> -----Original Message-----
> From: 
> 
>  [
> ]
>  On Behalf Of Tom Golson
> Sent: Tuesday, February 26, 2013 8:43 AM
> To: 
> 
> Subject: Re: [Assurance] Question on Protected Channel - SSL/TLS
> 
> Isn't the AD stored secret issue, unsalted, MD4 hashes, not RC4 encryption?
> 
> --Tom
> 
> On 2/26/13 10:28 AM, Brian Arkills wrote:
> > Accepting RC4 would resolve the Active Directory stored secrets issue too.
> >
> >> -----Original Message-----
> >> From: 
> >> 
> >>  [
> >> ]
> >>  On Behalf Of Capehart,Jeffrey D
> >> Sent: Tuesday, February 26, 2013 8:21 AM
> >> To: 
> >> 
> >> Subject: RE: [Assurance] Question on Protected Channel - SSL/TLS
> >>
> >> Joe,
> >>
> >> Thank you for the excellent reference and tool.  The SSL Labs website
> does a
> >> fantastic job of documenting server encryption!
> >>
> >> Unfortunately, my tests gave a "C" grade to our servers, so it looks like
> there
> >> is room for improvement.
> >>
> >> For anyone testing the Silver "Protected Channel" requirements, this is a
> >> great way to document the encryption supported.
> >> https://www.ssllabs.com/ssldb/index.html
> >>
> >> For Higher Ed, would it be reasonable to use exception (footnote) #22 and
> >> allow RC4 Encryption in SSL/TLS and still claim NIST compliance?
> >>
> >> NIST TLS-SSL SP800-52:
> >>
> >> TLS_RSA_WITH_RC4_128_SHA   (#22)
> >>
> >> (#22) RC4 is not a FIPS-approved cryptographic algorithm. For this 
> >> reason,
> >> cipher suites with RC4 should be offered only when communicating with
> >> non-government entities in limited, low risk situations for the transfer 
> >> of
> >> non-Federal data when a FIPS-approved encryption algorithm is not
> >> supported. Normally this cipher suite should not be offered.
> >>
> >> Jeff
> >>
> >> Jeff Capehart, CISA
> >> IT Audit Manager
> >> University of Florida - Office of Internal Audit
> >> (352) 273-1882
> >> 
> >> http://oia.ufl.edu
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: 
> >> 
> >>  [
> >> ]
> >>  On Behalf Of Joe St Sauver
> >> Sent: Monday, February 25, 2013 4:02 PM
> >> To: 
> >> 
> >> Subject: Re: [Assurance] Question on Protected Channel - SSL/TLS
> >>
> >> "Capehart,Jeffrey D" 
> >> <>
> >>  asked:
> >>
> >> #So, what level of testing do you think is necessary to validate that a
> >> #Protected Channel is used?
> >> #
> >> #Per the v1.2 IAAF, typical SSL/TLS should provide the protections.
> >>
> >> Let me preface my comments by noting that I'm *not* an IT auditor, and
> this
> >> is not audit advice, just some points for your consideration...
> >>
> >> A year or two ago I did a talk, "SSL/TLS Certificates: Giving Your Use of
> Server
> >> Certificates a Hard Look," see
> http://pages.uoregon.edu/joe/hardlook/hard-
> >> look.pdf
> >>
> >> As part of putting that talk together, I looked at a set of higher ed
> institutions
> >> uisng the tool that's available at:
> >> https://www.ssllabs.com/ssldb/index.html
> >>
> >> The results weren't particularly pretty :-(
> >>
> >> Lots of sites have issues with things like:
> >>
> >> -- permitting SSL 2.0 (they shouldn't -- SSL2.0 is insecure)
> >> -- doing renegotiation insecurely
> >> -- accepting too-short ciphers
> >> -- using too-short cert signatures
> >> -- running out-of-date versions of Apache (or whatever server software
> >>    they're using)
> >> -- not using a web application firewall
> >> -- and the list goes on...
> >>
> >> And of course, lots of users are using browsers with their own set of SSL
> >> issues, including things like failing to handle OCSP/CRL checking 
> >> sanely, or
> >> failing to support secure versions of the TLS protocol.
> >>
> >> So, if it were me, I'd start by hitting the SSL Labs page mentioned 
> >> above,
> just
> >> to see what it can detect that's worth digging into more deeply. A lot of
> sites
> >> appear to be doing SSL/TLS, but when you give them a hard look, their
> >> installations aren't very secure "under the hood."
> >>
> >> Beyond that, as discussed in "Leveraging Certificates for Improved
> Security,"
> >> http://pages.uoregon.edu/joe/leveraging-certificates/leveraging-
> certs.pdf
> >> I'd *like* to see an EV cert used, and I'd also like to see HTTP Strict
> Transport
> >> Security (HSTS) enabled, and I'd like to see users running Certificate
> Patrol...
> >>
> >> Hope this gives you at least a few ideas to explore...
> >>
> >> Regards,
> >>
> >> Joe
>