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

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

Adam wrote:

>It depends how secure you want it as a lot of people have said but I
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 Received on Thu Feb 6 08:16:34 2003