W
Wiktor Zychla
Hello,
after several investigations around ASP.NET, I would like to ask about
the best practices for building a secure database application.
suppose I wish to use Forms authentication in ASP.NET. the user must be
verified against the database and I see two options here:
1) each user profile is stored as the separate login in the SQL Server
pros:
- there should be no problems with security
cons:
- after the server crash, revival of the site could be painful
(thousands of SQL logins with unknown passwords)
2) each user login and password is stored in a table in the database and the
ConnectionString is always set for a fixed user with fixed password
pros:
- the revival of crashed server is easy, since all security data is
stored in a single database
cons:
- the fixed user and fixed password could be used by anyone to break
into the database and perform some malicious activities
as far as I've noticed, the second option is more popular (to be frank: I've
never seen any ASP.NET application that would follow the first scenario). in
my opinion this raises the security problems: anyone allowed to access the
SQL machine could use the fixed user parameters and do anything with the
data in the database.
what would be the other possibilities then? how the real-world applications
are built? should I think of another form of ASP.NET or SQL authorization
(Windows instead of Forms, Windows instead of SQL)? or maybe I should
redesign the application to use the existing models in a more proper way?
thanks for any clues,
Wiktor Zychla
after several investigations around ASP.NET, I would like to ask about
the best practices for building a secure database application.
suppose I wish to use Forms authentication in ASP.NET. the user must be
verified against the database and I see two options here:
1) each user profile is stored as the separate login in the SQL Server
pros:
- there should be no problems with security
cons:
- after the server crash, revival of the site could be painful
(thousands of SQL logins with unknown passwords)
2) each user login and password is stored in a table in the database and the
ConnectionString is always set for a fixed user with fixed password
pros:
- the revival of crashed server is easy, since all security data is
stored in a single database
cons:
- the fixed user and fixed password could be used by anyone to break
into the database and perform some malicious activities
as far as I've noticed, the second option is more popular (to be frank: I've
never seen any ASP.NET application that would follow the first scenario). in
my opinion this raises the security problems: anyone allowed to access the
SQL machine could use the fixed user parameters and do anything with the
data in the database.
what would be the other possibilities then? how the real-world applications
are built? should I think of another form of ASP.NET or SQL authorization
(Windows instead of Forms, Windows instead of SQL)? or maybe I should
redesign the application to use the existing models in a more proper way?
thanks for any clues,
Wiktor Zychla