WebApp Sec mailing list archives
Re: ASP authentication
From: ido () cs uchicago edu (Ido Mordechai Rosen)
Date: Tue, 31 Aug 2004 14:17:01 -0500
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
Current thread:
- RE: ASP authentication, (continued)
- RE: ASP authentication Brett Moore (Sep 01)
- Re: ASP authentication Ido Mordechai Rosen (Sep 01)
- RE: ASP authentication Zuech, Richard (Aug 27)
- RE: ASP authentication focus (Aug 28)
- RE: ASP authentication pfeito (Aug 29)
- RE: ASP authentication focus (Aug 29)
- Re: ASP authentication Ido Mordechai Rosen (Aug 31)
- RE: ASP authentication Sarbjit Singh Gill (Aug 29)
- FW: ASP authentication Rishi Pande (Aug 27)
- RE: ASP authentication Scovetta, Michael V (Aug 31)
- Re: ASP authentication Ido Mordechai Rosen (Sep 01)
- Re: ASP authentication Saphyr (Sep 01)
- Re: ASP authentication Ido Mordechai Rosen (Sep 01)