RE: Current Project Design, Comments?

[Douglas Schlenker <Douglas.Schlenker () RoyalRoads ca>]

As many of you are probably aware (but it hasn't been mentioned yet), the
ViewState mechanism will have a huge performance impact on your application.
In my own applications I've seen ViewState more than double the size of the
page being rendered due to the amount of information being stored. Using the
caching mechanisms IMO is a much more flexible and better alternative.

Douglas Schlenker
Systems Analyst
Royal Roads University

-----Original Message-----
From: Gal Rozov [mailto:Gal.Rozov () ealaddin com] 
Sent: February 17, 2003 1:01 AM
To: Michael Loll
Cc: webappsec () securityfocus com

Hi Michael,

1. "Client to Web Server: Custom authentication against a
username/password stored in Oracle DB.  The database actually only
stores the username, a hash of the password, and a random salt value
used in the hashing process.  No password is actually stored in the
database."
 - Can you please explain in more detail how this works?, if you store a
hash with random salt how can you compare the hash to the entered
password when the user logs in and validate him?

2. ASP.Net has a login mechanism to do the redirection automatically,
why haven't you used it or extended it?

3. Have you considered the performance issues of your design, I see you
used a lot of security layers that can reflect on the site's
performance.
    Can someone shade a light on this subject from his own tests because
I saw some benchmarks from Microsoft yet I'm still not sure they checked
all the aspects together?

4. As someone said before you can't rely on the ViewState mechanism
because it's not that secure (Base64 with some salt), you can consider
using the Caching API for saving data.
   Depending on your server strength and the size of the data, look for
it on MSDN :)
   * If you use session variables your server is more prone to DDOS
attacks because it can crash when the system looses free resources
space. 
     (as against to caching API that slows down the server when it
happens)

All and all it looks great and I'll be glad to get your
impressions/conclusions when you finish with the site, we also plan on
developing an ASP.Net secured site and it will be great to get some
UNBIASED remarks on ASP.Net secured sites :)

Thanks and Best Regards.
 
Gal Rozov
Senior Developer.
 
Aladdin. Securing the Global Village.
P.O. Box 11141,  Tel Aviv 61110 Israel
Tel:   +972 3 636-2222; Fax: +972 3 537-5796
Visit us at our Web site!  http://www.eAladdin.com
 
Aladdin supports Idealist. Visit http://www.idealist.org


-----Original Message-----
From: Michael Loll [mailto:mloll () pointetech com] 
Sent: Friday, February 14, 2003 10:26 PM
To: webappsec () securityfocus com
Subject: Current Project Design, Comments?


I am currently on a project designing an ASP.NET-based application for a
client.  I would welcome any comments on my security design so far.

Communication Protection
------------------------
Client Web Browser to Web Server: 128-bit SSL encryption
Web Server to Database Server: IPSec (via Windows 2000 Server)

Authentication
--------------
Client to Web Server: Custom authentication against a username/password
stored in Oracle DB.  The database actually only stores the username, a
hash of the password, and a random salt value used in the hashing
process.  No password is actually stored in the database.

Web Server to Database Server: A single identity is used to talk to the
DB server from the Web Server.  These credentials are stored on the Web
Server in encrypted form and are decrypted when needed (and stored in
memory).  The key for decryption is the password of the web account -
this is all handles via Window's data protection api.

Authorization
-------------
Client to Web Server: Subsystems of the application are protected via
custom role-based security.  Each user has a "role" and if that page is
not viewable by that role, they are redirected to a different page.

Web Server to Database Server: The trusted identity has minimum rights
to the specified tables and procedures needed to perform its duties.

Pretty standard in the web world, correct?  I am still trying to figure
out a universal way to handle SQL injections.  I garnered most of this
from Microsoft's whitepaper on secure ASP.NET applications.


--
Michael Loll
Consultant / Pointe Technology Group, Inc.
mloll () pointetech com / www.pointetech.com


* This email is my opinion and not that of my employer.

******************************* IMPORTANT !
**********************************
The content of this email and any attachments are confidential and intended 
for the named recipient(s) only.

If you have received this email in error please notify the sender
immediately.
Do not disclose the content of this message or make copies.

This email was scanned by eSafe Mail for viruses, vandals  and other
malicious content.
****************************************************************************
**