[thelist] Enough security

Peter Loron peterl at www.standingwave.org
Wed Nov 10 15:19:12 CST 2004

> On Wed, 10 Nov 2004 14:41:32 +0100, Andreas Wahlin  
> <Andreas.Wahlin at ufl.gu.se> wrote:
> > I have a site that different persons log onto, mainly it's
> > administrators and students. Information logged on the students is
> > somewhat sensible; adress, phone number, "social security number"
> > (Personnummer for Swedes), some administrator comments and so forth.
> > This is protected with userid and password login.
> >
> > The site as such is protected by SSL, and I have an Access 2003 database
> > (ok so flame me :) in a place where you can't reach it from the web
> > (like typing https://thesite/thedatabase.mdb). This database contains
> > usernames and passwords and of course all the data.
> > The userid and password is input by using a form with method post and
> > action="", so the info gets posted to the same page and then parsed in
> > ASP script.
> > The ASP script fetches username and password from the database and
> > compares with Request.Form, if they match a Session variable is set to
> > the username which every page then polls to see if the user is a valid
> > one.
> > Thus only one comparison is done with username and password, after that
> > each page just checks if the username is in the database.
> >
> > Now, my question, if you've bared with me so far is; is this enough
> > security. Can I sleep at night knowing I did pretty much what I could,
> > or is this childsplay? (I'm not that good server side, or on security)
> >
> > I know that if only people knew the username of a person and the name of
> > the session variable in which I store it, they could set that externally
> > and then just walz in on the place, but other than that I don't see any
> > major flaws, but then I don't know much about this.
> >
> > Big thanks in advance for help
> >
> > Andreas

You shouldn't be storing the passwords (or any sensitive information) in 
the database in the clear. What you can do is store a one way hash of the 
password (MD5 or SHA1, etc) in the database. Then when an authentication 
request has been received, you can hash the submitted password and compare 
the stored hash and the newly computed one. This prevents sensitive 
information from being exposed even if the database is compromised.


More information about the thelist mailing list