RE: ASP authentication

["Scovetta, Michael V" <Michael.Scovetta () ca com>]

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.

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.

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).


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.

Michael Scovetta


-----Original Message-----
From: Ido Mordechai Rosen [mailto:ido () cs uchicago edu] 
Sent: Monday, August 30, 2004 4:41 AM
To: focus () karsites net; webappsec () lists securityfocus com
Cc: pfeito () netcabo pt; Benoni.MARTIN () libertis ga;
RichardZuech () miamibeachfl gov
Subject: Re: ASP authentication


Hi there. :)

  I hope my code is of some use to you.  (Remember, I'm a student...that
means I'm POOR. *hint hint* :) Anyhow, here's my spiel on this:

  While sessions alone are secure enough for most sites to allow access
to content after authentication (i.e.: upon successful authentication a
session variable called "authenticated" is set to "yes" and this session
variable is checked whenever a members-only portion of the site is
viewed), the added protection of encrypting any session data stored on
file (i.e.: in a database server, not just in memory), is a step in the
direction of  thwarting users who gain access to the database, or
perhaps less than ethical DBAs, from abusing that access.  It's not
foolproof, but it lets you say "Absolutely none of your data is stored
unencrypted on disk," and mean it.  (Assuming you don't store anything
sensitive outside of the session, in which case you'd want to encrypt
that too.)  

  A more lofty encryption scheme (and more CPU- and disk- intensive one)
that blinds pretty much everyone but the user from seeing data
(including blinding you!) would make use of RSA or other asymmetric
encryption algorithm(s), using the user's password or session key as the
private key, and storing the public key (generated from the
passwd/session id/private key in the database entry/record/row with the
encrypted data.  I didn't implement such a scheme because I thought it
might be overkill and would definitely not be very resource-friendly.

Best wishes,
Ido Rosen


On Sun, Aug 29, 2004 at 04:28:09PM +0000, focus () karsites net wrote:
> May be of some use:
>
> Encrypted session date code example - HTH
>
> http://www.cs.uchicago.edu/~ido/session_include_php.txt
>
> Regards - Keith Roberts
>
>
> On Sat, 28 Aug 2004, pfeito wrote:
>
> > To: 'B?noni MARTIN' <Benoni.MARTIN () libertis ga>,
> >      webappsec () lists securityfocus com
> > From: pfeito <pfeito () netcabo pt>
> > Subject: RE: ASP authentication
> >
> > You could hash or encrypt the UserID and store it in a session
variable.
> > This adds an extra layer of security. Its not bullet proof but its
more safe
> > and it adds little cpu overhead.
> >
> > Hash would be better than symmetrical encryption, but then you'll
need the
> > passwords hashed in the database also.
> >
> > -pfeito

-- 
+-------------------------------------------------+
|  Email : ido () ieee org / ido () cs uchicago edu     |
| Jabber : phaedo () jabber org                      |
|    PGP : http://www.cs.columbia.edu/~ido/pgp    |
+-------------------------------------------------+