RE: Prevent security bypass

["David Mowers" <davemo () windows microsoft com>]

Windows Integrated Authentication in IIS/IE is a negotiation between
Kerberos and NTLM (v2). Whenever possible, basically Win2k+
environments, Kerberos will always be negotiated. 

NTLM v2 is a reasonably strong authentication protocol and certainly
does not use "unencrypted hashes" - whatever that means. The NTLMv2
protocol has existed in its current form since NT SP4 and Win9x with the
DS client pack.

If you are worried about brute-forcing the NTLM challenge response then
this attack can be mitigated by turning on strong password policy and/or
protecting all traffic with the web server via SSL. Brute forcing NTLM
auth with strong passwords is extremely difficult and beyond the ability
of all except the most determined attacker with significant resources.

MS-CHAP is not used by any Microsoft products other then IAS for RADIUS.

Adam, your life should be very easy.

Dave

-----Original Message-----
From: Larry Seltzer [mailto:larry () larryseltzer com] 
Sent: Thursday, February 06, 2003 3:49 AM
To: 'Adam'
Cc: webappsec () securityfocus com
Subject: RE: Prevent security bypass

Are you thinking of the difference between Basic and Integrated
authentication in IIS?
In any event, I believe the standard challenge response is MS-CHAP:

According to
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/
html/vxconIISAut
hentication.asp: "Integrated Windows authentication is the best
authentication scheme in
an intranet environment where users have Windows domain accounts,
especially when using
Kerberos. Integrated Windows authentication, like digest authentication,
does not pass
the user's password across the network. Instead, a hashed value is
exchanged."

According to
http://www.microsoft.com/windows2000/en/advanced/help/auth_mschap.htm:
"Microsoft created MS-CHAP to authenticate remote Windows workstations,
providing the
functionality to which LAN-based users are accustomed while integrating
the encryption
and hashing algorithms used on Windows networks. It uses a
challenge-response mechanism
with one-way encryption on the response.

Where possible, MS-CHAP is consistent with standard CHAP. Its response
packet is in a
format specifically designed for Windows NT and Windows 2000, and
Windows 95 and later,
networking products. In addition, MS-CHAP does not require the use of
plaintext or
reversibly encrypted passwords."

-----Original Message-----
From: Adam [mailto:a.bardsley () lancaster ac uk] 
Sent: Thursday, February 06, 2003 5:05 AM
To: Adam
Cc: webappsec () securityfocus com
Subject: RE: Prevent security bypass


I might be wrong about this but I couldn't find anything on MS' site
(who
can?) but I thought the standard NT challenge response was sent
unencrypted. If this has
changed I'd love to know because t would sure make my life easier :)

Adam

-----Original Message-----
From: Chris Travers [mailto:chris () travelamericas com]
Sent: 06 February 2003 07:20
To: Adam
Cc: webappsec () securityfocus com
Subject: Re: Prevent security bypass


Adam wrote:

> It depends how secure you want it as a lot of people have said but I 
> would personally go for what you suggested as bar the v.expensive 
> suggestions or the ones relying on being on the same NT network you 
> arent going to get anything very secure. We have a secuirty script 
> called on each secure page. The overhead doesnt seem that bad tbh.
What makes you say that?  If you are on NT, then any insecurities of the
authentication
protocol are ALREADY going to affect you.  Applying diversity in depth
might buy you
something but only if it is paired with good NT security practices,
Besides, if your
server is not secure, you are already screwed.

The way I design my web applications which require granularity of
permissions for
different users or other advanced security features is based on the
following
principles:

1)  Primary Security on Backend-- don't try to do any more enforcement
than you have to
on the middleware.  And avoid ANY enforcement of anything important on
the front-end.
Instead, try to do as much enforcement with the backend components as
possible and only
suppliment with the middleware as needed.  The idea here is that you
enforce permissions
using the web server, operating system, and/or information store (such
as RDBMS and
LDAP) as much as possible because these are the most robust
security-wise, and they can
be attacked independently anyway.  Furthermore these are the only
solutions that can
globally protect the information (from inside the web context or outside
it).

2)  Supplimental Security in Middleware-- Sometimes, it is necessary to
place
information in the information store in an insecure fassion,and this
could be used for
DoS attacks.  One example might be a user profile in an RDBMS system
where all users
will be able to write to and update that table.  In this case, enforce
additional
security on the middle-ware.  But this security is much more brittle and
not as strong,
so it should not be relied upon as much.

3)  Protect content In Transport-- Use SSL to protect the content and
passwords.

Best Wishes,
Chris