|
|||||||||||
|
Current Project Design, Comments?
From: Michael Loll <mloll(at)pointetech.com>
Date: Fri Feb 14 2003 - 15:26:20 EST
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. --
This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:07:48 EDT |
||||||||||
|
|||||||||||