Re: ASP authentication

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

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    |
+-------------------------------------------------+