SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 52
  1. #26
    Non-Member
    Join Date
    Oct 2009
    Posts
    1,852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    (say at around 2000 users with 'remember me' set) get people signed in as another user.
    I've heard that md5 collisions occurs not so frequently

  2. #27
    SitePoint Evangelist AlienDev's Avatar
    Join Date
    Feb 2007
    Location
    UK
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Shrapnel_N5 View Post
    I've heard that md5 collisions occurs not so frequently
    There are very frequent.
    Me on StackOverflow | Blog & personal website.

    I mostly use: PHP, Java, JavaScript, Android.

  3. #28
    Non-Member
    Join Date
    Oct 2009
    Posts
    1,852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I wish to see the same test result with sha1
    Something telling me that there is not md5 fault, but testing algorithm...

  4. #29
    SitePoint Evangelist AlienDev's Avatar
    Join Date
    Feb 2007
    Location
    UK
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Shrapnel_N5 View Post
    I wish to see the same test result with sha1
    Something telling me that there is not md5 fault, but testing algorithm...
    The testing algorithm is on the page I linked to in an earlier post.

    md5 is rubbish, accept it.
    Me on StackOverflow | Blog & personal website.

    I mostly use: PHP, Java, JavaScript, Android.

  5. #30
    Non-Member
    Join Date
    Oct 2009
    Posts
    1,852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Don't let this rubbish article to scare you
    Yes, md5 has it's weakness, but it's far away from the numbers you posted.
    this article is not on md5 but on some other matters, so the numbers too
    relax

  6. #31
    SitePoint Evangelist AlienDev's Avatar
    Join Date
    Feb 2007
    Location
    UK
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Shrapnel_N5 View Post
    Don't let this rubbish article to scare you
    Yes, md5 has it's weakness, but it's far away from the numbers you posted.
    this article is not on md5 but on some other matters, so the numbers too
    relax
    If you think this article is rubbish, I guess there isn't much point arguing with you any longer, because it is over your head. The issues raised in the article are extremely real.

    Bye.
    Me on StackOverflow | Blog & personal website.

    I mostly use: PHP, Java, JavaScript, Android.

  7. #32
    Non-Member
    Join Date
    Oct 2009
    Posts
    1,852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Too sad to see another fellow, who is full of right words, but understand none of it

  8. #33
    SitePoint Wizard
    Join Date
    Nov 2005
    Posts
    1,191
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AlienDev View Post
    There are very frequent.
    I checked this out a bit further.

    It turns out that it is extremely unlikely that any md5 ever generated (naturally) since the algorithm was invented is a collision. For a collision to be likely (>50% chance) you would need 2.2 × 10^19 hashes. So, if your site added a billion users per second it would only take 697 years before you would get a collision (on average).

  9. #34
    SitePoint Evangelist AlienDev's Avatar
    Join Date
    Feb 2007
    Location
    UK
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by hash View Post
    I checked this out a bit further.

    It turns out that it is extremely unlikely that any md5 ever generated (naturally) since the algorithm was invented is a collision. For a collision to be likely (>50% chance) you would need 2.2 10^19 hashes. So, if your site added a billion users per second it would only take 697 years before you would get a collision (on average).
    *sigh*

    I'm not going to argue with you 2 on this any more because you clearly aren't taking security seriously enough.

    MD5 is broken - That article has plently of links for further reading.

    If you don't care about security, then shame on you both.
    Me on StackOverflow | Blog & personal website.

    I mostly use: PHP, Java, JavaScript, Android.

  10. #35
    SitePoint Wizard
    Join Date
    Nov 2005
    Posts
    1,191
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think you don't understand what you read. You just see "MD5 is broken" and run around screaming. But maybe I'm wrong, why don't you explain why md5 is broken with respect to storing a session token for a logged in user (it has nothing to do with collision attacks).

  11. #36
    SitePoint Zealot
    Join Date
    Jan 2010
    Posts
    139
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    welp this is what I came up with for my login system with cookies, would appreciate feedback.

    index.php
    PHP Code:
    <?php
    session_start
    ();
    if (!isset(
    $_SESSION['username'])) {
        require_once 
    $_SERVER['DOCUMENT_ROOT'] . '/includes/cookiecheck.php';
    }
    else
        if (isset(
    $_SESSION['username'])) {
            include 
    'main.php';
        }
    ?>
    cookiecheck.php
    PHP Code:
    <?php
    require_once $_SERVER['DOCUMENT_ROOT'] . '/includes/connect.php';
    require_once 
    $_SERVER['DOCUMENT_ROOT'] . '/includes/functions.php';
    if (isset(
    $_COOKIE['c_username']) && isset($_COOKIE['c_password'])) {
        
    $username $_COOKIE['c_username'];
        
    $password $_COOKIE['c_password'];
        
    $check mysqli_query($link"SELECT username, password FROM members WHERE username = '$username' AND password = '$password'");
        
    $result mysqli_num_rows($check);
        if (
    $result != 1)
            {
            include 
    'login.php';
            }
        else
            {
            
    $_SESSION['username'] = $_COOKIE['c_username'];
            
    $_SESSION['password'] = $_COOKIE['c_password'];
            include 
    'main.php';
            }
        }
    else
        include 
    'login.php';
        
    ?>
    login.php
    PHP Code:
    <?php
    if (!isset($_SESSION['username'])) {
    if (isset(
    $_POST['username']))
    {
        require_once 
    $_SERVER['DOCUMENT_ROOT'] . '/includes/connect.php';
        require_once 
    $_SERVER['DOCUMENT_ROOT'] . '/includes/functions.php';
    // safe = mysqli_real_escape_string
        
    $username safe($link$_POST['username']);
        
    $password = ($_POST['password']);
        
    $mix md5($password 'mysalt');
        
    $safemix safe($link$mix);
        
    $check mysqli_query($link"SELECT username, password FROM members WHERE username = '$username' AND password = '$safemix'");
        
    $result mysqli_num_rows($check);
        if (
    $result != 1)
            {
                
    header('Location: /');
                exit();
            }
            else
            {
                
    session_start();
                
    $_SESSION['username'] = $username;
                
    $_SESSION['password'] = $safemix;
                if (
    $_POST['rememberme'] == "on") {
                
    setcookie("c_username"$usernametime()+3600*24*365);
                
    setcookie("c_password"$safemixtime()+3600*24*365);
            }
            
    header('Location: /');
            exit();
            }
        }
        }
    ?>
    I know it's probably silly to use the users password as the password cookie, but I will be changing that to a unique cookie password and storing it in a cookie column in the database. just want to make sure what I have here is ok.. it seems to be working perfectly.

    does it look ok? man I hope I'm on the right track.

  12. #37
    Non-Member
    Join Date
    Oct 2009
    Posts
    1,852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    index.php must be shortened to something like
    PHP Code:
    session_start();
    if (!isset(
    $_SESSION['user_id']) die("Access denied!"); 

  13. #38
    SitePoint Zealot
    Join Date
    Jan 2010
    Posts
    139
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    well for index.php

    if session['username'] is already set, it shows the 'logged in' page (main.php).

    if there is no session['username'] set it runs the script to check if there's cookies set. if there's cookies set it verifies them and sets up the session username/password, otherwise it shows the login form. if there aren't cookies set it shows the login form.

    that's not ok?

  14. #39
    Non-Member
    Join Date
    Oct 2009
    Posts
    1,852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ah you're using rememberme feature.
    Pardon me, I was wrong then

    You don't using safe() for the query - that's totally wrong

    and you're storing plain password in tha cookie, that's wrong too

  15. #40
    SitePoint Zealot
    Join Date
    Jan 2010
    Posts
    139
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    $safemix is the md5+salted password.. do I have to md5 it again before I put it into the cookie?

    also, where else do I need to safe() ? mysqli_query?

  16. #41
    Non-Member
    Join Date
    Oct 2009
    Posts
    1,852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    mysqli_real_escape_string must be used for the every data value which you enclose in quotes in the query.

  17. #42
    SitePoint Zealot
    Join Date
    Jan 2010
    Posts
    139
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    ahh I wasn't using it in cookiecheck.php, fixed that. thanks I don't see that I am putting plain password in the cookie though since it is $safemix

    will test this all now to make sure it works

  18. #43
    SitePoint Zealot
    Join Date
    Jan 2010
    Posts
    139
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    well it seems to be working just fine. FINALLY.

    I am going about this remember-me feature the right way, yes?

    1) upon login, set cookies + session.
    2) upon return to site, check for cookies, if they exist, verify and re-set session.

    that's how you're supposed to do it?

    also, should I maybe set cookies again in 2), so whenever the user returns to the site the cookies expiry date is refreshed? like this:

    PHP Code:
    <?php
    require_once $_SERVER['DOCUMENT_ROOT'] . '/includes/connect.php';
    require_once 
    $_SERVER['DOCUMENT_ROOT'] . '/includes/functions.php';
    if (isset(
    $_COOKIE['c_username']) && isset($_COOKIE['c_password'])) {
        
    $cookie_u $_COOKIE['c_username'];
        
    $cookie_p $_COOKIE['c_password'];
        
    $safe_u safe($link$cookie_u);
        
    $safe_p safe($link$cookie_p);
        
    $check mysqli_query($link"SELECT username, password FROM members WHERE username = '$safe_u' AND password = '$safe_p'");
        
    $result mysqli_num_rows($check);
        if (
    $result != 1)
            {
            include 
    'login.php';
            }
        else
            {
            
    $_SESSION['username'] = $safe_u;
            
    // added the following 2 lines
            
    setcookie("c_username"$usernametime()+3600*24*365"/"".mysite.com");
            
    setcookie("c_password"$safemixtime()+3600*24*365"/"".mysite.com");
            include 
    'main.php';
            }
        }
    else
        include 
    'login.php';
        
    ?>
    will that work to reset the timer on the cookie, or should I not setcookie like that again when the cookies are already there? kinda worried that's gonna mess my scripts up since it's working fine right now. hehe

    also, I am having an issue that http://www.mysite.com/ is working as a session, but if I go to http://mysite.com/ it starts a new session.. what am I doing wrong?

  19. #44
    SitePoint Addict
    Join Date
    Apr 2009
    Posts
    248
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by hash View Post
    I think you don't understand what you read. You just see "MD5 is broken" and run around screaming. But maybe I'm wrong, why don't you explain why md5 is broken with respect to storing a session token for a logged in user (it has nothing to do with collision attacks).
    Why would you use MD5, though? It's been effectively broken for 15 years, now. Sure, it's not yet completely trivial to collide an arbitrary hash (takes a couple hours on modern hardware), but give it a few years. Do you want to have to explain to your clients why you need to go back and update their site due to a security vulnerability which was discovered a decade and a half before your created their site?

    To the OP: change your MD5 hash to something a bit more secure (SHA-256 at a minimum, or my preference: whirlpool). Additionally, you should be randomly generating a salt and appending that to the password, then storing the salt in the database.

    Also, you should be hashing the password a few thousand times for additional security (see http://en.wikipedia.org/wiki/Key_strengthening for details).

    Ultimately, what this really means is that if you're a bit newish to PHP, or uncomfortable with the security aspects, you probably shouldn't write your own login function. There are far too many things you could be doing wrong.

  20. #45
    Non-Member
    Join Date
    Oct 2009
    Posts
    1,852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    But how can one become seasoned to PHP without own experience?

  21. #46
    SitePoint Wizard
    Join Date
    Nov 2005
    Posts
    1,191
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by SituationSoap View Post
    Why would you use MD5, though? It's been effectively broken for 15 years, now. Sure, it's not yet completely trivial to collide an arbitrary hash (takes a couple hours on modern hardware), but give it a few years. Do you want to have to explain to your clients why you need to go back and update their site due to a security vulnerability which was discovered a decade and a half before your created their site?
    Even if it becomes trivial to generate a collision this is not the same as generating a collision for a specific hash. But even if that became trivial it does not apply in this case.

    All you are doing here is storing a random 128 bit hash in the cookie and checking it against your db record. Unless the attacker knows how you generated this and can reproduce it there is no problem. You can't brute force this in any remotely feasible time, so md5ing a bunch of random data to generate a key is fine.

    If I'm wrong please correct me. But tell me why instead of "md5 is broken".

  22. #47
    SitePoint Addict
    Join Date
    Apr 2009
    Posts
    248
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Shrapnel_N5 View Post
    But how can one become seasoned to PHP without own experience?
    There's nothing wrong with gaining experience. There is something wrong with attempting to pass off a production-level authentication mechanism as secure when it's very obviously not.

    I'm not saying that the OP is attempting to commit fraud, but security is hard. You don't make the first thing that you do while learning math Integral Calculus. Why make one of the first things you do in PHP writing auth systems? Why not let people with more experience handle that one for your first projects?

    Quote Originally Posted by hash View Post
    Even if it becomes trivial to generate a collision this is not the same as generating a collision for a specific hash. But even if that became trivial it does not apply in this case.

    All you are doing here is storing a random 128 bit hash in the cookie and checking it against your db record. Unless the attacker knows how you generated this and can reproduce it there is no problem. You can't brute force this in any remotely feasible time, so md5ing a bunch of random data to generate a key is fine.

    If I'm wrong please correct me. But tell me why instead of "md5 is broken".
    The problem with your post is that it has been possible to trivially find a collision for an arbitrary message using MD5 for five years now (see http://cryptography.hyperlink.cz/md5/MD5_collisions.pdf -- that group was able to find a collision for an arbitrary MD5 hash in eight hours using a 1.6GHz processor...in 2005). There are two places as I understand it, that our OP is going to use a hash: the first is in the password storage, and the second is in a "Remember me" function.

    The "Remember" function doesn't need a hash. There's no reason to use a hash: just use a sufficiently lengthy randomly generated key which you store in the cookie. Because the key is random, and there's no actual meaning to it (it's useless outside of that website), there's no reason to hash it. In this case hashing (due to the possibility of collisions in the domain) are actually less secure than simply using the key.

    Passwords on the other hand, are secrets. They (by design) should only be known by the person who created the password. As such, well-designed systems are put together to be able to check the user's password without actually knowing the password in a human-readable format for more than the time it takes for the computer to transform it. This is why we use hashing -- it's designed to provide one-way encryption and "fingerprint" the object in question.

    Salting the password and using multiple rounds of encryption (with the password appended) goes a long way to make things more secure, but MD5 has been known to be insecure since 1995. It may not have been insecure for all practical applications for that whole time, but implementing another algorithm is trivial. The difference between implementing Whirlpool and implementing MD5 in your system is six characters. The difference between compromising MD5 and compromising Whirlpool is a couple of thousand years. Why wouldn't you use the slower, more secure, proven algorithm?

  23. #48
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    I see both sides of the story here - MD5 is technically "broken" because in a list of strings and their hashes, every so often you'll find a duplicate hash.

    However, this list needs to be huge. I'm talking massive - 2000 is a slight underestimate. Raise it to the nth power and you'd be closer . The MAJOR thing here is that if someone has access to your database to see this MD5 in the first place, you have A LOT more problems than them finding your site's Admin password.

    The recommendation would be to salt the password and then encrypt it with an algorithm - SHA, MD5, whirlpool - the choice is yours. However, you cannot make an informed decision until you look at, and understand, the algorithms behind each and know the weaknesses. If you have that kind of understanding of each, and not just take in what you've heard from not-so-explanitory articles, you will find out that no algorithm is perfect.

    But guys, can we please keep this thread on topic? Sure, encryption is relevant to login systems, but arguing over what encryption to use is only going to confuse the original poster. I'm going to see if we can get this thread split into the OP's thread and the encryption thread. Until then, please keep on track.

    Note also that if you want a good debate about this, both sides need good backup data so we can have a reliable thread summary. Half of the debate so far has resulted in pure insult to either side which contributes nothing to these forums. The winner of an argument is the one who supplies real-life information, backs it up (the source code behind testing would be useful) and explains the results - not the person who resorts to derogatory comments to others.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  24. #49
    SitePoint Addict
    Join Date
    Apr 2009
    Posts
    248
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Jake -- I don't think the majority of your post there applies specifically to me, but I think the OP has already been given the advice necessary: "Don't do it yourself". There are a number of options out there for authentication, PEAR has a couple which look promising (http://pear.php.net/search.php?q=aut...on&in=packages), or you could do a quick google search and find a great deal more.

    The point I've been repeatedly trying to stress to the OP is that security is hard, and by trying to do things yourself, you just end up being another in the long line of PHP applications which manage to do something with Authentication wrong. It's telling that in Windows 2000, even Microsoft moved away from an in-house Authentication framework, adopting Kerberos. If you don't know, and you're not willing to put in the weeks it takes to research how to do this effectively, you just shouldn't do it. Let someone who has already done that legwork for you, and developed an extensible authentication framework in your stead, handle the heavy lifting.

  25. #50
    SitePoint Wizard
    Join Date
    Nov 2005
    Posts
    1,191
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by SituationSoap View Post
    The problem with your post is that it has been possible to trivially find a collision for an arbitrary message using MD5 for five years now (see http://cryptography.hyperlink.cz/md5/MD5_collisions.pdf -- that group was able to find a collision for an arbitrary MD5 hash in eight hours using a 1.6GHz processor...in 2005). There are two places as I understand it, that our OP is going to use a hash: the first is in the password storage, and the second is in a "Remember me" function.
    That's not a problem with the post, it's the whole point. The message is not known, so it doesn't matter how easy it is to generate a collision for a known message.

    Neither the token or the password are vulnerable to collision attacks. Collision attacks are where one (malicious) message is able to pass itself off as another (trusted) message via an identical hash. In this case the attacker does not know the message or it's hash.


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
  •