SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 61
  1. #1
    SitePoint Guru
    Join Date
    Nov 2004
    Location
    Plano
    Posts
    643
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    encrypting password

    hi,

    i'm making a script which requires a login. i realize it is good to use md5() to encrypt the password when it is entered into the db, but what about when the password is stored in cookies?

    i'm sure storing password=mypassword is not very secure. what kind of encryption should i use to store the password in the cookie. this has to be 2 way encryption because i need to decode the value found in the cookie, then test it against the encrypted value in the database.

    thanks

  2. #2
    SitePoint Guru
    Join Date
    Sep 2004
    Posts
    613
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    MD5 is 1-way encryption.

  3. #3
    SitePoint Guru
    Join Date
    Nov 2004
    Location
    Plano
    Posts
    643
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ty webnet,

    i realize md5 is 1-way encryption. that is why i am posting this question becuase i am not aware of a 2-way encryption method safe for storing password in COOKIES.

    from what i've gathered so far...
    md5 encryption is 1 way, so it is good for storing in the db. BUT i need to be able to retreive the real password, then validate it against the value in the db.

    is it necessary to encode the password when stored in the cookies?

  4. #4
    SitePoint Addict
    Join Date
    Jul 2004
    Location
    The Caribbean
    Posts
    267
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes - if you are storing the password in a cookie, then you should encrypt it. You may want to see the mcrypt module for some two way encryptions. Personally, I would strongly suggest that you don't store any sensitive information in cookies - perhaps you need to rethink your authentication script a bit more? Have you looked at PEAR::Auth ( http://pear.php.net )?

  5. #5
    SitePoint Guru
    Join Date
    Nov 2004
    Location
    Plano
    Posts
    643
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    thank you jeff,

    i will look into mcrypt. but where would i store the information if i dont store it in cookies?

    i only chose cookies becuase i figured it was my only option

  6. #6
    SitePoint Wizard HarryR's Avatar
    Join Date
    Dec 2004
    Location
    London, UK
    Posts
    1,376
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,
    If you want a quick and relatively secure method to store a hashed password in a cookie (without giving away the hashed password in the db) then you should consider creating a new hash of the already hashed password and a piece of information unique to the client.

    By using this method you can re-authenticate a user against a hashed password without ever knowning the password, but in a manner that will not give away anything that's supposed to be secret.

    For example:
    $hashed_password . $client_useragent . $last_login_time . $username

    Then store the username and last login time in cookies in the clients browser, and as long as nobody gets the cookie it'self you should be ok for security.

    Hope you get the jist of the idea, as it's just my 0.02p

  7. #7
    SitePoint Addict
    Join Date
    Jul 2004
    Location
    The Caribbean
    Posts
    267
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You can use PHP's server side sessions. Then, the only thing stored in the cookie sent to the user is a session id.

    http://www.php.net/session (and there are many tutorials online). Basically, in the newer versions of PHP, after doing 'session_start()', you can store things in the $_SESSION[] array, ie. $_SESSION['username'] = bob. Then, on another page, do 'session_start()' at the top again, and then you can access the $_SESSION['username'] variable.

  8. #8
    SitePoint Guru
    Join Date
    Nov 2004
    Location
    Plano
    Posts
    643
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    harryR,

    by checking the pw based on last login date, wouldn't that be less secure, because the login time is easier to guess than an actual password? im sorry, i dont think i understand exactly

    jeff,

    so since the session is unique, would that mean i dont need to authenticate and test against the db on every page load?...can i assume sessions cannot be fiddled with and that if i do
    Code:
    SELECT * FROM users WHERE username='" . $_SESSION['username'] . "'
    that i'll be safe?

  9. #9
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Posts
    39
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Why not actually answer his question?
    There is a 2 way encryption ive used before but as any 2 way encryption its not that secure but
    PHP Code:
    $enc base64_encode($my_password);
    $dec base64_decode($my_password);

    echo 
    "Encrypted:<br> " $enc "<br> Decrypted: <br>" $dec "; 
    Hoped that helped.

  10. #10
    SitePoint Guru
    Join Date
    Nov 2004
    Location
    Plano
    Posts
    643
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    thanks thefallen,

    but anyone can decode that using a php script, rite?, i think i need a bit more security than that.

  11. #11
    SitePoint Addict
    Join Date
    Jul 2004
    Location
    The Caribbean
    Posts
    267
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by XtrEM3
    so since the session is unique, would that mean i dont need to authenticate and test against the db on every page load?...can i assume sessions cannot be fiddled with and that if i do
    Code:
    SELECT * FROM users WHERE username='" . $_SESSION['username'] . "'
    that i'll be safe?
    That's correct - since the session data is stored on the server, the client is unable to modify it. The 'username' idea was just an example of using sessions. You could even set something like
    Code:
    $_SESSION['logged_in'] = true;
    And then just check that on each page (instead of doing a db query each time).

  12. #12
    SitePoint Evangelist
    Join Date
    Sep 2004
    Location
    Oregon
    Posts
    445
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    First of all. If a password can be decryped, then it is identicle to a password which is unencrypted. Therefore, MD5 is the best way out there. By having a 2-way encryption, it just stops the complete "n00bs" but still, anybody with google or webspace could get the password. It all depends on your interest in usage of a password. If you are like Ebay, Paypal, Moneybookers etc. then obviously you have to be very secure and whatnot. However, if you are something which nobody is paying for, free services, for example a pet-site, then theres no reason to be super-secure.

    Personally, if you are worried about security and the if($password != $_COOKIE['pass']){ startles you, then you should look into secondary methods. Possibly if you are using MySQL storing their IP Address inside a Database with a unique "code" which is stored inside the database. If in the situation where they check the box to safe the password, then the unique code, current IP address, and username is added as a new row, and then can eaisly be rechecked while the code is saved inside the cookie. Simply do a query and count the rows, if there is 1 valid row with that code, then they are logged in with the user affiliated with said code. Ofcourse, this can be gotten around, but in reality unless they are aware the structure of you database (Which is very idotic if you want any security) then they wouldn't know this.

    Good Luck, but leaving you off, I still use the if($pass = $cookie), well actually technically I query to find rows with said user password, and count them, if its 1 they are logged in, else prompted to login. I also usually depending on the exact security and check IP addresses, and if they are diffrent, then they will have to login. You will notice many large established adult websites (like, adult targeted, not porn...) then they usually will only allow you to be able to login with the saved data if you are on a static IP, obviously for security.

    None of us are IT certified and trained, however most security is obvious. If you are dealing with an account worth actual money, then obviously seek advice from somebody trained in this feild.

  13. #13
    SitePoint Addict
    Join Date
    Jul 2004
    Location
    The Caribbean
    Posts
    267
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Actually md5 is not the best out there. Especially calling md5('password'), since that will not use a salt. It is just as easy to get the password from a salt-less md5 hash (google for rainbow tables, you'll see what I mean) as for most two way encryptions people would use. But aside from that, even if someone ends up with a password hash, it's only a matter of time before it gets cracked - especially if you are not actively enforcing strong passwords on your site.

  14. #14
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If you need a simple 2 way encryption you may try the XOR encryption. It's implementation is available at http://itlibrary.remiya.com/index.php?uid=0_1_1_0.

    Wrap its result in base64_encode like this.
    PHP Code:
    $enc base64_encode(XOREncode::encode($user_password,$my_password)); 
    $dec base64_decode(XOREncode::decode($enc,$my_password));
     
    echo 
    "Encrypted:<br> " $enc "<br> Decrypted: <br>" $dec "; 
    Hope that helps


  15. #15
    One website at a time mmj's Avatar
    Join Date
    Feb 2001
    Location
    Melbourne Australia
    Posts
    6,282
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    In my opinion you should not store the password or an encrypted form of the password in a cookie at all. If anything, store an unrelated, hard-to-guess unique ID in the cookie and link that ID with the user's account ID in a table. Ideally, change that ID regularly to minimise the risk of account hijacking.
    [mmj] My magic jigsaw
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    The Bit Depth Blog Twitter Contact me
    Neon Javascript Framework Jokes Android stuff

  16. #16
    SitePoint Evangelist gollux's Avatar
    Join Date
    Feb 2005
    Location
    Oregon, USA
    Posts
    414
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by thefallen
    Why not actually answer his question?
    There is a 2 way encryption ive used before but as any 2 way encryption its not that secure but
    PHP Code:
    $enc base64_encode($my_password);
    $dec base64_decode($my_password);

    echo 
    "Encrypted:<br> " $enc "<br> Decrypted: <br>" $dec "; 
    Hoped that helped.
    There is a major difference between encoding and encrypting.

    Encrypting completely renders something completely unreadable unless you know a passkey to use in decrypting it.

    Base 64 encoding is not encryption and is not meant to do anything except render control characters and other binary as printable ascii so an encoded message can be emailed. It is not meant to render anything unreadable and is not really a valid method as it will be the first thing anyone would try in a cracking attempt along with ROT-13 and any of the other common ecoding methods.
    Released under the Fiasco Labs Digital Damnation Copywright,
    it's yours to make whatever the 7734 you want with it.

    (c) 2005 Fiasco Labs All Wrongs Reserved

  17. #17
    SitePoint Enthusiast
    Join Date
    Aug 2003
    Location
    Canada
    Posts
    93
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't think passwords should ever be stored in cookies - encrypted or not. I just store the user ID (number) of the user who is logged in. Besides, it's not like someone can go in and just create a cookie manually to be recognized by a website.

    EDIT: Ouch! I just discovered that you can just create a cookie by copying it...isn't this a huge security issue??

  18. #18
    One website at a time mmj's Avatar
    Join Date
    Feb 2001
    Location
    Melbourne Australia
    Posts
    6,282
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by epp_b
    I don't think passwords should ever be stored in cookies - encrypted or not. I just store the user ID (number) of the user who is logged in. Besides, it's not like someone can go in and just create a cookie manually to be recognized by a website.
    Actually, that's relatively easy. Browsers store their cookies in text files.

    By the way, what's your website address?

    j/k
    [mmj] My magic jigsaw
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    The Bit Depth Blog Twitter Contact me
    Neon Javascript Framework Jokes Android stuff

  19. #19
    SitePoint Enthusiast
    Join Date
    Aug 2003
    Location
    Canada
    Posts
    93
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nice try Oh, are you being serious?

    I have a system that remembers users indefinately (well, OK, for a very long time) by storing a cookie with the user's ID (number). By knowing the cookie domain, path, name, and value; a malicious geek could get in. The first two are easy to get at, the last two would take some guessing (or access to another computer)...but it is possible

    What if I created an encrypted variable based on the user's IP for the cookie name? I guess this wouldn't work idealy for dial-up users, but broadband users would be able to keep it for a few weeks. Have any better ideas? (Sorry, XtrEM3, for hijacking your thread here...)

  20. #20
    One website at a time mmj's Avatar
    Join Date
    Feb 2001
    Location
    Melbourne Australia
    Posts
    6,282
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by epp_b
    What if I created an encrypted variable based on the user's IP for the cookie name? I guess this wouldn't work idealy for dial-up users, but broadband users would be able to keep it for a few weeks. Have any better ideas? (Sorry, XtrEM3, for hijacking your thread here...)
    I've done this before. It is doable. What you are saying is that you would combine the user's ID and IP with a secret hash, and get a hash of the combined value.

    The thing about any type of 'remember me' feature that uses cookies is that the more secure you try and make it, the less convenient it is. If it is tied to an IP address then it won't be remembered when the user switches IPs. You could tie it to a 256 address range (ie, 203.44.221.*) perhaps.

    So you need to consider what you are protecting. Any decent CMS will have a 'remember me' feature that uses cookies, but will also require a user to re-authenticate themself whenever they do something important like access an administration control panel.

    vBulletin uses a cookie called bbpassword that contains a hash of the user's password combined with some secret hash. It's a good enough solution I think, as it means that firstly there is no way of getting the original password (or the plain MD5 of it) with the hash, and if you change passwords then the hash changes too. Notice that a hash is not encryption - there is no way of 'decrypting' a hash, and combining the password with a secret hash to create a new hash means that you can't go from that hash to the plain MD5 hash as stored in the DB.
    [mmj] My magic jigsaw
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    The Bit Depth Blog Twitter Contact me
    Neon Javascript Framework Jokes Android stuff

  21. #21
    Non-Member
    Join Date
    Jul 2005
    Posts
    606
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Epp, it's possible to fake cookie! Small oversight there!

    What I do is every time someone logs onto the site, create a random, MD5 hashed user identification number which is then stored in the cookie. This way I do not need to store any sensitive information client side, and someone wouldn't be able to fake a cookie because they'd be no way of getting that unique id number unless they hacked the database. and if someone can do that, well, you are in trouble no matter how well thought out your authentication is lol.

    Actually thinking about this I've just uncovered one potential, although minor flaw in my system. The unique user id is stored in the session data, so someone could sniff that and then create a cookie to log into the persons account. You see? Even when you think your auth is inpenetrable you uncover improvements

  22. #22
    Keep it simple, stupid! bokehman's Avatar
    Join Date
    Jul 2005
    Posts
    1,935
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You dont need two way encryption. When someone chooses a password encrypt it and store it in MySQL. Lets us md5() for example:
    PHP Code:
    md5($_POST['password']);// now save it in MySQL 
    When they return and log in get the encryted password from MySQL and do a comparison:
    PHP Code:
    if(md5($_POST['password']) == $mysql_password){
       
    //password good
    }else{
       
    // password bad

    Notice that no 2 way encryption was needed.

  23. #23
    SitePoint Zealot krt's Avatar
    Join Date
    Sep 2005
    Location
    Australia
    Posts
    114
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, and if you mjst store it in a cookie, use a salt with the hashed password.
    And never identify the user from a cookie without the password, someone above suggested saving the username to a cookie and identifying user from that, now what if someone easily changes that username to "anothermember" and now they are logged in as "anothermember", uhoh!
    Just remember that you can do these simply from the address bar
    Type into the address bar:
    Code:
    javascript:alert(document.cookie);
    And you see some data, now on vBulletin, this is secure so changing the values will only result in you being logged out but nevertheless you can do this:
    Code:
    javascript:void(document.cookie='username=joe');
    That will add a field and value pair into the cookie and if you alert the cookie again, you will see this new value again.

  24. #24
    SitePoint Addict
    Join Date
    Jul 2004
    Location
    The Caribbean
    Posts
    267
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    By the way, if you're wondering how to use a salt in your password - on a Linux box, it is most likely that the php crypt function will default to using salted md5, so:
    Code:
    $pass = crypt('password');
    Is a quick, easy way to get salted md5 encryption.

    On OS X, it gives me standard DES (at least it is salted unlike the default md5() behavior). I'm not sure what crypt does by default on Windows - anyone?

  25. #25
    SitePoint Addict mx2k's Avatar
    Join Date
    Jan 2005
    Posts
    256
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    its more like you're doing hashing vs encryption/decryption thread


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
  •