Why include a HTTP_REFERER check?

I'll explain why. Lets say I'm a malicious user and I want to hack your forums. I would then create a page with a hidden form that autosubmits when you visit it (easily done with JavaScript). I could e.g. mimic the "change status" form in the user profile so that when an administrator from your forums visits the page, the form will submit back to your forums and make me an admin, all completely transparent. However, since all admin and moderator actions are verified agains HTTP_REFERER, the forum wouldn't allow such an action. The referrer check is there to prevent that admins and moderators are tricked into taking action that can cause security problems.

Ok, not sure I made too much sense in the above "one-liner".

If the page with the javascript submits the data to http://evil.example.com/evil-script.php, then evil-script.php might include code for sending the data to the punBB-board + spoofing the HTTP_REFERER. After all, the HTTP_REFERER is just a string / HTTP header. If I know the board URL, I know what to include in my spoof-scripts. A HTTP_REFERER check only gives a false feeling of security.

"The most common use of this header is to track how users are finding your site. (...) this information should only be used to satisfy your curiosity (...) it should never be relied upon for any sort of security." - Chris Shiflett, HTTP Developer's Handbook

Wouldn't it be better to include some kind of shared secret between the form and the admin-scripts. One could for instance include a hidden-field in the form - with its value set to some kind of "dynamic"/"secret" content, and then validate the post-data in the admin-scripts afterwards.

Example:
First, generate the value:

<?php $secret = md5(date("Ymdh") . "some kind of secret string"); ?>

(It would probably have to be better than the use of date() above, but it serves as an example of content that you would be able to check later on)
Then, insert it into the form

<input type="hidden" name="secret" value="<?= $secret ?>" />

And finally, in the admin-scripts, you check that a $newly_calculated_value_of_secret == $_POST['secret'].

Make sense?

It's of course not bulletproof, but this way you at least require more effort from the user (to figure out what the $secret is / is calculated from), plus: an evil form wouldn't be valid/useful for long...

Yeah, you're 100% right - one would need the cookie-values in order to fake the request. Although not too likely, an evil script could get access to cookies, for instance via browsers' security holes: like when microsoft releases a new vulnerable browser, for instance internet explorer 6.0 (before SP1), + there are still users out there using older browsers. I would guess that that scenario is just as likely as someone making you visit an evil script while you're logged in as admin at your own board.

My point is that I for one wouldn't count on the HTTP_REFERER to add any extra security. To me, vBulletin's separate session cookie for the admin-panel seems preferable over a HTTP_REFERER check: if you're an admin, you're not _always_ logged in as admin-admin (plus: it favors usability)....

But, it's your forum (and I'm pleased with it so far)

http://www.securityfocus.com/bid/4754/discussion/
http://www.securityfocus.com/bid/3546/discussion/

If you click the "Info"-tab, you'll see a list of the vulnerable versions of ie.

Yeah, but one doesn't have to do admin stuff that often, really.

Agree.

zaher: It's not a bad idea, but it has one big problem. There is no way of upgrading everyones password so they would all have to be reset if upgrading.

Yes, but how will you keep track of whether a users hash is based on the salt ($login_key) or not?

But with your code, everyone will be forced to use "Forget your password?" to request a new password so that a hash based on not only the password but the login key as well can be generated and stored in the database. I can't see how it would be possible to avoid.

Ah, now I see what you mean. I'll investigate further!

Hmmm.. i dont think this method adds very much security. If you have a forum it's simple to retrieve the "real" password and not the hashed.
You just have to add some code in the login procedure.

This could add security if the attacker only has access to the Database or if an attacker manage to steal the victims cookie from your forum.

Do you mean that the random key should be stored in the cookie?

In the scenario that you have access to the hashed pw. You could just create the double hashed pw with any number on you own. The only thing you need to know is how the pun_hash works.
This way anyone can create a valid cookie out of the pwhash in the db.

This method only gives security if the attacker has stolen the cookie from your forum.
But if he manage to steal the cookie from your forum he could probably steal the cookie from the victims own forum too. Then he could just use the cookie as it is.

I hope I made any sense and that i havent missunderstood anything.

EDIT: My suggestion would be to use the second method but store the random number in the DB. I see no reason why this should be stored in cookie.

lol a MD5ed SHA1 sounds pretty invincible

No, but hash(seed + hash(password)) is safer than hash(password).

Actually a "double hash" is more safe. It doesn't have any inherent improved security. A bad password is a bad password. But in reality, it makes it a lot harder to brute force seeing as there are, as far as I know, no brute force tools out there that calculate the hash twice.