Page 1 of 2 12 LastLast
Results 1 to 25 of 42
  1. #1

    I still do not understand how to decode md5

    The php.net site sucks when it tries to explain md5 and I asked here but no one seemed to answer my question. I want to store a password in a cookie so I use:

    Code:
    $blah = md5($pass);
    setcookie("pass", $blah);
    How do I make the script read the password from the MD5 jibberish? I want to have an if statement such as

    Code:
    if ( $blah == ADMIN_PASS )
    {
         echo "password works";
    }
    However I do not know how to make it work. Does this only work with databases where I md5 the password into a db table and later check that table with md5 to see if they match?
    Last edited by lexington; 03-07-2008 at 06:26 PM.

  2. #2
    Join Date
    Mar 2004
    Posts
    1,303
    md5 is irreversible; you can't decode that.

    To compare $blah with the value of constant ADMIN_PASS, make sure you need to md5 the constant as well.

  3. #3
    Well I'll be darn thanks it works now. I thought I had tried that already and it didn't work but I guess my page was cached or something.

    Code:
    $blah = md5($pass);
    			setcookie("pass", $blah);
    			
    			if ( $blah == md5(ADMIN_PASS) )
    			{
    				 echo "password works";
    			}
    Works great thanks

  4. #4
    Thanks again I totally understand how md5 works now. I have one final question. Is it ok if I use substr to chop md5 down to about 16 characters for passwords? I think that having 32 chars for every db row would waste space. I know a very little amount but if I can make things more efficent I tend to do so. I doubt the security would be highly compromised if I shorten the limit? Like:

    Code:
    substr(md5($test), 0, 16);
    Thanks

  5. #5
    Join Date
    Oct 2005
    Location
    Six Degrees From You
    Posts
    1,079
    No, MD5 checksums are always 32 characters as far as I am aware.

    Cutting them down to 16 characters will invalidate the checksum.

    Paul

  6. #6
    Join Date
    Dec 2003
    Location
    St. Louis MO
    Posts
    76
    I'm not absolutely positive, but I believe you should be able to do that.
    UD Network Solutions
    http://udns.us

  7. #7
    Cutting them down to 16 characters will invalidate the checksum.
    Meaning that it will not be secure or?

  8. #8
    Join Date
    Oct 2005
    Location
    Six Degrees From You
    Posts
    1,079
    Meaning that it will not be secure or?
    MD5 checksums are not secure anyway.

    Paul

  9. #9
    Join Date
    Oct 2006
    Posts
    65
    Quote Originally Posted by DephNet[Paul] View Post
    MD5 checksums are not secure anyway.

    Paul
    Why not? They're only bruteforcable. Also, what is "secure", exactly?

  10. #10
    Join Date
    Oct 2005
    Location
    Six Degrees From You
    Posts
    1,079
    Quote Originally Posted by Wikipedia
    MD5 was designed by Ron Rivest in 1991 to replace an earlier hash function, MD4. In 1996, a flaw was found with the design of MD5; while it was not a clearly fatal weakness, cryptographers began recommending the use of other algorithms, such as SHA-1 (which has since been found vulnerable itself). In 2004, more serious flaws were discovered making further use of the algorithm for security purposes questionable. In 2007 a group of researchers including Arjen Lenstra described how to create a pair of files that share the same MD5 checksum.
    I think that answers your question.

    Paul

  11. #11
    Join Date
    Oct 2006
    Posts
    65
    Quote Originally Posted by DephNet[Paul] View Post
    I think that answers your question.

    Paul
    No actually, it doesn't, as I asked two questions, which I won't repeat.

  12. #12
    Join Date
    Oct 2005
    Location
    Six Degrees From You
    Posts
    1,079
    Why not?
    See previous answer.

    Also, what is "secure", exactly?
    Something that does not give the same checksum for two, maybe more, different files.

    SHA-1 sums are more secure, still vulnerable tho.

    Paul

  13. #13
    Join Date
    Oct 2006
    Posts
    65
    I guess you've missed my point completely. Thanks for trying anyway.

  14. #14
    Join Date
    Oct 2005
    Location
    Six Degrees From You
    Posts
    1,079
    How about trying to explain your point?

    Paul

  15. #15
    Join Date
    Oct 2006
    Posts
    65
    I'll simply ask the question again, if you don't understand it, then please simply refrain from answering: "What is secure exactly?" - i.e. is anything secure?

  16. #16
    Join Date
    Oct 2005
    Location
    Six Degrees From You
    Posts
    1,079
    is anything secure?
    Yes. A computer that is turned off, unplugged from any network, and burried about 200 feet underground in a concrete block 100 feet square.

    Anything can be secure, depends how much access you want people to have.

    If you think that MD5 hashes are secure then you might want to detail how they are secure.

    Paul

  17. #17
    Join Date
    Oct 2006
    Posts
    65
    I never stated they are secure. Also, given the context of the conversation, your point on a secure system is invalid - the system has to remain useful and secure.

  18. #18
    Join Date
    Oct 2006
    Posts
    76
    Quote Originally Posted by lexington View Post
    Meaning that it will not be secure or?
    The theory - skip below if you aren't interested
    [1] Collisions - When you compute an MD5 hash, what you get is a low probability of collisions - i.e. there is a low probability for a given $a of your finding $b such that

    $a != $b, but md5($a) == md5($b)

    [2] 32 Chars - The 32 chars are basically hexadecimal digits - sixteen 2-digit hexadecimal numbers. So when you chop them down to 16 chars, you get eight 2-digit hexadecimal numbers

    [3] Since you've lost eight of the original 2-digit hexadecimal numbers, it is far easier for md5chopped(a) == md5chopped(b) - only eight hex numbers have to match rather than sixteen. So you've -vastly- increased the probability of a collision.

    [4] Just for info - the probability of a collision has increased by (this is a very rough figure) 256 to the power of eight (each hex number can be 00 to FF, thats 256 possibilities, and there are eight such) - that is 2 to the power of 64. That is roughly 4 billion x 4 billion - the number of bytes on 16 billion 1 GB ram sticks.


    Thats the maths/explanation. Practically speaking -

    [1] Collisions can be generated theoretically / practically - there are papers/demos out on this subject. However it is very doubtful those will be used to break passwords when I last checked[they are much more useful to forge digital signatures]

    [2] Rainbow tables do a much better job of breaking MD5 passwords.

    [3] If you make a cormpromise now and your site / systems remain small, it will not really matter. But if you grow big, then some time in the future, this will snowball into a disaster. And then, the person who works on the code will probably go 'Who the heck is the idiot who wrote this code?'



    Good luck either way
    Last edited by ZeroPing; 03-08-2008 at 05:11 PM. Reason: Needed clarity

  19. #19
    Join Date
    Oct 2006
    Posts
    76
    Quote Originally Posted by mcrilly View Post
    Why not? They're only bruteforcable.
    It is also possible to generate collisions (see my reply above) to a given MD5 hash, under certain conditions. For example, digital signatures can be forged using this technique. Doesn't really apply to password hashes as far as I know, of course.

    Also, what is "secure", exactly?
    Nothing is 'Secure'. But the person you quoted was saying 'X is insecure' - meaning that it has been proven to be insecure.

    To define lack of security is simple - if MD5 is unable to provide the security features it provides (in the above case, being used to digitally sign text in such a fashion that only the owner can sign the text, and anybody can verify the signature as belonging to the owner) - then it is insecure. While you do have a point, so does the other poster.

  20. #20
    Join Date
    Feb 2007
    Posts
    81
    Also look into generating a salted hash, using sha512, for your passwords.

    Code:
    hash('sha512', $password);
    Also, never store a password, hashed or not, in a cookie. Use session_id's to identify users.

  21. #21
    Thanks actually I already used a salt when I first created the password system. I checked it on md5 decrypt sites and they cannot break the password

  22. #22
    Join Date
    Nov 2000
    Location
    Holland
    Posts
    246
    Quote Originally Posted by lexington View Post
    Is it ok if I use substr to chop md5 down to about 16 characters for passwords? I think that having 32 chars for every db row would waste space.;
    As mentioned elsewhere in this topic, md5 are 32 hexidecimal characters. So to save db space, store the md5 string as a 16-byte binary string.

    (in PHP there is no hex2bin afaik, but for workarounds see the comments section of the bin2hex function)
    .

  23. #23
    I still can't decode password when I retrive it from mysql db
    can anyone help

  24. #24
    Join Date
    Sep 2004
    Location
    Flint, Michigan
    Posts
    5,766
    Quote Originally Posted by cilina View Post
    I still can't decode password when I retrive it from mysql db
    can anyone help
    It is impossible to "decode" an MD5 hashed password. Hashing a password with MD5 is a one way process, there's no going back. The only thing you can do is compare the hash to a hash of what a user inputs.

    i.e. User signs up and uses the password: abc123
    Password is stored in the database as: e99a18c428cb38d5f260853678922e03
    When the user attempts to login, you take the text they submit on login, put that through MD5, and then compare it to the hash in your database to see if a proper password was entered.
    Mike from Zoodia.com
    Professional web design and development services.
    In need of a fresh hosting design? See what premade designs we have in stock!
    Web design tips, tricks, and more at MichaelPruitt.com

  25. #25
    Join Date
    Oct 2006
    Posts
    65
    Dollar is spot on. You basically take their input, hash it using the MD5 algo and your salt and then compare that hash to the stored, hashed password in your DB.

    Don't try and decode the MD5 hash

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •