why not SQL Authentication?

[Pavlos Kariotellis]

With Forms authentication and SQL Server, MS recommends creating a User
table and storing user names and password hashes to that table.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT03.aspThey go on proposing a Roles table and so on.I wonder why not just use SQL Server authentication and just try to loginwith the user supplied credentials?

 

[Brock Allen]

The main drawback of SqlAuthentication (authing from browser thru website
thru database) is that connections can't be pooled. For some websites this
is not a concern, but for others where you have huge volume (and/or you're
not doing windows auth against the clients) if you use the client's creds
for SqlAuth then that's an independant connection. So 1000 users on your
site, that's 1000 distinct connections. If you use the same credentials (like
a "SqlUser" account) then those connections get pooled and thus shared. It's
a performance enhancement.

 

[WJ]

Also it may not be safe to transfer SQL PW over the line because SQL doesn
ot encrypt your PW. You also may have some issues with fire wall. Some donot
let it thru, especially the NTLM authentication packet unless you are
sitting inside your FW.

John

 

[Pavlos Kariotellis]

My application is serving small businesses. Each one has its own DB. Most of
the time there is one user per DB. This user my be connected all day long.
To use connection pooling I'l have to log all the users to one DB and the
switch them to appropriate DB. I think this creates a security risk.

 

[Brock Allen]

Absolutely. That's why I said "for some websites it's not a problem" and
in fact for your situation it wouldn't help since you have more than one
database. Connection pooling with a single user for the database doesn't
really buy you anything since in general you're only ever using one conenction
to communicate to the DB.