Re: ASP authentication

[ido () cs uchicago edu (Ido Mordechai Rosen)]

On Tue, 31 Aug 2004 09:37:20 -0400
"Scovetta, Michael V" <Michael.Scovetta () ca com> wrote:

> The weakest link in the chain *should be* the session identifier that
> travels between client and server. As long as SSL is used, this
> identifier should be safe [assuming no MITM attacks], and most app
> servers now have good random session id generators.

Yes.  Also, the identifier is only valid for a short period, and is only
valid from a certain IP (the user's IP at the beginning of the session),
if you want to be picky.  I'd say that's secure enough to protect
against any reasonable hijacking.  ("Who are we protecting against?")


> If someone gets root/physical access to the server, then it is likely
> that any effort on your part will be fruitless. They can always modify
> the database, invoke your internal function calls, modify your code,
> or just get into the back-end data source.

This is not entirely true.  If someone gains root/physical access to the
DATABASE SERVER, they can not do anything with the encrypted sessions
because they do not have the key(s) to decrypt them.  Your above
statement only makes sense if someone hacks into the web server, in
which case all bets are off.  If you read my commentary regarding
encrypted sessions, you'd see that I specified "users gained access to
your db server or less than ethical DBAs" as the targets you are
protecting against.  

> IMHO, 95%+ of errors are application-level. This isn't to say that
> storing data encrypted/etc is bad idea, but simply that it's not going
> to gain you very much (unless you're in a specialized environment
> where that is a requirement).

See above.  Encrypted sessions *do* gain you *quite a bit* security-wise
when your db server and web server are on different machines, which is
usually the case with web hosts.  Anyhow, your analysis is good
regarding "95%+ of the errors are application-level".  I would venture
to say that 80%+ of errors/security breaches are also poor input
validation on the web developer's part, which encrypted sessions won't
protect you against.

> I usually don't implement anything crazy for authentication to
> specific pages. At the top of each ASP page I have a function call
> require(rolename), which checks the session variables to see if the
> role is included. If not, redirect to the login. The login sets up the
> roles. End of story.

Yeah.  I agree.  For *authentication*, that is pretty much it.  Behind
the scenes, encrypted sessions are a good thing solely as an added layer
of protection against database server breaches...nothing more.  

Ido