Page 1 of 2 12 LastLast
Results 1 to 40 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,301
    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,075
    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,075
    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,075
    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,075
    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,075
    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,075
    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,765
    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

  26. #26
    Join Date
    Oct 2002
    Location
    Canada
    Posts
    3,100
    Just a note, if you want to be able to revert password to it's original value you can try using real encryption (md5 is hashing not encryption). I find mysql's aes_encrypt and aes_decrypt functions simple and easy to use.

    SELECT @db_secret := 'some_secret_string_you_use_to_encrypt_your_passwords'

    UPDATE users SET password= AES_ENCRYPT('this_is_password',@db_secret) where id=1

    SELECT AES_DECRYPT(password , @db_secret) from users WHERE id=1
    # this will return 'this_is_password'

  27. #27
    Join Date
    Oct 2006
    Posts
    65
    Quote Originally Posted by sasha View Post
    Just a note, if you want to be able to revert password to it's original value you can try using real encryption (md5 is hashing not encryption). I find mysql's aes_encrypt and aes_decrypt functions simple and easy to use.

    SELECT @db_secret := 'some_secret_string_you_use_to_encrypt_your_passwords'

    UPDATE users SET password= AES_ENCRYPT('this_is_password',@db_secret) where id=1

    SELECT AES_DECRYPT(password , @db_secret) from users WHERE id=1
    # this will return 'this_is_password'
    Nice trick this, I'll have to remember this and give it a try

  28. #28
    Join Date
    Oct 2002
    Location
    Canada
    Posts
    3,100
    Quote Originally Posted by mcrilly View Post
    Nice trick this, I'll have to remember this and give it a try
    The problem, and there is always one, is that your data in this case is as secure as your key (db_secret var). So if someone gets hold of that key, they can decrypt all of your passwords.
    To work around that I create "mysql connection file". In that file there is data required to connect to the database (username and password) and the db_secret (key i use for encrypting the data in the database). I encrypt this file using variation of one-time pad algorithm. Yet again this algorithm relies on yet another "secret key" which must not be compromised. I come up with this by doing some hashing of the key which I do not keep secret.

    It goes something like this

    file private.php
    <?php
    $encryption_key = 'some_long_random_string' ;

    $db_username = 'username';
    $db_password = 'password' ;
    $db_secret = 'secret_key';

    my_encrypt ($db_username .'::' . $db_password . '::'. $db_secret) ;

    function my_encrypt($string , $encryption_key) {
    // here i change the key using some hashing and substr() and stuff like that and they use variation of one-time pad and that key to enctypt the $string;
    return $encrypted_string;
    }

    ?>
    This file never gets uploaded to the server, it is just used to generate mysql connection file
    php private.php > .ht_mysql_connection_file

    on server, i upload ioncube encoded file which knows how to decrypt .ht_mysql_connection_file using "public" $encryption_key, connects to the database using data from that file and exports @db_secret variable to the current mysql connection which I can call at any time and use it as argument to AES_ENCRYPT and AES_DECRIPT functions (those calls too are within some classes in ioncube encoded files). It is still possible for someone who obtains full access to server to try to decode the files and data, so there is built in mechanism in the system that will notify me of bad calls to these functions and it will replace mysql connection file with something that is good enough to keep thief busy.

  29. #29
    it's suppose to not to be decode, if you want to check a password for example..
    you need to control the password by encrypt it and compare it to the stored version !

  30. #30
    Join Date
    Sep 2005
    Location
    Canada
    Posts
    645
    Using MD5 or any other common hashing algorithm is very secure. You don't need to worry about salts or collisions.

    A collision would break security in this case if someone guessed someone elses password wrong, and it produced an identical hash. Thats so unlikely its not worth your time coding salts or worrying about other algorithms.

    The other instance would be if the database was stolen, and each password was brute forced to generate an identical hash. But do do that, you don't need a collision at all, just time.

    Salting can theoretically increase the security of the hashed passwords (by making it take more time to brute force them), but only if that salt is kept secret. If they can steal your database why can't they steal your salt, which is probably in your PHP code anyway right?

    Its always funny reading about people complaining that md5 is 'insecure'...they have no idea how hard it is to exploit that theoretical collision even with a variable length message.

    A collision is concerning if you are signing your emails with md5 and you work for the CIA. But on the password field of a php web page login? No need to worry at all about collisions and salts will not increase security.

    No one has shown a collision for sha1 yet, they just theorized its possible.
    VPSVille.com
    Toronto, London, Dallas, Los Angeles
    Quality VPS hosting on Premium bandwidth

  31. #31
    Join Date
    Oct 2001
    Posts
    114
    vpsville: That's not true. Salting each record with a different salt, as a well configured system does, means that for N users, you make a brute force attack N times harder. Otherwise, an attacker can run a dictionary attack against the entire userbase, and while this won't necessarily help an attack gain access to any particular account, it will quickly lead to insecure passwords being compromised.

    Salting the entire system with a static salt is much poorer security, but still prevents dictionary attacks - if you simply MD5 your passwords with no salt at all, an attacker can use a precomputed dictionary of MD5 password hashes - often containing common words, phrases, and so forth - in order to quickly and easily compromise your database.

    In short: salting is extremely important, and you should salt each record separately. Given how trivial salting is, you should do it.

    Take it easy,

    David Berube
    Is your Rails app running slow? I can help. Call me at 603-485-9622.
    http://berubeconsulting.com

  32. #32
    Join Date
    Sep 2005
    Location
    Canada
    Posts
    645
    When implementing security you need to be aware of the threat. Just what attack scenario are you attempting to prevent with a salt? A hacked server resulting in a downloaded database?

    Yes, salting each record with a different SECRET salt does increase the time taken to brute force the database.

    Unfortunately in order to gain any significant benefit from the salt, the algorithm used to generate the salt must be kept secret. If the database and the php files are hacked/stolen, this is a moot point.

    How do you recommend to create unique salts for each record, and keep the salts/algorithm safe from the root user on the server?

    That is a challenging task and I'm curious to hear your take on this.
    Last edited by vpsville; 03-13-2008 at 12:09 PM.
    VPSVille.com
    Toronto, London, Dallas, Los Angeles
    Quality VPS hosting on Premium bandwidth

  33. #33
    Join Date
    Oct 2001
    Posts
    114
    The salt does not have to be kept any more secret than the crypted hash for the password. The point of the salt is not that it's secret, the point is that instead of having to do the dictionary attack once, the attacker needs to do it once *for each user*.

    With no salts at all, the attacker can even reuse a computed list of hashes from a previous attack - such lists can even be downloaded from the various sites on the Internet.

    With a single static salt, the attacker can run a dictionary attack against your particular salt and hash combination, and then he will quickly discover all of the weak passwords in your database. With a per-user salt - even one generated via a weak random number generator - the attacker is forced to attack each user separately - this means that if you have 10,000 users, it's 10,000 times harder to search the entire userspace for weak passwords. (This is, incidentally, why Linux does per-user salts.)

    Because the goal of salting your passwords is to split a simple password operation into a more complex one, it is not generally important that you must have a cryptographically secure salt - as far as I know, it's not generally useful to an attacker to be able to predict salts. Nonetheless, it's probably wise to use a cryptographically strong random number generator.

    Take it easy,

    David Berube
    Is your Rails app running slow? I can help. Call me at 603-485-9622.
    http://berubeconsulting.com

  34. #34
    Join Date
    Sep 2005
    Location
    Canada
    Posts
    645
    You're correct when you say salting will create the need for more hashing to occur. But I don't think this makes weak passwords much harder to find.

    With the salting you suggest an attack would consist of hashing every dictionary word and comparing it to one user. So the dictionary is run through for each user.

    iterations = (words in dictionary * 1 user) * number of users.

    without a salt, each word is hashed and compared to all users.

    iterations = (words in dictionary * number of users).

    As I understand it the number of iterations is identical with or without a salt. So it all comes down to the cost of creating a md5 hash.

    Its true that more hashing will occur with salts, but given the low computational cost of md5, its a moot point. Any weak passwords will be discovered in a few of hours (or seconds) of cracking either way.

    To give you an indication of the computational cost of running through a dictionary attack with md5, in 2003 a 1.6ghz pentium could do 460,000 sha1 hashes per second.

    md5 is faster, and computers are much faster now. How long to go through websters dictionary on a p4 quad core?
    VPSVille.com
    Toronto, London, Dallas, Los Angeles
    Quality VPS hosting on Premium bandwidth

  35. #35
    Join Date
    Oct 2001
    Posts
    114
    Salting passwords is not a guaranteed protection against dictionary attacks; it simply slows down the attack. Generally, the slowest part of a dictionary attack is computing the hashes *by far*: it's much slower to compare two strings than to create a MD5 hash.

    Given that the total effort required to institute a per-user salt is perhaps ten lines of code - and likely less - it's is nonetheless worth the effort.

    Additionally, note that while it may be feasible to find dictionary passwords fairly quickly even with a salt, salting also slows down brute force approaches and expanded dictionary attacks: some dictionary attacks, for example, will find all words followed by a a number, all combinations of two words, and so forth. This approaches become less feasible when proper salting is used.

    Essentially, salting is a low cost way to increase the computational expense of attacking a list of password hashes. It is not a silver bullet, but, given the simplicity of the technique and almost complete lack of cost, it is important.

    Take it easy,

    David Berube
    Is your Rails app running slow? I can help. Call me at 603-485-9622.
    http://berubeconsulting.com

  36. #36
    Join Date
    Sep 2005
    Location
    Canada
    Posts
    645
    Your point is well taken. Random salting does add security with little or no cost. This is in the case of a stolen password database; and you're probably already screwed if that happens. But the cost is low so go for it.

    Since I just researched rainbow tables and ophcrack, here are my suggestions of beefing up your password security:

    1. Use a very strong hash. PHP supports SHA512. This one is great (512bit hash!) because its SLOW to generate and a good rainbow table would take hundreds of gigabytes.
    2. Encourage use of strong(long) passwords.
    3. Salt your passwords with another long hash, unique to the user.
    4. Don't let your server get hacked and your data stolen!
    VPSVille.com
    Toronto, London, Dallas, Los Angeles
    Quality VPS hosting on Premium bandwidth

  37. #37
    Join Date
    Oct 2001
    Posts
    114
    An excellent set of suggestions. IIRC, SHA512 is pretty much where it's at for hashing functions at the moment.

    Password strength is an excellent point; anyone have any good link for an AJAX password strength indicator? I've seen some, but most of them had one or more unfortunate flaws.

    Take it easy,

    David Berube
    Is your Rails app running slow? I can help. Call me at 603-485-9622.
    http://berubeconsulting.com

  38. #38
    Join Date
    Mar 2004
    Posts
    1,301
    I just googled it, the first one is here:
    http://simplythebest.net/scripts/aja..._strength.html

    Not so sure how good it is yet.

  39. #39
    Join Date
    Oct 2004
    Posts
    104
    Wow, some of you guys take simple stuff way too far. md5 is fine for hashing tiny pieces of data like passwords. The method that I use is the typical md5([email protected]) scheme that a lot of others use. Geez the real reason that I hash is because I don't want to see people's passwords.

  40. #40
    Join Date
    Mar 2004
    Posts
    1,301
    Quote Originally Posted by folsom View Post
    Wow, some of you guys take simple stuff way too far. md5 is fine for hashing tiny pieces of data like passwords. The method that I use is the typical md5([email protected]) scheme that a lot of others use. Geez the real reason that I hash is because I don't want to see people's passwords.
    md5 alone is fine only if your data is not so important that when you lose it, you don't care.

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
  •