Hi

i am trying to set a cookie but for obvious reasons i dont want to store the password and i am thinking that by md5() the password it could be the answer to the security issue.

however i have 1 problem

I cant find anywhere tat explains how to use md5()

Can someone point me in the right direction?

I really am a complete newbie.

    [man]md5/man

    However, be aware that md5 is a "hash", not an "encryption", and as such is a one-way operation; you cannot decrypt it.

    In any case, from a security standpoint I do not like the idea of ever storing passwords in any form in a cookie.

      Particularly not md5, last time i read about it md5 hashes could be broken within a 3 or 4 hours.

      Consider sha1, http://uk3.php.net/sha1

      and see examples in the php manual in the above link

      However, this should still not be used in a cookie as NogDog already said!

        Using a salt is probably necessary as well, at the very least. However, I agree: instead of storing a hashed password in the cookie, it would be better to store a session id.

          Yeah, overwhelming sentiment is "no" - don't store it in a cookie.

            Particularly not md5, last time i read about it md5 hashes could be broken within a 3 or 4 hours.

            md5 can be broken faster than several hours. take a look at this tool:

            [MOD: Link removed... even though these are becoming common, we probably shouldn't be posting links to this type of stuff around here...]

              nickadeemus - edit: upon reading the about page, it's not quite a rainbow table implementation. It's just a database of hashes. But now that I've typed it all up anyways, have a look at rainbow tables. 😃

              There's a 66~ GB list that can crack all possible LM hashes, and one that does alpha-numeric-symbol-space out to like 18 characters for NTLM hashes. Interesting stuff.

              edit: also, using a salt can greatly increase the security on MD5 hashes. Using rainbow tables is a good way to get around salts, but a dictionary attack will almost always be foiled by a simple salt. and a strong salt - something using alt codes or other special character sets - will also greatly increase security against rainbow tables.

              $salt = 'über:p@$S.salt';
md5($userpass . $salt);

              So even if a user enters "password" as their password, the hash is actually of:

              passwordüber:p@$S.salt

              Almost no dictionary will have that, and the time-memory trade-off required to generate rainbow tables of that size is so large that only huge community projects can do it - and then you've got 100GB+ tables to use. It's possible, but it ain't easy. 😃

                Horizon88 wrote:

                Almost no dictionary will have that, and the time-memory trade-off required to generate rainbow tables of that size is so large that only huge community projects can do it

                Really? I figured with computing power at the level it is these days, and with the chance of collisions when using MD5 compared to SHA1, it wouldn't be that outrageous of a 'project'. shrug Not that I'm in the business of cracking MD5 hashes and would have any evidence/information.

                Either way, if you're considering hashing passwords for security (which everyone should, I'd think), then you might as well use SHA1 with at least a simple salt (as noted); all of the DB's that I know of support SHA1 as does an extension-less installation of PHP, so it's not limiting your script's portability nor adding that much stress on you as a coder.

                  Really? I figured with computing power at the level it is these days, and with the chance of collisions when using MD5 compared to SHA1, it wouldn't be that outrageous of a 'project'.

                  I think the point is that although it may be feasible for specific salts, faced with many users each having their own salt, such a project becomes impractical.

                  (which everyone should, I'd think)

                  Unless you're one of those devious people who go around collecting username and password combinations from unsuspecting users :o

                  I suggest reading Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes. I do not entirely agree with that article, but it does raise issues to consider.

                  djwideboy, we're talking about this because it is a concern as users do choose weak passwords and reuse them on different websites. If they did not, or if there was no chance at all that our databases will ever be compromised, all this is useless.

                    laserlight wrote:

                    If they did not, or if there was no chance at all that our databases will ever be compromised, all this is useless.

                    No kidding. There's the answer: require the user's to have one capital letter, one number, and one non-alphanumeric character in their password of at least 8 characters. :p

                      LOL looks like i opened a can of worms i was only trying to find the best way of sending a user around my site whilst logged in.

                      I will take a look at the examples and see what is the best but by what ive been told sessions might be a good idea.

                      Thanks lot folks any references to thins i can read up about on this would be ace.

                        Yeah, I always prefer sessions to cookies if it's just for authentication/kicking users around. PHP.net is always a good place to read up 😉

                          Write a Reply...