Classic ASP Session v Database check cookie for secure pages

Hi All

I’ve wanted to ask this for years, but never got round to asking clever people like yourselves :slight_smile:

I continue to develop web apps in Classic ASP and I’m happy in my own skin doing this :slight_smile:

I’ve always authenticated pages over an SSL connection by checking the supplied username and password in a DB and if OK putting a value of say true in a session var and then checking if this same var says true at the top of each page that needs to be secure. The only downsides I’ve ever had with this is the 20 min timeout issue, but now I work on dedicated servers so I can increase this timeout, and ultimately not knowing if this is really the best and most secure method of doing it :slight_smile: I’ve never done the httponly bit because I’m scared of the URL Rewrite blowing up my IIS 7+, but perhaps I should???

I’ve toyed with the idea of putting some form of encrypted token in a cookie, but would the following be better than a session cookie:

  • Log on with the DB over SSL as normal.

  • Create a really long random token in the DB for the logged in user.

  • Put this token in the cookie.

  • For every page check this token with the DB.

  • When the user quits the browser the cookie dies, so they have to log in again (which is fine it was all about just keeping the state for whilst ever they are using the web app) and it creates a new random token.

My issue with the above is that on every page it is doing at least one DB call to check if the cookie matches the user whereas the session cookie method would be no DB call at all.

Is the above cookie method OK? Is it actually better or worse than the session method?

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.