how do you hash a word

[djr33]

If someone steals your cookie (eg, from an unsecure wifi network) then they get unlimited access, rather than just the session. That's the downside.

And sessions do use cookies, but they're a little more secure. Instead of having a direct "key" to the website (a cookie) the session is an indirect way with a cookie that just gives access to the session while that particular session exists. It's like a plastic key for getting into your car if you lock yourself out; it won't work for long, but it is fine temporarily. With the cookie method (without an expiration) it's like giving the thief a metal key that will work forever.

It's totally your choice. In fact, a lot of scripts don't use sessions (I'm not sure why not), such as forum software. But generally I'd recommend sessions. They're also easy.

And by the way, you CAN try to extend sessions if you want. You can set the session cookie for a longer expiration date, and generally that keeps the session going just as long as the cookie. (Sometimes your server might delete old session logs, but I've never been bothered by that.)

[james438]

I understand the risk of creating a duplicate cookie. That sounds easy enough to do, but even if the person had the correct cookie on my website they would still need the correct $_SERVER[REMOTE_ADDR] value for the cookie to be considered valid. Both must be correct in order to gain access.

Here is an example of one of my passwords: secure7➈
I know listing my password is a little off topic, but I wanted to show that I like to use more than just letters and numbers.

[djr33]

That's a strong password, but the strength of a password only matters if there is no other way around it-- if stealing the cookie is enough then it won't matter what the password is.

If you are using the IP within the validation, that's very strong. The only (reasonable) way that would not be secure is if someone is using the same IP you are, such as at a public wifi location or internet cafe (where you're both behind the same router).


By the way, here are some more thoughts on why cookies are potentially problematic:
--Cookies are stored on the client's computer so they can be manipulated, such as extending the expiration date. The server keeps no record of cookies and just checks what the client claims they have, so if their cookie is modified to be extended forever, that will give them access forever.
--Cookies will relate directly to access. If sessions are used then they are an intermediate step in access so that:
1) the sessions can expire on the server and just extending the cookie's expiration won't extend the session's validity.
2) The session cookie will be random each time. A cookie that gives access directly will be the same always. So if a brute force hacking method is used, then the session method is much more secure because rather than giving the hacker infinite time to guess what cookie might work (and just try various combinations), with sessions the hacker would need to guess the right combination for the cookie within the time that that session is active on the server-- much less likely.

Remember that with any brute force attack it's possible to limit the number of login attempts for a login form, but if that login attempt is done by a cookie (claiming they are already logged in) and there is no secondary validation of the actual login process (eg, a session log), then it will be much more difficult to monitor this and deny excessive requests (eg, 25 wrong password attempts).


Finally, this is a very important point: if a brute force method is used and you do not have server log validation of some sort (eg, sessions or a database entry) and the cookie is generated by validating the IP address and the password together (eg, as a hash), then it is completely possible that given enough time the hacker can find the right combination. It will be the cookie that gives them access from THEIR IP, not yours, but that will still give them full access.
There are two ways to protect against that:
1. Create a list of approved IP addresses (including your own) that can access the site or admin part of the site. That way the hacker will never get access from another location.
2. Use a real login form with sessions or something else to show that that user really has logged in rather than just submitting a cookie that might be fake (and one of thousands of brute force attempts).

[james438]

I like the idea of creating a list of approved ip addresses that are stored in my database or used in .htaccess file. For now I don't want to limit the number of login attempts so that I can continue to gather some information on the behavior of these hack attempts. I have a script that records all valid and hack attempts. Some are innocent like google crawlers. Others are sql injection attacks.

I use unicode in my passwords to greatly hinder brute force attempts. When using letters and numbers and capital letters to generate a password I get a password that is 62 to the power of the number of characters in the password. In the above example if I were to only use letters and numbers I would have to make approximately 62^8 attempts. With unicode I get 65536 to the power of the number of characters in the password, which is a considerably larger number and thus far more difficult to crack.

I do not disagree that sessions are more secure. I am leaving myself slightly open to attacks for now so that I can learn more about my attackers. For my site I do not believe it is necessary to have to log in every time I want to have admin access to my site. My site has many files that are more tailored just for myself or files that I do not feel are finished enough for public viewing. I keep sensitive information off site. I like to change my passwords every so often just to be safe. I might use sessions in the future, but not now. I feel like my site is secure enough to ward the casual hacker. If I were concerned about very sensitive or personal data I would, but even if my site were compromised or destroyed I can always upload it again to my hosting service.

[djr33]

That's fine-- do what you want with the site. I'm just explaining the technical details from my experience. As I've said, it's probably not realistically necessary to take every precaution (and would make your life as an admin on the site more difficult).

The one last point I want to make, though, is that you can limit login attempts and still track what the hackers are doing-- just make it a silent block. After 10 incorrect passwords, make that IP wait one hour, but don't display anything-- just pretend that every password is incorrect until that time limit is up. Or, if you find someone doing a very serious brute force attack just block that IP from gaining access (that is-- reject the password even if it's right). The hackers never need to know-- the response can read "incorrect password" and it won't hurt your ability to see how they're attacking the site. It will just protect it while you're doing that. In fact, you could make it like a true "silent alarm" and have it automatically send you an email so you can watch their hacking attempt live.

[traq]

absolutely. a few more things for passwords:

1. send a unique token (a random hash, for example) in a hidden field with every login form, and save the value (sessions would come in handy here) and time to compare the submission to. This will prevent malicious users from creating their own login forms to work from, since you'll reject any form submission that doesn't match the unique value that you sent.

2. You can also have forms expire in this way; don't accept a login attempt from a form that is more than a helf-hour or so old. Likewise, don't accept login attempts that are too quick: legitimate users don't make 5 login attempts in as many seconds, so block them (silently, as Daniel suggests).