SitePoint Sponsor

User Tag List

Results 1 to 15 of 15

Hybrid View

  1. #1
    SitePoint Addict
    Join Date
    Jan 2005
    Posts
    204
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    checking login security

    when checking for user login, i usually do this like after the user has logged in with the correct username and password, i will set a SESSION or COOKIE variable like 'login' = 1;

    so when i check if the user is logged in, i do this:
    Code PHP:
    if($_SESSION['login'] == "1") {
     print "logged in";
    }

    however i began to wonder if this is secure enough? is it possible where people can fake a cookie or session by creating a similar cookie name and value to 1?

    thanks.

  2. #2
    SitePoint Member
    Join Date
    Apr 2007
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I believe it's better practice to store the user id and password hash or similiar in a session or cookie, and then on each page you would query the database with the given information to see if the user actually exists.

  3. #3
    SitePoint Addict
    Join Date
    Jan 2005
    Posts
    204
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    if need to do a query to check the login details, isn't it going to make the site slower?

  4. #4
    SitePoint Enthusiast
    Join Date
    Jul 2004
    Location
    NL, Rotterdam
    Posts
    38
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, it will make things slower. If a scenario is likely to occur where during it's login-session a user will be removed or it's access rights change, then it is useful to keep checking.

    To limit the risk of session highjacking you could also store the remote-ip in the session and destroy the session when the ip doesn't match. But then if your client's webserver suddenly gets moved behind two load-balancing proxies, stuff goes wrong...

    Also store a last activity timestamp so that you can destroy a login-session after some inactivity and don't have to worry about how long a session gets stored on the server or an attacker that tries to revive an old session on a different computer.

  5. #5
    SitePoint Guru MikeBigg's Avatar
    Join Date
    Jun 2004
    Location
    Reading, UK
    Posts
    970
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by x[E]nOn View Post
    if need to do a query to check the login details, isn't it going to make the site slower?
    Will you be access the database for other things for the page? If so, then one extra query isn't going to make much difference.

    To avoid users faking cookies, you could encrypt the data in the cookie and include either creation time or expire time (or both) in the data. Decrypt the data and checking it is still within the valid time.

    Don't store the IP address for validation - AOL users' IP addresses may change from page request to page request.

    Mike

  6. #6
    SitePoint Enthusiast
    Join Date
    Jul 2004
    Location
    NL, Rotterdam
    Posts
    38
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by MikeBigg View Post
    Don't store the IP address for validation - AOL users' IP addresses may change from page request to page request.
    Interesting point, I'll take that into account. Haven't had sites targeting AOL users (Dutch based projects) so I haven't encountered such issues yet (I would have noticed soon enough ).

  7. #7
    SitePoint Evangelist
    Join Date
    Aug 2004
    Posts
    428
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Question where is my bad *** programmer avatar

    best method to use is serialize and unserialize the user object
    if you can return an object instanceof User then he's a valid user and you also have his current credentials including activity since he first logged in.

    I call this my authorization object and have Authorization::getInstance() unserializes from session. throws exception if the user isn't logged in.

    function inside authorization private function save()
    moves object to a serialized session. used only when modification to authorization or user object is affected . else it remains the same as when the user first logged in.

  8. #8
    SitePoint Zealot
    Join Date
    Jun 2004
    Location
    Norway - Oslo
    Posts
    198
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    On some fairly decent traffic sites i've not even once seen the simple method that threadstarter suggests actually being a security problem.
    Perfection is rarely the perfect solution for a problem as we all know, which brings me to ask, do people overdo security for apps that will never need such high security?
    Or do you actually have hands on experience pointing to the simpler methods in this case actually not being secure enough?
    Raymond Julin
    Developer: Hardware.no, Amobil.no, Gamer.no, Prisguide.no ...
    Owner: Kulturo.no

  9. #9
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > do people overdo security for apps that will never need such high security?

    Regardless of the application, or the environment the application is used in, you can never overdo security from my point of view. It's better in any regard to go way out of your way to be secure, or at least to the point that you can determine that you can't be more secure.

    You shouldn't take any chance with security on any level; When you do, this is how someone somewhere will find a hole and gain access, so believe me when I say don't just stop development of an applications security once it's finished, as it's a continual ongoing process.

  10. #10
    SitePoint Addict Jasper Bekkers's Avatar
    Join Date
    May 2007
    Location
    The Netherlands
    Posts
    282
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    1. As long as you don't store any credentials (even "logged in") in a cookie you should be fine.
    2. You also don't want to store user credentials in you session, because we al know what shared hosts are like.
    3. If you have a security hole, dub it plugin architecture and you'd be fine
    4. You don't need to query the database every time to make sure the user is authenticated. However, the permissions a user has should remain in the database because you don't want them in a public place (cookie or /tmp).

    So as long as you protect yourself from session hijacking you should be fine with the example above.
    Design patterns: trying to do Smalltalk in Java.
    I blog too, you know.

  11. #11
    SitePoint Addict
    Join Date
    Jan 2005
    Posts
    204
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jasper Bekkers View Post
    1. As long as you don't store any credentials (even "logged in") in a cookie you should be fine.
    2. You also don't want to store user credentials in you session, because we al know what shared hosts are like.
    3. If you have a security hole, dub it plugin architecture and you'd be fine
    4. You don't need to query the database every time to make sure the user is authenticated. However, the permissions a user has should remain in the database because you don't want them in a public place (cookie or /tmp).

    So as long as you protect yourself from session hijacking you should be fine with the example above.
    i am not too sure how session hijacking works. i am on a shared host but how would this affect my sessions?

  12. #12
    SitePoint Zealot rawkes's Avatar
    Join Date
    Oct 2006
    Location
    Surrey, UK
    Posts
    121
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Can someone explain to me what the use is for storing the user's password in the session?
    Rawkes - Standards based web design and development

  13. #13
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Not sure what you are asking but it shouldn't be the password alone that you store, but a hash, which may comprise of several pieces of data,

    PHP Code:
    $request -> get'session' ) -> set'...'sha1$row['hash'].$row['email'].'-'.$row['password'] ) ); // ... 
    When I create a new user, I put a randomly generated 12 character hash in the database row for that user, and use it along with email and password (which is MD5 anyway) to create a hash.

    It's that hash that is stored in the session; Pretty much secure since the 12 character hash is unknown (it's unique). If you were paranoid, I suppose you could put an expiry period on the hash and have it regenerated, but it makes no real difference to the login process.

    Does that help?

  14. #14
    SitePoint Addict
    Join Date
    Jan 2005
    Posts
    204
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston View Post
    Not sure what you are asking but it shouldn't be the password alone that you store, but a hash, which may comprise of several pieces of data,

    PHP Code:
    $request -> get'session' ) -> set'...'sha1$row['hash'].$row['email'].'-'.$row['password'] ) ); // ... 
    When I create a new user, I put a randomly generated 12 character hash in the database row for that user, and use it along with email and password (which is MD5 anyway) to create a hash.

    It's that hash that is stored in the session; Pretty much secure since the 12 character hash is unknown (it's unique). If you were paranoid, I suppose you could put an expiry period on the hash and have it regenerated, but it makes no real difference to the login process.

    Does that help?
    i am not storing the password in the session because i thought that is redundant since the user has logged in. however, this wouldn't allow me to do authentication on every page since the the password is not in the sessions. moreover, my concern was doing authentication on every page may slow down the page as there may be many people access the same page at a time and a large number of queries ran were actually to authenticate the users sounds funny to me.

    it was recently that i began to think what happens if someone was able to change the values in the session? since the only session variable i have is the user's id, if someone could change the value of the userid in the session, he could immitate any users on the site and escape from logging in the true credentials.


Bookmarks

Posting Permissions

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