SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 61
  1. #26
    Keep it simple, stupid! bokehman's Avatar
    Join Date
    Jul 2005
    Posts
    1,935
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by JeffIsGood
    I'm not sure what crypt does by default on Windows - anyone?
    This:
    PHP Code:
    <?php
    for($i 0$i 10$i++){
        
    $pass crypt('password');
        print 
    $pass."<br>";
    }
    ?>
    Printed this:
    PHP Code:
    $1$ZQ0.u10.$ME0q3odOwPSZkNc6dh3GY.
    $
    1$fO4.62..$Y.NetLTzw.zkktO/UodRc.
    $
    1$V0/.493.$/LQoxUoBn43bmyCjf8wu/0
    $1$582.oK0.$GA1kaRWS9/ydRXWSVWJni.
    $
    1$RL/.GJ3.$jbfLHzk4dVdPH4wF3AUyb0
    $1$X...UY4.$4bf0p1onhtPDXanm./DFF.
    $
    1$N91.SG5.$CbYUHCLv/wKB4SQ7lsA1N/
    $
    1$zh5.AR5.$SUbH25xt4mE57HTbsTWbc/
    $
    1$JC0.em1.$bS5FtOZj99bJn8mBamiBB.
    $
    1$P03.sk1.$sAlTWfB.NhiOxhb8eq6kg

  2. #27
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Do not use crypt() any longer!
    Shift to md5() or better to sha1().

  3. #28
    SitePoint Addict
    Join Date
    Jul 2004
    Location
    The Caribbean
    Posts
    267
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by REMIYA
    Do not use crypt() any longer!
    Shift to md5() or better to sha1().
    Could you please provide your reasoning for that statement?

    The problem with those functions is that many people don't know better, so they don't use a salt which makes the encryption much easier to crack.

  4. #29
    SitePoint Addict
    Join Date
    Aug 2002
    Posts
    385
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Can someone tell me if this method for login is secure:

    On login, first, I compare the user's inputted password with the stored database password using one way encryption. If the user decides to remember his login info for the site, I store a hash and his user id as a cookie in his computer. Everytime he logs back in my site, I check to see if that cookie hash matches the one inside my database.

  5. #30
    SitePoint Zealot TheTank's Avatar
    Join Date
    May 2003
    Location
    Houston, TX
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The short of it:
    Anything encrypted, by definition can be decrypted.
    MD5 is Hash, which means it cannot be decrypted.

    The only way to find the original value of a MD5 Hashed value is to use a Dictionary Library and brute force it by running through itereations till it finds a match. So making your password "book" is not recomended becasue if someone finds your md5 hashed password they could crack it. If you make your passwords have numbers and characters then it is basically uncrackable. So therefore I don't see any problem with storing the MD5 Hashed password in a cookie. You can even add a Salt value and secure it even more.

    Perhaps someone would like to disprove this? Or even comment on a disadvantages of it.
    I think sometimes I dream in code.

  6. #31
    SitePoint Guru
    Join Date
    Nov 2004
    Location
    Plano
    Posts
    643
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi everyone, thanks for your replies.

    I'm not sure i completely understand the whole hash, encrypt, salt, etc. thing, but i believe i have an idea of how im going to do this.

    when a user logs in, it will just take the md5() of whatever their password is, then save the md5 in BOTH mysql and the cookie. so then i can just compare the hashes, and i won't have to worry about dealing with 2 different password-scrambler methods...one for cookie and one for mysql.

    i think i am going to use both cookies and sessions, since users may have cookies disabled, and sessions cannot be disabled.

    thanks for you guys' help,
    blayne

  7. #32
    SitePoint Member
    Join Date
    Feb 2002
    Location
    Kuwait
    Posts
    19
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    XtrEM3,

    I can see why you are confused, but your last solution isn't a very good idea either, becuase it means that anyone that can get hold of the password hash stored in the cookie can use it later to login into the same users account without having to know the password.

    So, if one of your users logs into his account from a public computer and forgets to logout, then the only way to ensure that the account is safe is to change the users password.

    This is a chore, not to mention that many users won't even know that they've left their details on some computer, and even if they did, they'd expect their session to expire eventually like it does on most web services.

    There are several solutions to this problem. All of them revolve around the idea of creating a temporary identifying string that will expire after a certain amount of time and that is valid only in a certain context.

    You can derive that string from data already existing in the database and cookies information, then you will get the advantage of not having to store that string in your database. For example, you can send the user cookies containing his username, expiration date of this identifying string and the string itself, which you will construct from concatenating the users hashed password and the expiration date you gave to the client as a cookie and hashing the result of the concatenation. This way you can check the validity of this string with every request by concatenating and hashing again and checking against the hash stored in the users cookies.

    The disadvantage here is that you cannot activly expire a certain string. Expiration happens passivly by passing the expiration date.

    The other way to do this is to generate a completely random string and give it to the user, then store this random string in the server together with the login id and expiration date. This way, you can have more control over the validity of the string. You can activly expire a string by destroying all its records on the server side and it will be useless next time the users tries to use it. This is also much more secure against brute force attacks.

    This is basically what a session hash is. A temporary, randomly generate string given to the user to store information about his visits on the server side without exposing this information or allowing the client to tamper with it.

    This is what I recommend you do.

    I hope I didn't make it even more confusing.

  8. #33
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As much as I know crypt() is a very old, and creates easy-brekable hash.
    Several md5() hashes, have also broken several months ago by a group of researchers, with plenty of PC.
    The most secure hash for now is sha1(), it is not reported to be broken by now.

    I have seen a method using:
    PHP Code:
     
    $hash 
    md5($pass).sha1($pass);
     
    //Any sort of encoding here with admin pass.
    //Make sure its URL compatible at the end.
    $encoded encode($hash,$admin_pass); 

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

    i see your point...i just realized that myself.

    i like the first method you presented...i can see how i can do that and how it would work out

    the second one i am wondering how i would create a completely random string? i can also see how i could code this, but the random string part is throwing me. i would guess i could just generate a random number, then md5 hash it a few times...or sha1() which apparently is safer.

    thanks for all you guy's help, when i first started workin on this script i was fairly lost as to how to go about this, but now i see the light.

    blayne

  10. #35
    Keep it simple, stupid! bokehman's Avatar
    Join Date
    Jul 2005
    Posts
    1,935
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    random string

    PHP Code:
    function r($len 10) {
        
    $e base64_encode(pack("h*"sha1(mt_rand())));
        return 
    substr(strtr($e"+/=""xyz"), 0$len);
    }


    $rand_str r(); // VctY6pL63y... max length 28 chars 

  11. #36
    SitePoint Addict
    Join Date
    Jul 2004
    Location
    The Caribbean
    Posts
    267
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by REMIYA
    As much as I know crypt() is a very old, and creates easy-brekable hash.
    Several md5() hashes, have also broken several months ago by a group of researchers, with plenty of PC.
    The most secure hash for now is sha1(), it is not reported to be broken by now.
    Actually, like I've been saying, crypt() does not necessarily mean that it is using standard UNIX crypt algorithm (DES). From the PHP manual (emphasis is my own)
    crypt() will return an encrypted string using the standard Unix DES-based encryption algorithm or alternative algorithms that may be available on the system.
    ...
    If the salt argument is not provided, one will be randomly generated by PHP each time you call this function.
    Also, sha-1 has also been shown to have collisions (faster than brute force attack), and I believe it was by the same group which did it for md5.
    http://www.schneier.com/blog/archive...nalysis_o.html
    Really it's not much to worry about (at least for now), especially for what most of us here use it for - ie. encrypting passwords. Still, it's best to be aware of it, and to use a salted encryption to prevent certain types of attacks.

    By the way, simply appending the sha1 hash to your md5 hash doesn't help the problem - it just allows a cracker to use either one they find easier to crack.

  12. #37
    SitePoint Zealot TheTank's Avatar
    Join Date
    May 2003
    Location
    Houston, TX
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AhmadH
    I can see why you are confused, but your last solution isn't a very good idea either, becuase it means that anyone that can get hold of the password hash stored in the cookie can use it later to login into the same users account without having to know the password.
    that is incorrect. they do not know the password. they only know the hash... which does them no good. there is no way they can check it against the database because they don't have access to the database except through the login script which requires that they enter the unhashed value.
    I think sometimes I dream in code.

  13. #38
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Watertown
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Have you considered double ROT-13?

  14. #39
    SitePoint Guru
    Join Date
    Nov 2004
    Location
    Plano
    Posts
    643
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by MikeWasHere05
    Have you considered double ROT-13?
    never heard of it

  15. #40
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by MikeWasHere05
    Have you considered double ROT-13?
    That was a joke

  16. #41
    SitePoint Evangelist
    Join Date
    Sep 2004
    Location
    Oregon
    Posts
    445
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Again, as said before. Any encryption can be decrypted either with a complicated Algorithm which if it was known to mankind, everybody and their grandmother would know and it would be all over the internet. However, there are many websites in there so if you type in a line, it saves the line and the encrypted phrase. Therefore, allowing some common words to be decrypted. The problem is, getting to that password. If you personally never echo/mail it, don't use cookies, don't give just anybody access to the MySQL Database - You will be fine. Else, then you need to ensure that persons passwords are complicated. But ofcourse, again as I stated before; unless you are managing funds or something to the extent, then you do not need to be the more secure on earth. Then again, cookies are very unsafe, so if you DEMAND some sort of auto-login feature instead of saving-username feature, then you should look at my post for more secure methods.

  17. #42
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Hong Kong
    Posts
    64
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    How about using SSID instead?

  18. #43
    SitePoint Guru
    Join Date
    Sep 2004
    Posts
    613
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Why not just program your own encryption? It'd be easy enough....

  19. #44
    SitePoint Addict
    Join Date
    Jul 2004
    Location
    The Caribbean
    Posts
    267
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Webnet
    Why not just program your own encryption? It'd be easy enough....
    I hope that's a joke

  20. #45
    SitePoint Enthusiast
    Join Date
    Aug 2003
    Location
    Canada
    Posts
    93
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What I ended up doing is using an MD5 hash of the User's ID and their password. That way, an account login is only good when the password remains the same.

  21. #46
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by epp_b
    What I ended up doing is using an MD5 hash of the User's ID and their password. That way, an account login is only good when the password remains the same.
    What if the user forgets his username and password?

  22. #47
    SitePoint Guru mwolfe's Avatar
    Join Date
    Mar 2005
    Posts
    912
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    you ask them for there email and then you mail them there username and have them reset there password.. well, thats what i would do

  23. #48
    SitePoint Zealot Dorsey's Avatar
    Join Date
    Feb 2004
    Location
    NJ
    Posts
    103
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As has been pointed out here, you don't need two-way encryption, but DO encrypt one-way with something that incorporates a salt, then re-encrypt and compare on return. md5 works well for generating unique GUIDs, but there are newer and better one-way encryption schemes available.

    We store CC numbers (shudder) and use two-way RC4 encryption with a 256 character key that is tightly locked away from prying eyes, and we DO NOT pass even the encrypted value around; it only goes into and out of the DB. I mention this because there are many RC4 implementations you can find in PHP.

  24. #49
    SitePoint Enthusiast
    Join Date
    Aug 2003
    Location
    Canada
    Posts
    93
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What if the user forgets his username and password?
    What if?

    The reason I do this is because if a hacker gets in via a user account, it should be as easy as changing the password of the user he's hacked to kick him out.

    you ask them for there email and then you mail them there username and have them reset there password.. well, thats what i would do
    But...if you don't email them their password, how do they get in to change it?

    The system I have is one in which payments/credit cards are handled, so I don't have an "email me my password" form. Currently -- being a smaller system with only one implementation -- I simply ask them to email me so that I can reset it for them...although, I guess that's not much more secure anyway. I do give them a strong recommendation to change their password.

    I should probably ask a random math question upon initial registration and/or ask a private question, etc. These answers would be required for password recovery, after which an email would be sent containing a link with a random MD5 string in the URL to a script that expires after X number of hours or something...

  25. #50
    SitePoint Addict
    Join Date
    Jul 2004
    Location
    The Caribbean
    Posts
    267
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Forgotten passwords are a tough situation. For 'secure' applications you need to be sure that the user really is who they claim to be. This can be done in a number of ways, but most people tend to use the 'security question' method. ie. when a user signs up you ask them one or more questions only they should know the answer to. Usually it is good in this case to have one question that you supply, and allow them to supply the second question. Then, to reset their password, they need to answer your required question, at that point they are shown their personal question and they need to answer that, at which point you can proceed with a password reset.

    Combine this with some good logging to prevent brute force attacks against the security questions.


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
  •