#16
  1. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Feb 2001
    Location
    USA
    Posts
    830
    Rep Power
    14
    No. He is checking against the entered password. . . .
    That's not what he described. I know how hashing works.

    He said

    . . . [I] see if the cookie MD5 password matches the DB MD5 password.
    Just how do you suppose it would be an auto login if the user was prompted for their password?


    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.
    Do you mean they don't provide a special cookie editing client for you? IE and Netscape, at least, store their cookies as plain text files. They seem pretty accessible.
  2. #17
  3. No Profile Picture
    Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2001
    Posts
    15
    Rep Power
    0
    Originally posted by JMM
    Do you mean they don't provide a special cookie editing client for you? IE and Netscape, at least, store their cookies as plain text files. They seem pretty accessible.
    I don't see how "password{LF}5e6fcb9c648d799cd888502c85db4b84" (IE format) or "password 5e6fcb9c648d799cd888502c85db4b84" (NS6/Moz format) is of any real help to a malicous user considering that if you edit either cookie there is high likelyhood of the browser subsiquently regecting the edit and flushing the cookie from its cache. Oh and IE/NS6+ won't let you add your own cookies.

    Oh and my post was based on the assumption that the cookie contains the MD5 hash of the password not the plaintext.

    Then again if someone other than the user can read the users cookies you have many many worse possible problems which are well out of your control (like being able to resubmit some posted data).

    Thus the code should do something like if ($cookie['password'] == $dbpassword) or possibly if ($cookie['password'] == MD5($dbpassword)) depending on if plaintext or hashed passwords are stored in the db.
    Last edited by dabean; October 22nd, 2002 at 07:22 PM.
  4. #18
  5. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Feb 2001
    Location
    USA
    Posts
    830
    Rep Power
    14
    Re 1st paragraph: Those are good points. Have you personally observed those behaviors?
  6. #19
  7. Always Spell Chek
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2002
    Location
    NJ, USA
    Posts
    338
    Rep Power
    13
    Originally posted by dabean
    I don't see how "password{LF}5e6fcb9c648d799cd888502c85db4b84" (IE format) or "password 5e6fcb9c648d799cd888502c85db4b84" (NS6/Moz format) is of any real help to a malicous user considering that if you edit either cookie there is high likelyhood of the browser subsiquently regecting the edit and flushing the cookie from its cache. Oh and IE/NS6+ won't let you add your own cookies.
    You must have a different version than my 6.0.2800.1106. I just removed a cookie, stored it in another directory, then dropped it into another CPU on my network. It worked. So, yes, you can add a cookie (if you couldn't how is the import/export feature supposed to work?)

    It may be very hard to edit a cookie and get it to work, however, any child could get ahold of a cookie, and use it. So as I said before, authenticating based just on cookie content is not a good idea.
    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.
  8. #20
  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 believe that's what he meant by "add". Nonetheless, it seems clear that it would be folly to trust cookies too fully. Let's not forget that anyone could create their own user agent if they so desired. Such a user agent could do whatever the creator wanted with cookies or other things.
  10. #21
  11. No Profile Picture
    Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2001
    Posts
    15
    Rep Power
    0
    By add I was refering to the ablity to manually create a cookie and "add" it to IE or Netscape's cookie database as you would have to in a "man in the middle" style attack. Now disk to disk copying is perfectly possible but as I stated before if the users disk is not secure you have far bigger worries than thieft of cookies, which are well out of the scope of your application.

    Just out of interest how would you propose to build a autologin system that logs the user in automatically without reling on just cookies that is also secure to all possible attacks?
    Hint if your not trusting cookies at any level you can't trust the browser IP address or User Agent String either. See my previous post for the reasoning behind that.

    I must stress at no point did I suggest fully trusting cookies however when handled correctly there is no reason why they are any less secure than forced authentication, to allow a site to remeber a user in fact constant re-entering of passwords annoys users and makes them more likely to tell the browser to remember it for them, IE and NS don't store remembered passwords securely by default either.
    Certainly a good system would force full authentication over SSL when it comes to time to do things that require security e.g. password changes, buying things, updating user "profile" data etc.
    But still be happy to allow a user that has been remebered via a cookie to do insecure things e.g. browse a catalouge, possibly even read email (yahoo and hotmail allow it and I don't see them facing many problems about it).

    It is all in the end down to risk, you should allow users to choose the amount of risk they wish to expose themselves too clearly and simply explaining the risks. Now man in the middle and/or disk attacks are highly unlikely and well configured public terminals should be set to flush all cookies just incase a user forgets to log out of a online app.
  12. #22
  13. Always Spell Chek
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2002
    Location
    NJ, USA
    Posts
    338
    Rep Power
    13
    Originally posted by dabean
    Just out of interest how would you propose to build a autologin system that logs the user in automatically without reling on just cookies that is also secure to all possible attacks?
    Simple, you dont. If you have sensitive information that is worth transferrring over SSL, you should force login or verify the user over SSL, then transer the information over SSL. After that, use a session to determine if the user has been inactive for a certain period, then clean their session out. That is the only way you can semi- ensure that the user is who they say they are (assuming they dont blab their login information to everyone).

    Cookied logins are good for insensitive information sites like forums or download sites. They are not good at all for securing payment information, sensitive account information, etc.

    You can't offer up a secure auto-login solution that will securrly handle both general login and sensitive information in one shot. The only solution that would handle both would be to use an auto login for general information (cookie with min. userid), then when access to sensitive information is required, ask the user to verify their password (send via SSL) , then use sessions to control access to that information. It is still giving you an auto login for the site, but is securing the sensitive informaiton by manually asking the user for information only they would know.

    The above solution may not protect the insensitive information from a cookie hack, but it will require the password. This elevates the game and forces a hacker to otherwise aquire the users password.

    P.S. Login information should not leave the server. Use userid's or other reference variables. Don't give a hacker ammunitition to take your system down.
    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. #23
  15. Contributing User
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Jun 2002
    Location
    Washington, DC
    Posts
    2,692
    Rep Power
    22
    Is it just me, or are the last few replies to this thread not the exact same thing I said in my replies to this thread?

    This thread is starting to drag out and tie up storage space. Seriously guys, can we keep the threads flowing accross the board and not drag out debates in this forum. If you guys like, we can get a nice little debate going on this issue in the lounge.......
    ~ Joe Penn
  16. #24
  17. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Feb 2001
    Location
    USA
    Posts
    830
    Rep Power
    14
    It's just you. Don't feel welcome to interfere with the reasonable self-determination of threads on this board.
  18. #25
  19. Contributing User
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Jun 2002
    Location
    Washington, DC
    Posts
    2,692
    Rep Power
    22
    It's just you. Don't feel welcome to interfere with the reasonable self-determination of threads on this board.
    Indeed I won't. But as a number of people have said in the past, and explicitly to you before, keep the threads to the current technical issues pertaining to the matter at hand, and don't turn a technical thread into a debate.
    ~ Joe Penn
  20. #26
  21. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Feb 2001
    Location
    USA
    Posts
    830
    Rep Power
    14
    As I've been obliged to mention to other individuals in the past, your recent post was off topic, the first such of it's kind to rear it's ugly head in this discussion. There was nothing amiss with this thread, at least not until your off topic post. And, if you'll consent to be reasonable, the discussion may yet resume.
  22. #27
  23. Contributing User
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Jun 2002
    Location
    Washington, DC
    Posts
    2,692
    Rep Power
    22
    This thread is starting to drag out and tie up storage space. Seriously guys, can we keep the threads flowing accross the board and not drag out debates in this forum. If you guys like, we can get a nice little debate going on this issue in the lounge.......
    My post had everything to do with this thread. Your post is actually the first one that had no relevence to the thread itself...
    ~ Joe Penn
  24. #28
  25. Always Spell Chek
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2002
    Location
    NJ, USA
    Posts
    338
    Rep Power
    13
    I think everyone was on point. This is a discussion entitled, "How secure is this?" All of the replies where based either on the question itself, or degrees of cookie, session, or client security.

    If you don't want to hear everyone's opinions, dont ask the question, and dont follow the thread. Posting a thread to tell everyone something is off topic is also off topic, so how is that helping anyone? If you wanted the thread to just move on, you shouldn't have stopped to mention your opinion on the validity of Jpenn's reply. That does not help us answer whether a cookie is secure or not.
    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.
  26. #29
  27. Contributing User
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Jun 2002
    Location
    Washington, DC
    Posts
    2,692
    Rep Power
    22
    Indeed....
    And from a piece from one of your replies maytricks ->
    The only solution that would handle both would be to use an auto login for general information (cookie with min. userid), then when access to sensitive information is required, ask the user to verify their password (send via SSL)
    That is really the only way to go as I mentioned in one of my earlier replies that auto login should only be used for sites where there is no storage of personal information, as our community here.

    --------------///---------------
    ~ Joe Penn
  28. #30
  29. No Profile Picture
    Moderator =(8^(|)
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Feb 2002
    Location
    Sacramento, CA
    Posts
    1,710
    Rep Power
    14
    ooo... this is gonna get ugly.
    -james

IMN logo majestic logo threadwatch logo seochat tools logo