Page 1 of 3 123 Last
  • Jump to page:
    #1
  1. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2002
    Posts
    42
    Rep Power
    13

    Question How secure is this?


    I have an auto login feature on a site that I'm building.

    The way I've done it is store the memberís username and their MD5 password in a cookie. When they return to the site I check for the existence of the cookies and if they are there I run the login against the DB and see if the cookie MD5 password matches the DB MD5 password.

    Is there anyway to make this more secure? Or is this ok?

    Cheers
  2. #2
  3. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Feb 2001
    Location
    USA
    Posts
    830
    Rep Power
    14
    That seems to leave the password pretty exposed in a cookie.
  4. #3
  5. Always Spell Chek
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2002
    Location
    NJ, USA
    Posts
    338
    Rep Power
    13
    What stops a hacker from using the cookie? You could hijack the cookie and you are set.

    You should store at most, a userid and session id which can be checked against current session data and user information.

    Example:

    Scenario 1:

    [User logs in]
    1. password is checked
    2. cookie set with userid
    3. session is started, session variables saved
    4. log session id and time
    5. user surfs using session data
    6. (optional) as user surfs update session log w/ location etc

    [User logs out]
    1. kill session
    2. expire cookie
    3. clear session log of user entry

    Scenario 2:

    [User logs in]
    1. password is checked
    2. cookie set with userid
    3. session is started, session variables saved
    4. log session id and time
    5. user surfs using session data
    6. (optional) as user surfs update session log w/ location etc

    [User does not log out and returns to surf]
    1. check cookie for userid and session id
    2. check session log, if session is current update log (you can control how long to expire session) else kill session, start new one, and log it.
    3. user surfs using session data
    4. (optional) as user surfs update session log w/ location etc


    It seems like alot of work, but a full system which uses sessions, cookies, and logging will help you not only prevent misuse, but it will give you more options.

    Options like:

    - Forcing login even if cookied. This will help you if you feel there has been misuse, it will reverify the users. It will also keep users which you have banned or deleted from using an old cookie to get onto your sytem. Also, prevents two users from using the same cookie.

    - User tracking can be effected using query strings, request URI's etc. You can tell where your users are at all times, and where they were if they got an error.

    - Uses sessions, and cookies, so the passwords or other sensitive information is not stored or processed anywhere but on the server.


    Hope this helps.
    Programming is easy. It's the thinking that's hard.

    Search the forums before you ask your question.
    PHP | MySQL websites. Visit them, read them, cherish them.
    Read the posting rules, before you post.
    See if your question has been answered already.
  6. #4
  7. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2002
    Posts
    80
    Rep Power
    13

    Re: How secure is this?


    Originally posted by Invoke
    I have an auto login feature on a site that I'm building.
    Is there anyway to make this more secure? Or is this ok?
    One of the golden rules of secure programming is "never trust users input".

    In this case, you can't trust that the person with the cookie is the real user. If you assume that everyone is out to hack your site you won't go far wrong....apart from becoming totally paranoid like me!

    Trev
    --
    http://www.aardvarkbusiness.net/
  8. #5
  9. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Feb 2001
    Location
    USA
    Posts
    830
    Rep Power
    14
    I don't want to hijack this thread, but I'd be interested to learn more about the session logging of which maytricks spoke . . . I'm not really familiar with the practice.
  10. #6
  11. Contributing User
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Jun 2002
    Location
    Washington, DC
    Posts
    2,692
    Rep Power
    22
    Ok, to your original question Invoke:
    posted by Invoke:
    I have an auto login feature on a site that I'm building.

    The way I've done it is store the memberís username and their MD5 password in a cookie. When they return to the site I check for the existence of the cookies and if they are there I run the login against the DB and see if the cookie MD5 password matches the DB MD5 password.

    Is there anyway to make this more secure? Or is this ok?
    Your way is the preffered way of validating a cookies string. We can all see that you have thought your cookie system out pretty well as inexperience people would just check on the existance of a cookie for validation, which is sure fired trouble.
    posted by JMM:
    That seems to leave the password pretty exposed in a cookie.
    Well, yes. But how usefull is it hashed up in md5, not much usefull...
    posted by maytricks:
    What stops a hacker from using the cookie? You could hijack the cookie and you are set.
    Well, if someone hijacks the cookie and does some trouble with it, the user would not have to travel far to figure out who did it as the only people that would hijack the cookie are users of the same machine or terminal. So, it would be nobodies fault but the owner of the cookie...
    posted by: trevHCS
    One of the golden rules of secure programming is "never trust users input".

    In this case, you can't trust that the person with the cookie is the real user. If you assume that everyone is out to hack your site you won't go far wrong....apart from becoming totally paranoid like me!
    And you can't trust the person without the cookie to be the correct user neither. Do you know how many people use the password remember feature that is with your browser, a whole hell-uv-alot. This makes any application vulnerable for user account damage when more than 1 person is accessing the same computer under the same user.

    -----------------------------------------------------------

    Invoke,
    Bottom line is that enabling an auto log-in feature is not a bad thing and you have took the correct route in trying to make it as secure as possible. Give your user the option to use auto-login if they wish, if they choose not to do auto log-in, than don't set the cookie and let them browse under a session_enabled auth system, just as this BB system does.

    Also, to add total security to your site, use SSL for the user log-in to ensure no sniffers hijack any of the log-in data in the transfer...
    ~ Joe Penn
  12. #7
  13. Always Spell Chek
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2002
    Location
    NJ, USA
    Posts
    338
    Rep Power
    13
    Well, if someone hijacks the cookie and does some trouble with it, the user would not have to travel far to figure out who did it as the only people that would hijack the cookie are users of the same machine or terminal. So, it would be nobodies fault but the owner of the cookie...
    It is not possible to obtain a cookie by other means? If the computer is connected to the Internet there are more ways than one to get cookie data off a remote computer. Most of them involve illegal or un-ethical means, but it is not impossible.

    And what if the hacker or hijacker is on the same terminal or network. Does that mean once that cookie is taken and copied from that terminal can't be used in other locations, or taken apart and examined?

    I agree, it would be the fault of the owner of that cookie for not securing his or her data, however, who pays when the owner of the cookie fails to secure it? You do, hence, you should consider a process to verify the cookie is unique to the user, computer, IP, etc.

    The only security you can count on is your own. You can't assume that a user is who they appear to be, you must find a way to authenticate them in everyway possible.
    Programming is easy. It's the thinking that's hard.

    Search the forums before you ask your question.
    PHP | MySQL websites. Visit them, read them, cherish them.
    Read the posting rules, before you post.
    See if your question has been answered already.
  14. #8
  15. Contributing User
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Jun 2002
    Location
    Washington, DC
    Posts
    2,692
    Rep Power
    22
    It is not possible to obtain a cookie by other means? If the computer is connected to the Internet there are more ways than one to get cookie data off a remote computer. Most of them involve illegal or un-ethical means, but it is not impossible.
    Yes, but that also leaves cookied_enabled_sessions open for attacks, and the password remember feature open also for attacks as the data can also be retrieved by a hacker through the inet.....
    And what if the hacker or hijacker is on the same terminal or network. Does that mean once that cookie is taken and copied from that terminal can't be used in other locations, or taken apart and examined?
    Again, same as above. As far as examining any info in the cookie, it will be worthless as he is hashing the data....
    you should consider a process to verify the cookie is unique to the user, computer, IP, etc.
    Thats true in any kind of auth system, but remember we can only go so far. No auth system at the present moment is 100% secure, we can only hope in the future that developers are presented with more options that enable the creation of solid auth systems.

    The thing is the only way to make an auto-login system (as far as I know) is to use a cookie based system and he has taken the best route to secure the cookie string. As long as he is not storing cc numbers, financial information, or any other sensative data, an auto-login feature is not a bad thing.

    Also, I am assuming that he is not storing sensative information as only common sense will tell any developer not to use a auto-login system when storing this kind of info........
    ~ Joe Penn
  16. #9
  17. No Profile Picture
    Moderator =(8^(|)
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Feb 2002
    Location
    Sacramento, CA
    Posts
    1,710
    Rep Power
    14
    Well, another interesting approach I found.

    This app we have at work uses an ActiveX object to store the user/password in the registry. Of course that kinda limits the platform a client can use to connect...
  18. #10
  19. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Feb 2001
    Location
    USA
    Posts
    830
    Rep Power
    14

    JMM:
    That seems to leave the password pretty exposed in a cookie.

    JPenn:
    Well, yes. But how usefull is it hashed up in md5, not much usefull...
    It's as useful as any other password that gains entry to the site, is it not?
  20. #11
  21. Contributing User
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Jun 2002
    Location
    Washington, DC
    Posts
    2,692
    Rep Power
    22
    It's as useful as any other password that gains entry to the site, is it not?
    No. He is checking against the entered password. For instance, if I use this password -> 6359842 <- as my password string, it would only be true if I use that exact password. If I tried to use my md5 encrypted password -> 6b0266aa460fce19cf54832f772aa94e <- it would return false because the string will be put back thru the hash and re-hashed which in return would fail on the check......

    Well, at least crypt() would fail. Never used md5() for pass storing but I can only imagine it would fail....
    Last edited by jpenn; October 21st, 2002 at 04:28 PM.
    ~ Joe Penn
  22. #12
  23. No Profile Picture
    Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2001
    Posts
    15
    Rep Power
    0
    Cookies shouldn't be considered user entered data due to few if any user agents allow users to alter/add (spoof) cookies manually. Thus there is a high possiblity that data sent as a cookie is valid.

    However if you are going to treat cookies are user input then you must also treat the user agent string (perfectly easy to spoof) and the IP address (spoofable via X-Forwarded-For) as user input too, thus in this situation producing a secure auto-login system is impossible unless you run the whole site over SSL. Then again there are some interesting errata relating to SSL, Apache 1.x and proxies.

    Thus the solution is to accept there are some small risks with auto-login features when designed correctly and make the user aware that its not 100% secure or force the user to login each time over SSL, with well designed auto-login systems it should not be possible to post/get the data back to server as anything but a cookie and become the target user.

    The only real solution is packet level encryption but untill IPv6 or IPSec becomes common place that is not a option.
  24. #13
  25. No Profile Picture
    The Bisifiniti
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 2001
    Posts
    25
    Rep Power
    0
    Think of it this way. If the password is in a non-encrypted format in any other place than the login textbox, you're much higher at risk
  26. #14
  27. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2002
    Posts
    42
    Rep Power
    13
    Thanks for the feedback guys, some really good advice here

    Maytricks:
    When you mentioned checking the session log, I assume you mean having a sperate logs table with like the member ID and their current session ID if logged in and a null if they logged out?

    Thanks
  28. #15
  29. Always Spell Chek
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2002
    Location
    NJ, USA
    Posts
    338
    Rep Power
    13
    Yes, one table for their user information, and a separate one that can hold temporary information like session id, ip addy, useragent, request uri, etc.

    All you really need to do is create a function that will INSERT/DELETE/UPDATE when they log in then something that can UPDATE why they are browsing.
    Programming is easy. It's the thinking that's hard.

    Search the forums before you ask your question.
    PHP | MySQL websites. Visit them, read them, cherish them.
    Read the posting rules, before you post.
    See if your question has been answered already.
Page 1 of 3 123 Last
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo