Hello, Can anyone suggest a thorough article/tutorial about how to use cookies to store a username/password? My goal is to let users stay logged in for long periods of time, even when they leave and come back. Cookies would be the best for that right? Not sessions? Thanks! ~alhen
Some may consider it a security risk to send cookies with passwords. I believe sessions would work very well. If you want the sessions to stay around longer, just use session_cache_expire(<seconds>); and if that isn't long enough... ini_set("session.gc_maxlifetime", "<seconds>"); To deal with a large amount of anonymous users, you may want to make a conditional statement that will drop sessions that don't have a username or password in a shorter time.
One of the problems with cookies is that they can be read externally from the browser. This means that any information which is stored within them can in theory be retrieved by whoever uses the client computer. I'd advise that if you are planning on storing the username/password at least encrypt or MD5 the password to restrict the above.
MD5 encryption = not secure (enough). http://md5encryption.com/ But you can do something like this: $word = "1234"; $word2 = md5($word)."h2"; PHP: (This is only a simple trick...) One small change in the encrypted string can make a different result.
I like what WeBuster said. What he used is known as a 'salt', and I work with vBulletin and what it does is that it generates a random 3 character salt consisting of random uppercase or lowercase letters and numbers, and hashes it with that. All the salts are completely random for each user, so you could do it that way. That would make it practically impossible to hack.
no no no, never store a password in a cookie, not hashed, not encrypted, never do it ... An actually usable idea to achieve as you wish would be to rewrite php's session handler, keep the session data in a MySQL or whatever database, when a user logs in you create a new database session, and the only data you need to keep in a cookie is an identifier to select the same session again, your users data is then protected, there's nothing they can do with a session identifier because they cannot access the database ...
These topics might be interesting as well. http://forums.digitalpoint.com/showthread.php?t=369523 http://forums.digitalpoint.com/showthread.php?t=368906 http://forums.digitalpoint.com/showthread.php?t=365334
@WeBuster Wrong. Period. md5 has been a web standard for years as a one-way hash algorithm. There are three ways you can crack it, brute-force all possible combinations of characters (a 10 character password would take over 300,000 years on an average computer), use a dictionary attack, or rainbow tables. (time/memory trade-off, a rainbow table for lowercase alphanumeric keys 1-8 would be about 32gb) With said rainbow table, it would take less than an hour to find the plaintext of an 8-character password of that type, so the only insecurity is the user's poor choice of password. The site you linked appears to store encrypted passwords generated by it, and then refer to that list to decrypt. Try "863B53C9C4A2E5B84D466DAA70275E74" What you may be trying to say is that any slight change in the hash will render it broken. Then, the fault lies on the coder.
@garbageman: The weakness of using an MD5 hash is that it can be attacked quite effectively using a dictionary attack. If you can lay your hands on the MD5 hash of a passwordstring chances are you can find a matching password in your dictionary, which you can use to log in. Salting the hash is effective because even if you find an matching password you can not use it to log in, because you don't know which salt to add.
If someone can use a dictionary attack to get a password that's hashed, then it's pretty much the user's fault for not choosing an effective and secure password.
But that is not a good reason to leave out some extra security. In every case, either with smart users or with stupid users, it is more secure to salt your password-hashes than to hash unsalted. There is no good reason to leave out the salt.
That is not a weakness specific to md5. All hash functions share that problem... user ignorance. I don't see why you have to tag md5 as insecure. By the way, many cracking programs will try variations on a dictionary file. For example, with "john the ripper", you can easily specify to check each dictionary word + a string of some digits. And if, like vBulletin does, the salt is 3 alphanumeric characters, the dictionary would only be 238328 times as large. Not a very large number for powerful computers.
I don't tag MD5 as insecure, but I tag the way it is used as insecure. The point is that if you salt your hashes and someone finds a password by means of a dictionary attack, they still can't use it to log in: normal flow: 'password' --> 'salt'+'password' --> MD5('salt'+'password') If you find a string for which MD5(string) matches a certain hash then you will not be able to log in because the string you found is not 'password' but 'salt+password'. The login flow would be: 'salt+password' --> 'salt'+ 'salt+password' --> MD5('salt'+'salt+password') --> login failure
I never said that, but you specifically tagged md5 as a relatively insecure way to hash passwords. But, even if the password was salted intensely, such as you described, a very powerful computer could get through. Though you would have to think, if someone were to use such a powerful computer, what they're trying to get is probably quite important, which, you would figure, the user knows as well, meaning that they should probably be pretty careful when choosing their passwords. I'm not saying that we shouldn't try every security measure we can, but sometimes it's not our faults. It's like installing 10 locks on a safe, and having only one of them locked. Is that the installer's fault, or just the person/people who are in charge of that safe?