Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > ASP .Net Security > why not SQL Authentication?

Reply
Thread Tools

why not SQL Authentication?

 
 
Pavlos Kariotellis
Guest
Posts: n/a
 
      03-28-2005
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/de...etHT03.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?

 
Reply With Quote
 
 
 
 
Brock Allen
Guest
Posts: n/a
 
      03-28-2005
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.

-Brock
DevelopMentor
http://staff.develop.com/ballen



> 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/de...ary/en-us/dnne
> tsec/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?




 
Reply With Quote
 
 
 
 
WJ
Guest
Posts: n/a
 
      03-28-2005
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


 
Reply With Quote
 
Pavlos Kariotellis
Guest
Posts: n/a
 
      03-29-2005
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ...
> 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.
>
> -Brock
> DevelopMentor
> http://staff.develop.com/ballen
>
>
>
>> 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/de...ary/en-us/dnne
>> tsec/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?

>
>
>



 
Reply With Quote
 
Brock Allen
Guest
Posts: n/a
 
      03-29-2005
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.

-Brock
DevelopMentor
http://staff.develop.com/ballen



> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) ...
>
>> 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.
>>
>> -Brock
>> DevelopMentor
>> http://staff.develop.com/ballen
>>> 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/de...rary/en-us/dnn
>>> e
>>> tsec/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?




 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
SQL Reference, SQL Queries, SQL help ecoolone ASP .Net 0 01-03-2008 10:58 AM
Why :: ? Why not : ? Why not . ? <- less clutter ?!? Skybuck Flying C++ 16 08-25-2007 09:48 PM
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
why why why does function not work Horace Nunley ASP .Net 1 09-27-2006 09:52 PM



Advertisments