SitePoint Sponsor

User Tag List

Results 1 to 10 of 10
  1. #1
    SitePoint Addict
    Join Date
    Jan 2004
    Location
    New York
    Posts
    254
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Lets talk about MD5 security schemes

    Thought this might be interesting. I took a look at http://membres.lycos.fr/mdcrack/ and read something that caught my attention:

    Today many applications (most of them are network oriented) use MD5 for authentication purpose avoiding any plain text password on the wire.

    In such a case, clients typically send a password hash over the network to the server wich in turn, make its own client password hash to compare the two hashes. If they match together, the server considere the client know the good password and the authentication process is ended althought the server may be totally wrong! MD5 can not theoricaly be reversed that is to say nobody can guess the original text from its hash (even with little strings like passwords) but since the number of resulting hash is fixed (2^128), many strings will give the same hash.
    And it is true. The program that the site provides is designed to find collisions, not actual passwords. Meaning in the infinitude of passwords and binary files, the hash result will always be limited to 32 characters, and each character limited to 16 possible um, characters (a-f, 0-9). In other words, there is no string that will have a unique hash.

    Let me describe how md5 comparison security can be compromised. If a site sends password 'abc' which gives an md5 hash of '12345' and uses it to compare for verification, then the security hole here is that any string that will result in an md5 hash of '12345' will get you logged in! You do not need to use the password 'abc' specifically. A packet sniffer finds the hash value (assuming you took the precaution to use the javascript md5 script) and finds any string that will find the same exact hash. If the string 'xyz' gives you the hash '12345' then you can log in with that (remember it is comparing hash values, not the actual password).

    Even though the possibilities of a collision is rare (16^32 or 2^128 however you want to look at it, its a freakin huge number), there is a flaw. And I was wondering if anyone here would bring up anything to make this more secure?

  2. #2
    SitePoint Wizard megamanXplosion's Avatar
    Join Date
    Jan 2004
    Location
    Kentucky, USA
    Posts
    1,099
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Even if MD5 were 1024 characters, people would still call this a security issue. Well, 32 characters are NOT a security issue if you take a little extra effort to ensure that nobody gets duplicate MD5 hashes. All you have to do is generate the hash, SELECT * FROM account WHERE hash='hash', if there are returned results then create another md5, keep going from there. Problem solved.

  3. #3
    Non-Member Icheb's Avatar
    Join Date
    Mar 2003
    Location
    Germany
    Posts
    1,474
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If you generate the md5 along with a salt, the hacker would have to brute force the salt as well, which adds more security.

  4. #4
    SitePoint Addict
    Join Date
    Jan 2004
    Location
    New York
    Posts
    254
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    How would I add the salt? Wouldn't the packet sniffer read the javascript, seeing that it adds the salt as well?

  5. #5
    Free your mind Toly's Avatar
    Join Date
    Sep 2001
    Location
    Panama
    Posts
    2,181
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Atealtha
    How would I add the salt? Wouldn't the packet sniffer read the javascript, seeing that it adds the salt as well?
    Check out this thread: http://www.sitepoint.com/forums/show...highlight=salt especially post #21.
    Community Guidelines | Community FAQ

    "He that is kind is free, though he is a slave;
    he that is evil is a slave, though he be a king." - St. Augustine

  6. #6
    SitePoint Addict
    Join Date
    Jan 2004
    Location
    New York
    Posts
    254
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm not worried about password storage, but actual security of the authentication process over http. Since serverside, whatever hash/password I send will go through the same processing (sha(md5($hash . $salt))) etc., it still leaves the hash being sent, open and vulnerable.

  7. #7
    ********* Genius Mike's Avatar
    Join Date
    Apr 2001
    Location
    Canada
    Posts
    5,458
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Use https if you're worried.
    Mike
    It's not who I am underneath, but what I do that defines me.

  8. #8
    SitePoint Wizard megamanXplosion's Avatar
    Join Date
    Jan 2004
    Location
    Kentucky, USA
    Posts
    1,099
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yep. SSL is a great thing indeed (hmmm, why is THAT the 'nod' smiley? )

  9. #9
    SitePoint Addict
    Join Date
    Jan 2004
    Location
    New York
    Posts
    254
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Is there any method to increase security without ssl?

  10. #10
    SitePoint Member
    Join Date
    Apr 2004
    Location
    Delta Quadrant
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sending two hashes - one as a hash of the actual password and one as reversed password?
    try to collision that if you dare.


    pass: "abc" - hash: fdskfhk
    reverse pass: "cba" - hash: dkhkdfdd

    now you just send both hashes combined..."fdskfhkdkhkdfdd"
    the server just passes (after ver) the combined hashes to the sql server:

    select * from <table> where hash=hash

    where the table structure is sth. like that:

    [id] [hash] [username]
    1 fdskfhkdkhkdfdd jocker


    as the actual pass and reversed one have different hashes, it would be extremely difficult (at least in my book, correct me if i'm wrong) to find a collision password (if not impossible).
    Also, the packet sniffer wouldn't recognize the sent value as hash (as it's two times too long) - at least without additional programming - so it would hopefully just ignore the sent data.


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
  •