Results 1 to 3 of 3

Thread: using sessions for authentication

  1. #1
    Junior Member
    Join Date
    Sep 2002
    Posts
    5

    using sessions for authentication

    Hi,

    I am writing a program using Java servlets. I want to use a session for user authentication.

    In the login page I check users user name and password with usernames and password in my database and store username and password in a session.

    After that do I have to check the user name and password stored in session with my database, in every page. Or can I just check wether there is a session avaiable and if the session is available, allow the user to view the page.


    Thanks a lot,
    Chamal.

  2. #2
    Senior Member kr5kernel's Avatar
    Join Date
    Mar 2004
    Posts
    347
    This page can show you how to do it with php, if that helps any. I use something similar to this for some web stuff, and it works pretty well.

    http://<br /> <a rel="nofollow" hre...html</a><br />
    edit: I think that link got screwed up, here it is:
    http://php.codenewbie.com/articles/p...ns-Page_1.html
    kr5kernel
    (kr5kernel at hotmail dot com)
    Linux: Making Penguins Cool Since 1994.

  3. #3
    Senior Member
    Join Date
    Mar 2004
    Posts
    557
    Hi


    I assume, you are dealing successfully with the servlet API[1-3]
    for the authentication, managing/tracking of the state or sessions.
    You are here interested in the security implications thereof. I
    want to illustrate my understanding of state and sessions and
    a few thoughts about securing it. I hope I do not confuse too much,
    because plenty of texts available actually do mix up certain issues.


    I would suggest you to have an overview-read about session management
    on the web[4], to fix the ideas and to make you aware of possible weaknesses.
    In particular, even the Servlet's 128bit-session id environment is flawed
    by the initial seed of the pseuo-random generator, and eventually allows
    to hijack client sessions[5]. I look at this whole subject from a
    rather theoretical point of view and would be very happy to listen to
    people in the front line.


    To your question:
    Let me recapitulate state management. If you are using cookies/url-post
    to keep track of the state (e.g. transactions, shopping cart, hashed
    user-id, ...), it will be sent by the browser at each request
    and could consist of quite some data. People tend to secure it by applying
    a very short life-time to a cookie, in particular if the cookie stores
    sensitive data, like a hashed user-id (expiration date: cookie.setMaxAge).
    In addition, the sensitivity of the data accessible with that particular
    user-id also is thrown into the equation. Since you cannot control the
    environment of the user accessing your page, a logout-function might come
    in handy too.


    In the case of sessions, just a session id will be stored in a cookie or by
    url-post, and management thereof is transparent. The "state" can be stored
    in the servlet, ie server-side and/or client-side if the state information
    should be available at a later time. As already mentioned, the session will
    loose its validity after closing the browser or ending the servlet. The same
    precautions as for state management can be used.


    Provide additional information for further discussion.


    Cheers.

    /edit: you might find a few alternative/additional inspirations here on AO[6]

    [1] http://java.sun.com/j2ee/1.4/docs/tu...1.html#wp64744
    [2] http://www.developer.com/java/other/article.php/616801
    [3] http://www.developer.com/java/ent/article.php/616831
    [4] http://www.giac.org/certified_profes.../gsec/4206.php
    [5] http://www.cs.huji.ac.il/~zvikag/Zvi...Malkhi2005.pdf
    [6] http://www.antionline.com/showthread...hreadid=262880
    If the only tool you have is a hammer, you tend to see every problem as a nail.
    (Abraham Maslow, Psychologist, 1908-70)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •