RE: Current Project Design, Comments?

From: Douglas Schlenker <Douglas.Schlenker(at)RoyalRoads.ca>
Date: Mon Feb 17 2003 - 11:08:49 EST

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
work: 301-306-4400 x4441 / cell: 240-603-7372 / fax: 301-306-4421

* 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.
****************************************************************************
**

Received on Mon Feb 17 12:58:15 2003