note 68088 added to features.http-auth
| From: | web at kwi dot dk | Date: | Wed, 12 Jul 2006 17:23:18 +0000 |
| Subject: | note 68088 added to features.http-auth | ||
| Groups: | php.notes | ||
| Request: | Send a blank email to php-notes+get-114712@lists.php.net to get a copy of this message | ||
While Digest authentication is still far superior to Basic authentication, there are a number of
security issues that one must keep in mind.
In this respect, the Digest example given above is somewhat flawed, because the nonce never times
out or otherwise become invalid. It thus becomes a password-equivalent (although to that specific
URL only) and can be used by an eavesdropper to fetch the page at any time in the future, thus
allowing the attacker to always access the latest version of the page, or (much worse) repeatedly
invoke a CGI script -- for instance, if the user requests the URL
"/filemanager?delete=somefile", the attacker can repeat this deletion at any point in the
future, possibly after the file has been recreated.
And while it might not be possible to change GET data without reauthentication, cookies and POST
data *can* be changed.
To protect against the first problem, the nonce can be made to include a timestamp, and a check
added to ensure that nonces older than e.g. 30 minutes result in a new authentication request.
To solve the second problem, a one-time only nonce needs to be generated -- that is, all further
requests using a particular nonce must be refused.
One way to do this: When the user requests an action such as "deletefile", store a
randomly generated nonce in a session variable, issue a 401 authentication challenge with that
nonce, and then check against the stored value when receiving the authentication (and clear the
session variable).
This way, although a possible eavesdropper receives the nonce and thus gains the ability to perform
the action, he can only perform it once -- and the user was going to perform it anyway. (Only the
user or the attacker, but not both, gets to perform the action, so it's safe.)
Of course, at some point, the security can only be improved by switching to HTTPS / SSL / TLS (this
is for instance the only way to defend against man-in-the-middle attacks). You decide the level of
security.
----
Server IP: 195.184.96.15
Probable Submitter: 192.38.95.24
----
X-Spam-Status: No, hits=3.1 required=5.0 tests=DATE_MISSING,FROM_NO_LOWER
autolearn=no version=2.64
----
Manual Page -- http://www.php.net/manual/en/features.http-auth.php
Edit -- http://master.php.net/note/edit/68088
Del: integrated -- http://master.php.net/note/delete/68088/integrated
Del: useless -- http://master.php.net/note/delete/68088/useless
Del: bad code -- http://master.php.net/note/delete/68088/bad+code
Del: spam -- http://master.php.net/note/delete/68088/spam
Del: non-english -- http://master.php.net/note/delete/68088/non-english
Del: in docs -- http://master.php.net/note/delete/68088/in+docs
Del: other reasons-- http://master.php.net/note/delete/68088
Reject -- http://master.php.net/note/reject/68088
Search -- http://master.php.net/manage/user-notes.php